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.0
Via: SIP/2.0/UDP 192.168.2.124:50422;branch=z9hG4bK-qa5k4ddrhvok;rport
From: "Büro Jan" <sip:XXXXX@tel.t-online.de>;tag=dzadbqiwhi
To: <sip:YYYYY@tel.t-online.de;user=phone>
Call-ID: 313538303338353434303531333530-mxeagr7ulapk
CSeq: 2 INVITE
Max-Forwards: 70
User-Agent: snomD765/10.1.49.11
Contact: <sip:XXXXX@192.168.2.124:50422>;reg-id=1
X-Serialnumber: 00041394E891
Accept: application/sdp
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, MESSAGE, INFO, UPDATE
Allow-Events: talk, hold, refer, call-info
Supported: timer, 100rel, replaces, from-change
Session-Expires: 3600
Min-SE: 90
Proxy-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 OK
Via: SIP/2.0/UDP 192.168.2.124:50422;received=84.141.56.123;rport=50422;branch=z9hG4bK-qa5k4ddrhvok
To: <sip:YYYYY@tel.t-online.de;user=phone>;tag=h7g4Esbg_p65542t1580385444m252622c553395349s1_688083261-1877431650
From: "Büro Jan" <sip:XXXXX@tel.t-online.de>;tag=dzadbqiwhi
Call-ID: 313538303338353434303531333530-mxeagr7ulapk
CSeq: 2 INVITE
Contact: <sip:sgc_c@217.0.25.32;transport=udp>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Record-Route: <sip:217.0.25.32;transport=udp;lr>
Session-Expires: 1800;refresher=uas
Supported: 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: 3600
In 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.0
Via: SIP/2.0/UDP 192.168.2.124:50422;branch=z9hG4bK-7g2u2oeo3gx7;rport
Route: <sip:217.0.25.32;transport=udp;lr>
From: "Büro Jan" <sip:XXXXX@tel.t-online.de>;tag=dzadbqiwhi
To: <sip:YYYYY@tel.t-online.de;user=phone>;tag=h7g4Esbg_p65542t1580385444m252622c553395349s1_688083261-1877431650
Call-ID: 313538303338353434303531333530-mxeagr7ulapk
CSeq: 4 BYE
Max-Forwards: 70
User-Agent: snomD765/10.1.49.11
Contact: <sip:XXXXX@192.168.2.124:50422>;reg-id=1
RTP-RxStat: Total_Rx_Pkts=45548,Rx-Pkts=45548,Rx_Pkts_Lost=0,Remote_Rx_Pkts_Lost=0
RTP-TxStat: Total_Tx_Pkts=45798,Tx_Pkts=45798,Remote_Tx_Pkts=45798
Content-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.0
Max-Forwards: 68
Via: SIP/2.0/UDP 217.0.25.32:5060;branch=z9hG4bKg3Zqkv7ijhilzf9on328588dz3u6tye7s
To: "Büro Jan" <sip:XXXXX@tel.t-online.de>;tag=dzadbqiwhi
From: <sip:YYYYY@tel.t-online.de;user=phone>;tag=h7g4Esbg_p65542t1580385444m252622c553395349s1_688083261-1877431650
Call-ID: 313538303338353434303531333530-mxeagr7ulapk
CSeq: 3 UPDATE
Contact: <sip:sgc_c@217.0.25.32;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-Length: 0
Allow: 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!!