900 Sekunden Problem, Telefonieabbruch am SIP-Anschluss

Question

Hallo, ich habe hier schon viel zu dem Problem gelesen und auch schon Tickets eingestellt, aber die 'Lösungen' brachten keine Lösung. Schlussendlich sollte es am Telefon liegen..... zur Technik: Speedlink 5501; SNOM D765 (neueste Firmware auf beiden Geräten) Hier die SIP Kommunikation zwischen snom und PBX Server: Das snom mit nummer XXXX sendet ein Invite an YYYYY;Das Gespräch kommt zusatnde, soweit so gut. ------------------------Sent to Udp:217.0.25.32:5060 from Udp:192.168.2.124:50422 at Jan 30 12:57:23.743 (1419 bytes):INVITE sip:YYYYY@tel.t-online.de;user=phone SIP/2.0Via: SIP/2.0/UDP 192.168.2.124:50422;branch=z9hG4bK-qa5k4ddrhvok;rportFrom: 'BÃ¼ro Jan' ;tag=dzadbqiwhiTo: Call-ID: 313538303338353434303531333530-mxeagr7ulapkCSeq: 2 INVITEMax-Forwards: 70User-Agent: snomD765/10.1.49.11Contact: ;reg-id=1X-Serialnumber: 00041394E891Accept: application/sdpAllow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATEAllow-Events: talk, hold, refer, call-infoSupported: timer, 100rel, replaces, from-changeSession-Expires: 3600Min-SE: 90Proxy-Authorization: Digest username='XXXXX',realm='tel.t-online.de',nonce='5BC6F604AFC4325E000000005494B740',uri='sip:YYYYY@tel.t-online.de;user=phone',qop=auth,nc=00000001,cnonce='48bdbc44',response='b886ef827dfb0795768f950a585c4ef0',algorithm=MD5------------------------Received from Udp:217.0.25.32:5060 on Udp:192.168.2.124:50422 at Jan 30 12:57:28.017 (1339 bytes):SIP/2.0 200 OKVia: SIP/2.0/UDP 192.168.2.124:50422;received=84.141.56.123;rport=50422;branch=z9hG4bK-qa5k4ddrhvokTo: ;tag=h7g4Esbg_p65542t1580385444m252622c553395349s1_688083261-1877431650From: 'BÃ¼ro Jan' ;tag=dzadbqiwhiCall-ID: 313538303338353434303531333530-mxeagr7ulapkCSeq: 2 INVITEContact: ;+g.3gpp.icsi-ref='urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel'Record-Route: Session-Expires: 1800;refresher=uasSupported: timer------------------------------Wichtig, was hier zwischen snom und die Gegenseite( PBX Server) vereinbart wird.Konzentrieren wir uns auf die Parametern, die für die Länge der Sitzung (Gespräch) von Bedeutung sind.Snom schlägt eine Sitzung von 3600 Sekunden; siehe: Session-Expires: 3600In dem 200 OK ändert die PBX diesen Wert zu Session-Expires: 1800, also 30 Minuten. Zusätlich definiert sie wer die Sitzung erneurt: refresher=uas.Das bedeutet, dass der (uas: user agent server) übernimmt die Aktualisierung der Sitzung. In diesem Fall die PBX .Was sagt die RFC dazu: hier kommt rfc4028 im Spiel und sagt, dass der refresher nach der Hälfte der Zeit ein Update schicken muss. In unserem Fall sind es genau 15 min.Erhält der Client (in diesem Fall snom) keine Nachricht nach Ablauf der Hälfte der Zeit vom Server, um die Sitzung aufrechtzuerhalten, beendet der Client die Sitzung.Was snom auch mit der Sendung der unten stehende BYE.Diese Vorgehensweise ist hier beschrieben: https://tools.ietf.org/html/rfc4028-----------------------------------Sent to Udp:217.0.25.32:5060 from Udp:192.168.2.124:50422 at Jan 30 13:12:41.714 (699 bytes):BYE sip:sgc_c@217.0.25.32;transport=udp SIP/2.0Via: SIP/2.0/UDP 192.168.2.124:50422;branch=z9hG4bK-7g2u2oeo3gx7;rportRoute: From: 'BÃ¼ro Jan' ;tag=dzadbqiwhiTo: ;tag=h7g4Esbg_p65542t1580385444m252622c553395349s1_688083261-1877431650Call-ID: 313538303338353434303531333530-mxeagr7ulapkCSeq: 4 BYEMax-Forwards: 70User-Agent: snomD765/10.1.49.11Contact: ;reg-id=1RTP-RxStat: Total_Rx_Pkts=45548,Rx-Pkts=45548,Rx_Pkts_Lost=0,Remote_Rx_Pkts_Lost=0RTP-TxStat: Total_Tx_Pkts=45798,Tx_Pkts=45798,Remote_Tx_Pkts=45798Content-Length: 0--------------------------------------------------In dem SIP Trace sehen wir auch, dass gleich nachdem snom das BYE schickt, schickt die PBX ein Update für die Sitzung, was aber zuspät kommt(13:12:43.583).Siehe:-----------------------------Received from Udp:217.0.25.32:5060 on Udp:192.168.2.124:50422 at Jan 30 13:12:43.583 (716 bytes):UPDATE sip:XXXXX@192.168.2.124:50422 SIP/2.0Max-Forwards: 68Via: SIP/2.0/UDP 217.0.25.32:5060;branch=z9hG4bKg3Zqkv7ijhilzf9on328588dz3u6tye7sTo: 'BÃ¼ro Jan' ;tag=dzadbqiwhiFrom: ;tag=h7g4Esbg_p65542t1580385444m252622c553395349s1_688083261-1877431650Call-ID: 313538303338353434303531333530-mxeagr7ulapkCSeq: 3 UPDATEContact: ;+g.3gpp.icsi-ref='urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel'Min-Se: 900Session-Expires: 1800;refresher=uacSupported: timerContent-Length: 0Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE, PUBLISH, INFO, INVITE, ACK, OPTIONS, CANCEL, BYE------------Damit ist es bewiesen, dass das Problem auf der Server Seite liegt, weil es die Sitzung nicht rechtzeitig aktualisiert. LIEBE Community:Was muss ich ändern, oder was die Telekom? Oder sollte das tatsächlich nicht funktionieren?? DANKE!!

jan.haberkamm · Accepted Answer

@talk @Lin J. @wari1957  Habe jetzt eine FritzBox (7530) angeschlossen und siehe da, es geht einwandfrei.Vielen Dank nochmal für Eure Hilfe!

wari1957 · Answer

Hallo @jan.haberkamm ,Ich sehe das so, der Telekomserver sendet den UPDATE, dieser geht aber verlustig, kann bei udp ja passieren.Versuch doch mal als Transport tcp oder tls einzustellen.

Social Media