Telekom VoIP Gesprächsabbruch nach exakt 15 Minuten

magicamun

Neuer User
Mitglied seit
1 Aug 2006
Beiträge
53
Punkte für Reaktionen
0
Punkte
6
Hallo - wie im Betreff oben geschrieben habe ich Abbrüche von Gesprächen nach exakt 15 Minuten - Das ganze scheint (auch) von der Gegenstelle abhängig zu sein.

Mein Trunk sieht so aus:
Outgoing:
Code:
type=friend
remotesecret=<passwort>
qualify=no
nat=force_rport,comedia
maxexpirey=240
insecure=port,invite
host=tel.t-online.de
defaultuser=<user>
authuser=<user>
fromdomain=tel.t-online.de
dtmfmode=rfc2833
defaultexpirey=240
canreinvite=no
realm=tel.t-online.de
extension=<vorwahl + rufnummer>

Incoming User Context ist "Rufnummer ohne Vorwahl"

Der Register String sieht so aus:
Code:
<Rufnummer mit Vorwahl>:<passwort>:<[email protected]@tel.t-online.de/<rufnummer mit vorwahl>~480

In den Asterisk SIP-Settings habe ich noch

session-timers=refuse

gesetzt - der Rest dort ist default.

Ich habe Gegenstellen, da passiert das nicht oder selten und ich habe eine Gegenstelle, da passiert das jedesmal - Nervig.

Der Freepbx hängt hinter einer FB und separatener Firewall und bekommt aus dem I-Net alles, was hier durch passt:

Code:
# Asterisk SIP - Signalling  from the internet (Telekom SIP-Servers) to asterisk
ACCEPT          dsl:217.10.0.0/13       dmz     udp     5060
ACCEPT          dsl:217.0.23.0/13       dmz     udp     5060
# Asterisk SIP - Signalling  from the internet (Telekom SIP-Servers) to asterisk
ACCEPT          dsl:217.10.0.0/13       dmz     udp     5070
ACCEPT          dsl:217.0.23.0/13       dmz     udp     5070
# Asterisk SIP - Signalling  from the internet (Telekom SIP-Servers) to asterisk
ACCEPT          dsl:217.10.0.0/13       dmz     udp     5080
ACCEPT          dsl:217.0.23.0/13       dmz     udp     5080
# Asterisk SIP - Signalling  from the internet (Telekom SIP-Servers) to asterisk
ACCEPT          dsl:217.10.0.0/13       dmz     udp     10000,19999
ACCEPT          dsl:217.0.23.0/13       dmz     udp     10000,19999
ACCEPT          dsl:217.10.0.0/13       dmz     udp     30000,39999
ACCEPT          dsl:217.0.23.0/13       dmz     udp     30000,39999
ACCEPT          dsl:217.10.0.0/13       dmz     udp     40000,49999
ACCEPT          dsl:217.0.23.0/13       dmz     udp     40000,49999
 
Ok, wenn's die Session-Timers nicht sind, kann es ggf. hier auch ein RTP-Timeout sein (da es qualify hier auch nicht ist).
Schau Dir mal die RTP-Settings (Keepalive, Timeout) an und mach allenfalls mal einen RTP-Debug.
Telekom ist leider einer der SIP-Anbieter, die im Hinblick auf Ihre "Interpretation" des SIP-protokolls wirklich nervig sind (weshalb sie bei mir auch nur noch der "Notnagel" sind und nicht wirklich zum telefonieren benutzt werden ...
 
das hier ist das zum Thema rtp:

Code:
root@raspbx:/etc/asterisk# grep rtp *
rtp_additional.conf:rtpstart=10000
rtp_additional.conf:rtpend=20000
rtp_additional.conf:rtpchecksums=yes
rtp_additional.conf:strictrtp=yes
rtp.conf:#include rtp_additional.conf
rtp.conf:#include rtp_custom.conf
sip_general_additional.conf:rtpend=20000
sip_general_additional.conf:rtpstart=10000
sip_general_additional.conf:rtpholdtimeout=300
sip_general_additional.conf:rtpkeepalive=0
sip_general_additional.conf:rtptimeout=30
root@raspbx:/etc/asterisk#

und wie mache ich einen rtp-debug?

- - - Aktualisiert - - -


ich hatte sip debug eingeschaltet bekommen - dann hatte ich von der Gegenstelle bei der das "immer" passiert einen Anruf - das Gespräch hielt gaz normal gute 23 Minuten, bis ich es sauber beendet habe. Habe dann dort angerufen und - nach 15Minuten ist das hier der spannende Ausschnitt aus dem Log:

Code:
Max-Forwards: 70
From: "Unknown" <sip:[email protected]>;tag=as0cb4ed01
To: <sip:[email protected]:5060>
Contact: <sip:[email protected]:5060>
Call-ID: [email protected]:5060
CSeq: 102 OPTIONS
User-Agent: FPBX-13.0.190.7(11.23.0)
Date: Sun, 11 Dec 2016 07:56:58 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Content-Length: 0


---
Retransmitting #4 (no NAT) to 192.168.2.10:5060:
OPTIONS sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.2.253:5060;branch=z9hG4bK60685e33
Max-Forwards: 70
From: "Unknown" <sip:[email protected]>;tag=as0cb4ed01
To: <sip:[email protected]:5060>
Contact: <sip:[email protected]:5060>
Call-ID: [email protected]:5060
CSeq: 102 OPTIONS
User-Agent: FPBX-13.0.190.7(11.23.0)
Date: Sun, 11 Dec 2016 07:56:58 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Content-Length: 0


---
Really destroying SIP dialog '[email protected]:5060' Method: OPTIONS

<--- SIP read from UDP:217.0.23.4:5060 --->
INVITE sip:<RUFNUMMER MIT VORWAHL>@192.168.2.253:5060 SIP/2.0
Max-Forwards: 64
Via: SIP/2.0/UDP 217.0.23.4:5060;branch=z9hG4bKg3Zqkv7ivhqcctyezwe9tfzy5shx6hi3r
To: <sip:<RUFNUMMER MIT VORWAHL>@tel.t-online.de>;tag=as43627e36
From: <sip:<GEGENSTELLE>@tel.t-online.de>;tag=h7g4Esbg_p65566t1481442093m365862c929600681s1_498794199-2098845657
Call-ID: [email protected]
CSeq: 107 INVITE
Contact: <sip:[email protected];transport=udp>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Min-Se: 900
Session-Expires: 1800;refresher=uac
Supported: timer
Content-Type: application/sdp
Content-Length: 199
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, INFO, PRACK, PUBLISH, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE

v=0
o=- 63251794 506029457 IN IP4 0.0.0.0
s=-
t=0 0
m=audio 0 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=fmtp:8 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20
<------------->
--- (14 headers 11 lines) ---
Sending to 217.0.23.4:5060 (NAT)
[2016-12-11 08:57:04] WARNING[1755][C-00000014]: chan_sip.c:9992 process_sdp: Ignoring audio media offer because port number is zero
[2016-12-11 08:57:04] WARNING[1755][C-00000014]: chan_sip.c:10413 process_sdp: Insufficient information in SDP (c=)...

<--- Reliably Transmitting (NAT) to 217.0.23.4:5060 --->
SIP/2.0 488 Not acceptable here
Via: SIP/2.0/UDP 217.0.23.4:5060;branch=z9hG4bKg3Zqkv7ivhqcctyezwe9tfzy5shx6hi3r;received=217.0.23.4;rport=5060
From: <sip:<GEGENSTELLE>@tel.t-online.de>;tag=h7g4Esbg_p65566t1481442093m365862c929600681s1_498794199-2098845657
To: <sip:<RUFNUMMER MIT VORWAHL>@tel.t-online.de>;tag=as43627e36
Call-ID: [email protected]
CSeq: 107 INVITE
Server: FPBX-13.0.190.7(11.23.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0


<------------>

<--- SIP read from UDP:217.0.23.4:5060 --->
BYE sip:<RUFNUMMER MIT VORWAHL>@192.168.2.253:5060 SIP/2.0
Max-Forwards: 64
Via: SIP/2.0/UDP 217.0.23.4:5060;branch=z9hG4bKg3Zqkv7ip5zghuydep6o9xrz4ym2xrprl
To: <sip:<RUFNUMMER MIT VORWAHL>@tel.t-online.de>;tag=as43627e36
From: <sip:<GEGENSTELLE>@tel.t-online.de>;tag=h7g4Esbg_p65566t1481442093m365862c929600681s1_498794199-2098845657
Call-ID: [email protected]
CSeq: 108 BYE
Content-Length: 0
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, INFO, PRACK, PUBLISH, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE

<------------->
--- (9 headers 0 lines) ---

<--- Reliably Transmitting (NAT) to 217.0.23.4:5060 --->
SIP/2.0 487 Request Terminated
Via: SIP/2.0/UDP 217.0.23.4:5060;branch=z9hG4bKg3Zqkv7ivhqcctyezwe9tfzy5shx6hi3r;received=217.0.23.4;rport=5060
From: <sip:<GEGENSTELLE>@tel.t-online.de>;tag=h7g4Esbg_p65566t1481442093m365862c929600681s1_498794199-2098845657
To: <sip:<RUFNUMMER MIT VORWAHL>@tel.t-online.de>;tag=as43627e36
Call-ID: [email protected]
CSeq: 107 INVITE
Server: FPBX-13.0.190.7(11.23.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Content-Length: 0


<------------>
Sending to 217.0.23.4:5060 (NAT)
Scheduling destruction of SIP dialog '[email protected]' in 32000 ms (Method: BYE)

<--- Transmitting (NAT) to 217.0.23.4:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 217.0.23.4:5060;branch=z9hG4bKg3Zqkv7ip5zghuydep6o9xrz4ym2xrprl;received=217.0.23.4;rport=5060
From: <sip:[email protected]>;tag=h7g4Esbg_p65566t1481442093m365862c929600681s1_498794199-2098845657
To: <sip:<RUFNUMMER MIT VORWAHL>@tel.t-online.de>;tag=as43627e36
Call-ID: [email protected]
CSeq: 108 BYE
Server: FPBX-13.0.190.7(11.23.0)
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Content-Length: 0


<------------>
    -- Executing [h@macro-dialout-trunk:1] Macro("SIP/30-00000026", "hangupcall,") in new stack
    -- Executing [s@macro-hangupcall:1] ExecIf("SIP/30-00000026", "0?Set(CDR(recordingfile)=.wav)") in new stack
    -- Executing [s@macro-hangupcall:2] GotoIf("SIP/30-00000026", "1?theend") in new stack
    -- Goto (macro-hangupcall,s,4)
    -- Executing [s@macro-hangupcall:4] ExecIf("SIP/30-00000026", "0?Set(CDR(recordingfile)=)") in new stack
    -- Executing [s@macro-hangupcall:5] Hangup("SIP/30-00000026", "") in new stack
  == Spawn extension (macro-hangupcall, s, 5) exited non-zero on 'SIP/30-00000026' in macro 'hangupcall'
  == Spawn extension (macro-dialout-trunk, h, 1) exited non-zero on 'SIP/30-00000026'
  == Spawn extension (macro-dialout-trunk, s, 23) exited non-zero on 'SIP/30-00000026' in macro 'dialout-trunk'
  == Spawn extension (from-internal, <GEGENSTELLE>, 6) exited non-zero on 'SIP/30-00000026'
Scheduling destruction of SIP dialog '3970312371@91_56_190_149' in 6400 ms (Method: ACK)
set_destination: Parsing <sip:[email protected]:5060> for address/port to send to
set_destination: set destination to 192.168.2.11:5060
Reliably Transmitting (no NAT) to 192.168.2.11:5060:
BYE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.2.253:5060;branch=z9hG4bK459feb0d;rport
Max-Forwards: 70
From: <sip:<GEGENSTELLE>@dmz.thielemann.intern;user=phone>;tag=as27a00ccb
To: "Gigaset C610 IP" <sip:[email protected]>;tag=1122633120
Call-ID: 3970312371@91_56_190_149
CSeq: 102 BYE
User-Agent: FPBX-13.0.190.7(11.23.0)
Proxy-Authorization: Digest username="30", realm="asterisk", algorithm=MD5, uri="sip:dmz.thielemann.intern", nonce="1faa8e71", response="1cdc65d8a6c8d14cea7a23bfeefa56f2"
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0


---

<--- SIP read from UDP:192.168.2.11:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.2.253:5060;branch=z9hG4bK459feb0d;rport=5060
From: <sip:<GEGENSTELLE>@dmz.thielemann.intern;user=phone>;tag=as27a00ccb
To: "Gigaset C610 IP" <sip:[email protected]>;tag=1122633120
Call-ID: 3970312371@91_56_190_149
CSeq: 102 BYE
Contact: <sip:[email protected]:5060>
Supported: replaces
User-Agent: C610 IP/42.238.00.000.000
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, SUBSCRIBE, NOTIFY, REFER, UPDATE
Content-Length: 0

<------------->
--- (11 headers 0 lines) ---
SIP Response message for INCOMING dialog BYE arrived
Really destroying SIP dialog '3970312371@91_56_190_149' Method: ACK
Reliably Transmitting (no NAT) to 192.168.2.10:5060:
OPTIONS sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.2.253:5060;branch=z9hG4bK7f6440ab
Max-Forwards: 70
From: "Unknown" <sip:[email protected]>;tag=as765e324f
To: <sip:[email protected]:5060>
Contact: <sip:[email protected]:5060>
Call-ID: [email protected]:5060
CSeq: 102 OPTIONS
User-Agent: FPBX-13.0.190.7(11.23.0)
Date: Sun, 11 Dec 2016 07:57:12 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces
Content-Length: 0
 
Das sieht so aus, als würde die Telekom das session-timers=refuse ignorieren und trotzdem nach Ablauf ein Re-Invite schicken. Das SDP enhält ungültige RTP Angaben, deshalb lehnt Asterisk es mit 488 ab und das Gespräch bricht ab.
 
und was kann ich tun? Ich habe andere gegenstellen, da passiert das nicht - das ist ja das "perverse" - Wenn ich mich auf meinem Mobilfon anrufe, hält die Verbindung "ewig" - Hilft ein anderes Sip-Modul (jsip?)
 
Ich muss da nochmal nachaken - macht es Sinn, bei den ***********n einen Supportfall "aufzumachen"? Hat da jemand Erfahrung?

Was ich nicht kapiere:

ich geh mal davon aus, dass es mehr als nur einen Nutzer des telekom-VoIP-Anschlusses gibt, und kann mir nicht vorstellen, dass Leuet die über die Speedports der TK telefonieren ebensolche Probleme haben. Frage also: was ist da prinzipiell anders? SIP machen die ja sicher auch...
 
Die Suchmaschine mit den vielen Ooooo liefert Ergebnisse aus dem Telekom Hilft Forum, wo es genau um dieses Problem geht, aber niemals eine Lösung gefunden wurde. Von daher glaube ich nicht, dass ein weiterer Support Fall allzu viel bringen wird. Allerdings kann ich Dir auch keine anderweitige Lösung bieten. PJSIP könnte vielleicht helfen, da ist so einiges modernisiert worden.
 
Gibt es schon eine Lösung für das Problem?
Ich habe eine Digibox Smart hinter meinem IPfire Router hängen. Da brechen die Gespräche nach 15min (900sek) ab. Es sind 3 Telekom Rufnummern drauf.
Ich habe noch 2 andere Provider, einen auf nem AVM Voip Gateway und den anderen direkt auf meiner Telefonanlage, da passiert das nicht.
Die digibox brauche ich wegen dem Clear Mode für Fernwartung.
 
"Vorgeschaltetes Gerät mit NAT" in den SIP-Provider-Accountdaten aktivieren.
 
Gibt es schon eine Lösung für das Problem?

Ja. Die Lösung heißt schon sehr lange chan_pjsip statt chan_sip. Zu diversen Providern klappt die 15 minütliche "Totmannschaltung" via ReInvite nicht. Mit pjsip wird statt dem ReInvite ein Update verwendet - mit dem funktioniert es (chan_sip ist zu alt und kennt die update-Methode nicht).
 
Ja, in den SIP-Provider-Einstellungen gibt es an dieser Stelle keinen Unterschied.
 
Und wie ändere ich das jetzt?

-- aktualisiert --

Ich habe jetzt von UDP auf TCP umgestellt in den Einstellungen, damit funktioniert es jetzt.
 
Zuletzt bearbeitet von einem Moderator:
Die Ursache liegt an deinem IPfire Router, der hat wohl ein Problem mit UDP und es kommt zum UDP Session Timeout.
 
Kann nicht sein, weil mit Sipgate und voip2gsm funktionierts auch mit UDP
Ich denke eher daß es ein Problem bei der Telekom gibt.
 
Wird denn bei Sipgate und voip2gsm überhaupt ein Session-Timer aufgesetzt?
 
Ich habe das gleiche Problem wie "magicamun" im ersten Beitrag.

Nach genau 16min habe ich Gesprächsabbrüche bei ausgehenden Telefonaten mit meinem Sinus 501 (Anrufbeantworter nicht im Betrieb). Das Mobilteil ist über Dect mit meiner eigenen Fritz&Box 6490 verbunden.
Mein Provider ist Vodafone Kabel Deutschland.
Wo könnte das Problem liegen?
Ich würde mich um sachliche Problemlösungen sehr freuen!
 
Du müsstest einen Paketmitschnitt erstellen (Anleitung), dann das Telefonat beginnen und auf den Abbruch warten. Dann den Mitschnitt beenden und mit bspw. Wireshark die SIP-Pakete analysieren, warum der Anruf beendet wurde. Gleichzeitig solltest du aber keine weiteren Internet-Tätigkeiten vornehmen, da ansonsten der Trace zu groß wird.
 
Danke für die schnelle Antwort! Ich bin natürlich davon ausgegangen,
dass die wahrscheinlichen Probleme bzw. die Ursachen schon bekannt sind
und es bereits Lösungsvorschläge hierzu gibt.
 
Die Wahrscheinlichkeit, das es am Router oder dem Zusammenspiel von Router und Telefon / Telefonanlage mit dem SIP - Provider liegt, schätze ich auf 95 % ein.
Nur weil das bei anderen Anbietern nicht passiert, ist dies kein Ausschlusskriterium. Denn jeder SIP - Server verhält sich anders. 15 Minuten ist ein Zeitrahmen der sehr gut auf einen UDP Session Timeout hindeutet.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.