Gelöst: SIP: 10.20.0367, Gesprächsabbruch nach 15 Minuten

Forum zu aktuellen Geräten der LANCOM Router/Gateway Serie

Moderator: Lancom-Systems Moderatoren

Antworten
Fully
Beiträge: 113
Registriert: 19 Apr 2007, 13:40

Gelöst: SIP: 10.20.0367, Gesprächsabbruch nach 15 Minuten

Beitrag von Fully »

Moin,

das leidige Thema wurde schon an folgenden Stellen debattiert,

viewtopic.php?f=42&t=17341&p=98415&hili ... res#p98402
lancom-systems-voip-router-f42/vcm-in-k ... 17320.html


Mit der 10.20.0336 tritt die hier diskutierte Form der Abbrüche nicht auf, ich formuliere hier bewusst vorsichtig. Bisher ist dieser Build mein Fallback-Favorit.

Mit dem Beta-Build 10.20.0353 traten die Abbrüche reproduzierbar nach 900 Sekunden auf, hielten über die RU3 (10.20.0355) an und minderten sich mit der 10.20.0367 soweit, dass ich annahm, diese Fehler wären verschwunden.

Dem ist leider nicht so. Ja, ich weiß, es gibt eine 10.20.0410, aber leider nicht für den den 1906 VA mit dem ich hier getestet habe.

Aktuell sind nur kommende Anrufe in Richtung SIP-Benutzer betroffen. ISDN- und Analog-Benutzer werden so behandelt, dass es zu keinem Abbruch kommt, weil in diesem Fall das Lancom selbst kommuniziert.
Mit der 10.20.0367 sehe ich als "Session-Expires" im INVITE nur noch Werte von 1800s oder 3600s. Die 900s scheinen ausgestorben, das verschiebt das Problem natürlich, denn längere Telefongespräche sind auch seltener. Maßgeblich für die 15 Minuten ist inzwischen nicht der "Session-Expires: <Wert in Sekunden>" im INVITE, sondern der häufig in der näheren Umgebung stehende "Min-SE: 900". Darauf weist auch Jirka in der zweiten "Forums-Quelle" hin. Danach müsste nach 900s - wir erinnern uns, das waren die 15 Minuten - wieder ein re-INVITE kommen.

Damit beginnt nun das Problem, denn in dem Dokument RFC 4028 "Session Timers in the Session Initiation Protocol", darf man dem ablaufenden Timer mit einem re-INVITE oder UPDATE begegnen.

Wie sieht das nun konkret aus:

Code: Alles auswählen

[SIP-Packet] 2019/02/21 19:00:22,895 [Packet]: 
Receiving datagram (1478 Bytes) at <Lancom-WAN-IP4>:11216 from <SIP-Provider-IP4>:5060 using UDP (RtgTag 0):
INVITE sip:<SIP-ID-Extern>@<Lancom-WAN-IP4>:11216;transport=udp SIP/2.0
Max-Forwards: 51
Via: SIP/2.0/UDP <SIP-Provider-IP4>:5060;branch=z9hG4bKg3Zqkv7iu9btwgu2kvefgg9obkdr7wubl
To: <sip:<SIP-ID-Extern>@hmbsx001.ngn.vodafone.de;user=phone>
From: <sip:SIP-ID-Gegenstelle@ims.vodafone.de;user=phone>;tag=h7g4Esbg_p65551t1550772025m527836c379417020s1_1068870541-1353243588
Call-ID: p65551t1550772025m527836c379417020s2
CSeq: 1 INVITE
Contact: <sip:sgc_c@<SIP-Provider-IP4>;transport=udp>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Record-Route: <sip:<SIP-Provider-IP4>;transport=udp;lr>
Accept-Contact: *;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
Min-Se: 900
P-Asserted-Identity: <sip:SIP-ID-Gegenstelle@vodafone.de;user=phone>
P-Asserted-Identity: <tel:SIP-ID-Gegenstelle>
Session-Expires: 1800
Supported: timer
Supported: 100rel
Supported: resource-priority
Content-Type: application/sdp
Content-Length: 215
Session-ID: e88b2fd7c8cd8d4174faf7132792d6a1
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE, INFO, INVITE, ACK, OPTIONS, CANCEL, BYE
Accept: application/isup
Accept: application/xml
Accept: application/media_control+xml
Accept: application/vnd.etsi.cug+xml
Accept: application/vnd.etsi.sci+xml
Accept: application/sdp

v=0
o=- 858566146 1068870226 IN IP4 <SIP-Provider-IP4>
s=IMSS
c=IN IP4 <SIP-Provider>
t=0 0
m=audio 37020 RTP/AVP 8 98 99
a=rtpmap:98 telephone-event/8000
a=rtpmap:99 telephone-event/16000
a=maxptime:20
a=ptime:20
Es kommt also ein INVITE mit einem "Min-Se: 900" an. Darauf antwortet das Lancom nach Extern mit einem "SIP/2.0 100 Trying", welches nicht weiter interessiert. Das INVITE wird im nachchsten Schritt von extern nach intern durchgereicht (172.16.100.1 ist das Lancom, 172.16.100.15 der SIP Client, ein S68Voip):

Code: Alles auswählen

[SIP-Packet] 2019/02/21 19:00:22,919 [Packet]: 
Sending datagram (967 Bytes) from 172.16.100.1:5060 to 172.16.100.15:5060 using UDP (RtgTag 1):
INVITE sip:<Teilnehmer/Benutzer>@172.16.100.15:5060 SIP/2.0
Via: SIP/2.0/UDP 172.16.100.1:5060;branch=z9hG4bK-9ae9207d-94d3ace3;rport
From: <sip:<Gegenstelle>@172.16.100.1;user=phone>;tag=-427150099-1030812341
To: <sip:<Teilnehmer/Benutzer>@172.16.100.1;user=phone>
Call-ID: 2650823467@00a057406ea8
CSeq: 1 INVITE
Max-Forwards: 70
User-Agent: LANCOM 1906VA (over ISDN) / 10.20.0367 / 06.02.2019
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, PRACK, INVITE, ACK, OPTIONS, CANCEL, BYE
Supported: 100rel,timer
Contact: <sip:<Gegenstelle>@172.16.100.1:5060;transport=UDP>
P-Asserted-Identity: <sip:<Gegenstelle>@172.16.100.1;user=phone>
Session-Expires: 1800
Min-SE: 900
Content-Type: application/sdp
Content-Length: 267

v=0
o=- 2730012341 2730012341 IN IP4 172.16.100.1
s=call
c=IN IP4 172.16.100.1
t=0 0
m=audio 16352 RTP/AVP 8 98 99
a=rtpmap:8 PCMA/8000
a=rtpmap:98 telephone-event/8000
a=rtpmap:99 telephone-event/16000
a=fmtp:98 0-15
a=sendrecv
a=ptime:20
a=maxptime:20
So - und da haben wir nun auch intern eine "Session-Expires: 1800" und "Min-SE: 900".

Kurz gefasst geht es so weiter:

SIP/2.0 100 Trying als interne Antwort auf das interne INVITE
SIP/2.0 180 Ringing vom Lancom an den Provider und
SIP/2.0 180 Ringing vom Teilnehmer/Benutzer an das Lancom

Dazu dann freundliche OKs, die sehen wir uns noch einmal genauer an, weil die mitegebenen "Allows" interessant sind:

Code: Alles auswählen

[SIP-Packet] 2019/02/21 19:00:34,636 [Packet]: 
Receiving datagram (709 Bytes) at 172.16.100.1:5060 from 172.16.100.15:5060 using UDP (RtgTag 1):
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.16.100.1:5060;branch=z9hG4bK-9ae9207d-94d3ace3;rport=5060
From: <sip:<Gegenstelle>@172.16.100.1;user=phone>;tag=-427150099-1030812341
To: <sip:<Teilnehmer/Benutzer>@172.16.100.1;user=phone>;tag=1900459748
Call-ID: 2650823467@00a057406ea8
CSeq: 1 INVITE
Contact: <sip:<Teilnehmer/Benutzer>@172.16.100.15:5060>
Supported: replaces
Allow-Events: message-summary, refer
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, REFER, SUBSCRIBE, NOTIFY
Content-Type: application/sdp
Content-Length: 199

v=0
o=40541015 5016 10 IN IP4 172.16.100.15
s=Mapping
c=IN IP4 172.16.100.15
t=0 0
m=audio 5016 RTP/AVP 8 99
a=rtpmap:8 PCMA/8000
a=rtpmap:99 telephone-event/8000
a=fmtp:99 0-16
a=sendrecv

[SIP-Packet] 2019/02/21 19:00:34,652 [Packet]: 
Sending datagram (1028 Bytes) from <Lancom-WAN-IP4>:11216 to <SIP-Provider-IP4>:5060 using UDP (RtgTag 0):
SIP/2.0 200 OK
Via: SIP/2.0/UDP <SIP-Provider-IP4>:5060;branch=z9hG4bKg3Zqkv7iu9btwgu2kvefgg9obkdr7wubl;received=<SIP-Provider-IP4>
Record-Route: <sip:<SIP-Provider-IP4>;transport=udp;lr>
From: <sip:SIP-ID-Gegenstelle@ims.vodafone.de;user=phone>;tag=h7g4Esbg_p65551t1550772025m527836c379417020s1_1068870541-1353243588
To: <sip:<SIP-ID-Extern>@hmbsx001.ngn.vodafone.de;user=phone>;tag=2083377501--1745710281
Call-ID: p65551t1550772025m527836c379417020s2
CSeq: 1 INVITE
User-Agent: LANCOM 1906VA (over ISDN) / 10.20.0367 / 06.02.2019
Server: Lancom
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE
Supported: 100rel,replaces,timer
Contact: <sip:<SIP-ID-Extern>@<Lancom-WAN-IP4>:11216;transport=UDP>
Session-Expires: 1800;refresher=uac
Require: timer
Content-Type: application/sdp
Content-Length: 199

v=0
o=- 0 0 IN IP4 <Lancom-WAN-IP4>
s=call
c=IN IP4 <Lancom-WAN-IP4>
t=0 0
m=audio 9534 RTP/AVP 8 98
a=rtpmap:8 PCMA/8000
a=rtpmap:98 telephone-event/8000
a=fmtp:98 0-15
a=sendrecv
a=ptime:20
Ein ACK extern und intern später: Yupp die Verbindung steht, was passiert nun kurz vor "Min-SE: 900"?

Code: Alles auswählen

[SIP-Packet] 2019/02/21 19:15:34,863 [Packet]: 
Receiving datagram (745 Bytes) at <Lancom-WAN-IP4>:11216 from <SIP-Provider-IP4>:5060 using UDP (RtgTag 0):
UPDATE sip:<SIP-ID-Extern>@<Lancom-WAN-IP4>:11216;transport=udp SIP/2.0
Max-Forwards: 68
Via: SIP/2.0/UDP <SIP-Provider-IP4>:5060;branch=z9hG4bKg3Zqkv7is5lkl6o56venov1emuvgq7hrz
To: <sip:<SIP-ID-Extern>@hmbsx001.ngn.vodafone.de;user=phone>;tag=2083377501--1745710281
From: <sip:SIP-ID-Gegenstelle@ims.vodafone.de;user=phone>;tag=h7g4Esbg_p65551t1550772025m527836c379417020s1_1068870541-1353243588
Call-ID: p65551t1550772025m527836c379417020s2
CSeq: 2 UPDATE
Contact: <sip:sgc_c@<SIP-Provider-IP4>;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, INFO, INVITE, ACK, OPTIONS, CANCEL, BYE
Verhülle deinen Himmel Zeus, was ist denn das? Ein UPDATE ??? Da gehört kein UPDATE hin, auch wenn der Name "Update" und die unglückliche Formulierung in RFC 4028 das nahe legen. Siehe RFC 3311:

Code: Alles auswählen

This specification defines the new UPDATE method for the Session
   Initiation Protocol (SIP).  UPDATE allows a client to update
   parameters of a session (such as the set of media streams and their
   codecs) but has no impact on the state of a dialog.  In that sense,
   it is like a re-INVITE, but unlike re-INVITE, it can be sent before
   the initial INVITE has been completed.  This makes it very useful for
   updating session parameters within early dialogs.
Sehen wir das mit dem "State of dialog" mal nicht so eng, auch das Lancom ist freundlich und und reicht das UPDATE durch:

Code: Alles auswählen

[SIP-Packet] 2019/02/21 19:15:34,864 [Packet]: 
Sending datagram (624 Bytes) from 172.16.100.1:5060 to 172.16.100.15:5060 using UDP (RtgTag 1):
UPDATE sip:<Teilnehmer/Benutzer>@172.16.100.15:5060 SIP/2.0
Via: SIP/2.0/UDP 172.16.100.1:5060;branch=z9hG4bK-0d03ecad-5e192083;rport
From: <sip:<Gegenstelle>@172.16.100.1;user=phone>;tag=-427150099-1030812341
To: <sip:<Teilnehmer/Benutzer>@172.16.100.1;user=phone>;tag=1900459748
Call-ID: 2650823467@00a057406ea8
CSeq: 2 UPDATE
Max-Forwards: 70
User-Agent: LANCOM 1906VA (over ISDN) / 10.20.0367 / 06.02.2019
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REFER, SUBSCRIBE, NOTIFY, REGISTER, PRACK
Supported: timer
Contact: <sip:<Gegenstelle>@172.16.100.1:5060;transport=UDP>
Session-Expires: 1800;refresher=uac
Min-SE: 900
Content-Length: 0
Nur, warum reicht das Lancom hier eigentlich durch? Im "Allow"des Teilnehmers ist kein UPDATE enthalten (s.o. 3.CODE-Block von oben), das kann nur schief gehen...

Code: Alles auswählen

[SIP-Packet] 2019/02/21 19:15:34,916 [Packet]: 
Receiving datagram (391 Bytes) at 172.16.100.1:5060 from 172.16.100.15:5060 using UDP (RtgTag 1):
SIP/2.0 405 Method Not Allowed
Via: SIP/2.0/UDP 172.16.100.1:5060;branch=z9hG4bK-0d03ecad-5e192083;rport=5060
From: <sip:<Gegenstelle>@172.16.100.1;user=phone>;tag=-427150099-1030812341
To: <sip:<Teilnehmer/Benutzer>@172.16.100.1;user=phone>;tag=1900459748
Call-ID: 2650823467@00a057406ea8
CSeq: 2 UPDATE
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0
Tja, wer nicht hören kann... Nun nimmt das Schicksal des unbändigen Durchreichens seinen Lauf:

Code: Alles auswählen

[SIP-Packet] 2019/02/21 19:15:34,916 [Packet]: 
Sending datagram (692 Bytes) from <Lancom-WAN-IP4>:11216 to <SIP-Provider-IP4>:5060 using UDP (RtgTag 0):
SIP/2.0 405 Method Not Allowed
Via: SIP/2.0/UDP <SIP-Provider-IP4>:5060;branch=z9hG4bKg3Zqkv7is5lkl6o56venov1emuvgq7hrz;received=<SIP-Provider-IP4>
From: <sip:SIP-ID-Gegenstelle@ims.vodafone.de;user=phone>;tag=h7g4Esbg_p65551t1550772025m527836c379417020s1_1068870541-1353243588
To: <sip:<SIP-ID-Extern>@hmbsx001.ngn.vodafone.de;user=phone>;tag=2083377501--1745710281
Call-ID: p65551t1550772025m527836c379417020s2
CSeq: 2 UPDATE
User-Agent: LANCOM 1906VA (over ISDN) / 10.20.0367 / 06.02.2019
Server: Lancom
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE
Supported: timer
Contact: <sip:<SIP-ID-Extern>@<Lancom-WAN-IP4>:11216;transport=UDP>
Content-Length: 0
Warum dies? Das Lancom hatte gegenüber dem SIP-Provider behautet, es könne UPDATEs verarbeiten, kann es auch, sollte es dann auch tun. Der Provider schickt nun, er hätte es besser gleich getan, ein INVITE. Das Lancom antwortet mit einem Trying.

Code: Alles auswählen

[SIP-Packet] 2019/02/21 19:15:34,938 [Packet]: 
Receiving datagram (993 Bytes) at <Lancom-WAN-IP4>:11216 from <SIP-Provider-IP4>:5060 using UDP (RtgTag 0):
INVITE sip:<SIP-ID-Extern>@<Lancom-WAN-IP4>:11216;transport=udp SIP/2.0
Max-Forwards: 68
Via: SIP/2.0/UDP <SIP-Provider-IP4>:5060;branch=z9hG4bKg3Zqkv7iyffhltmj6zodrdp7kp168yrbz
To: <sip:<SIP-ID-Extern>@hmbsx001.ngn.vodafone.de;user=phone>;tag=2083377501--1745710281
From: <sip:SIP-ID-Gegenstelle@ims.vodafone.de;user=phone>;tag=h7g4Esbg_p65551t1550772025m527836c379417020s1_1068870541-1353243588
Call-ID: p65551t1550772025m527836c379417020s2
CSeq: 3 INVITE
Contact: <sip:sgc_c@<SIP-Provider-IP4>;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: 215
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE, INFO, INVITE, ACK, OPTIONS, CANCEL, BYE

v=0
o=- 858566146 1068870226 IN IP4 <SIP-Provider-IP4>
s=IMSS
c=IN IP4 <SIP-Provider IP>
t=0 0
m=audio 37020 RTP/AVP 8 98 99
a=rtpmap:98 telephone-event/8000
a=rtpmap:99 telephone-event/16000
a=maxptime:20
a=ptime:20

[SIP-Packet] 2019/02/21 19:15:34,938 [Packet]: 
Sending datagram (632 Bytes) from <Lancom-WAN-IP4>:11216 to <SIP-Provider-IP4>:5060 using UDP (RtgTag 0):
SIP/2.0 100 Trying
Via: SIP/2.0/UDP <SIP-Provider-IP4>:5060;branch=z9hG4bKg3Zqkv7iyffhltmj6zodrdp7kp168yrbz;received=<SIP-Provider-IP4>
From: <sip:SIP-ID-Gegenstelle@ims.vodafone.de;user=phone>;tag=h7g4Esbg_p65551t1550772025m527836c379417020s1_1068870541-1353243588
To: <sip:<SIP-ID-Extern>@hmbsx001.ngn.vodafone.de;user=phone>;tag=2083377501--1745710281
Call-ID: p65551t1550772025m527836c379417020s2
CSeq: 3 INVITE
User-Agent: LANCOM 1906VA (over ISDN) / 10.20.0367 / 06.02.2019
Server: Lancom
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE
Supported: 100rel,replaces,timer
Content-Length: 0
Nun wird das INVITE nach Intern zum Teilnehmer/Benutzer weitergeleitet, der seinerseits mit einem Trying antwortet:

Code: Alles auswählen

[SIP-Packet] 2019/02/21 19:15:34,939 [Packet]: 
Sending datagram (931 Bytes) from 172.16.100.1:5060 to 172.16.100.15:5060 using UDP (RtgTag 1):
INVITE sip:<Teilnehmer/Benutzer>@172.16.100.15:5060 SIP/2.0
Via: SIP/2.0/UDP 172.16.100.1:5060;branch=z9hG4bK-4825760e-df0109fd;rport
From: <sip:<Gegenstelle>@172.16.100.1;user=phone>;tag=-427150099-1030812341
To: <sip:<Teilnehmer/Benutzer>@172.16.100.1;user=phone>;tag=1900459748
Call-ID: 2650823467@00a057406ea8
CSeq: 3 INVITE
Max-Forwards: 70
User-Agent: LANCOM 1906VA (over ISDN) / 10.20.0367 / 06.02.2019
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REFER, SUBSCRIBE, NOTIFY, REGISTER, PRACK
Supported: 100rel,timer
Contact: <sip:<Gegenstelle>@172.16.100.1:5060;transport=UDP>
Session-Expires: 1800;refresher=uac
Min-SE: 900
Content-Type: application/sdp
Content-Length: 267

v=0
o=- 2730012341 2730012343 IN IP4 172.16.100.1
s=call
c=IN IP4 172.16.100.1
t=0 0
m=audio 16352 RTP/AVP 8 98 99
a=rtpmap:8 PCMA/8000
a=rtpmap:98 telephone-event/8000
a=rtpmap:99 telephone-event/16000
a=fmtp:98 0-15
a=sendrecv
a=ptime:20
a=maxptime:20

[SIP-Packet] 2019/02/21 19:15:35,029 [Packet]: 
Receiving datagram (348 Bytes) at 172.16.100.1:5060 from 172.16.100.15:5060 using UDP (RtgTag 1):
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 172.16.100.1:5060;branch=z9hG4bK-4825760e-df0109fd;rport=5060
From: <sip:<Gegenstelle>@172.16.100.1;user=phone>;tag=-427150099-1030812341
To: <sip:<Teilnehmer/Benutzer>@172.16.100.1;user=phone>;tag=1900459748
Call-ID: 2650823467@00a057406ea8
CSeq: 3 INVITE
Contact: <sip:<Teilnehmer/Benutzer>@172.16.100.15:5060>
Content-Length: 0
Im letzten Aufzug folgen die OKs des Teilnehmers/Benutzers und deren Weiterleitung durch das Lancom an den Provider:

Code: Alles auswählen

[SIP-Packet] 2019/02/21 19:15:35,069 [Packet]: 
Receiving datagram (671 Bytes) at 172.16.100.1:5060 from 172.16.100.15:5060 using UDP (RtgTag 1):
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.16.100.1:5060;branch=z9hG4bK-4825760e-df0109fd;rport=5060
From: <sip:<Gegenstelle>@172.16.100.1;user=phone>;tag=-427150099-1030812341
To: <sip:<Teilnehmer/Benutzer>@172.16.100.1;user=phone>;tag=1900459748
Call-ID: 2650823467@00a057406ea8
CSeq: 3 INVITE
Contact: <sip:<Teilnehmer/Benutzer>@172.16.100.15:5060>
Supported: replaces
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, REFER, SUBSCRIBE, NOTIFY
Content-Type: application/sdp
Content-Length: 199

v=0
o=123456 5016 11 IN IP4 172.16.100.15
s=Mapping
c=IN IP4 172.16.100.15
t=0 0
m=audio 5016 RTP/AVP 8 99
a=rtpmap:8 PCMA/8000
a=rtpmap:99 telephone-event/8000
a=fmtp:99 0-16
a=sendrecv

[SIP-Packet] 2019/02/21 19:15:35,077 [Packet]: 
Sending datagram (977 Bytes) from <Lancom-WAN-IP4>:11216 to <SIP-Provider-IP4>:5060 using UDP (RtgTag 0):
SIP/2.0 200 OK
Via: SIP/2.0/UDP <SIP-Provider-IP4>:5060;branch=z9hG4bKg3Zqkv7iyffhltmj6zodrdp7kp168yrbz;received=<SIP-Provider-IP4>
From: <sip:SIP-ID-Gegenstelle@ims.vodafone.de;user=phone>;tag=h7g4Esbg_p65551t1550772025m527836c379417020s1_1068870541-1353243588
To: <sip:<SIP-ID-Extern>@hmbsx001.ngn.vodafone.de;user=phone>;tag=2083377501--1745710281
Call-ID: p65551t1550772025m527836c379417020s2
CSeq: 3 INVITE
User-Agent: LANCOM 1906VA (over ISDN) / 10.20.0367 / 06.02.2019
Server: Lancom
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE
Supported: 100rel,replaces,timer
Contact: <sip:<SIP-ID-Extern>@<Lancom-WAN-IP4>:11216;transport=UDP>
Session-Expires: 1800;refresher=uac
Require: timer
Content-Type: application/sdp
Content-Length: 199

v=0
o=- 0 1 IN IP4 <Lancom-WAN-IP4>
s=call
c=IN IP4 <Lancom-WAN-IP4>
t=0 0
m=audio 9534 RTP/AVP 8 99
a=rtpmap:8 PCMA/8000
a=rtpmap:99 telephone-event/8000
a=fmtp:99 0-15
a=sendrecv
a=ptime:20
Der Teilnehmer/Benutzer setzt nun mehrfach verzweifelt weitere OKs ab, die auch druchgeleitet werden, bis mit

Code: Alles auswählen

[SIP-Packet] 2019/02/21 19:16:07,249 [Packet]: 
Receiving datagram (449 Bytes) at 172.16.100.1:5060 from 172.16.100.15:5060 using UDP (RtgTag 1):
BYE sip:<Gegenstelle>@172.16.100.1:5060;transport=UDP SIP/2.0
Via: SIP/2.0/UDP 172.16.100.15:5060;branch=z9hG4bK74566e8bbbc3ef1073d3c6bdc224026d;rport
From: <sip:<Teilnehmer/Benutzer>@172.16.100.1;user=phone>;tag=1900459748
To: <sip:<Gegenstelle>@172.16.100.1;user=phone>;tag=-427150099-1030812341
Call-ID: 2650823467@00a057406ea8
CSeq: 2 BYE
Contact: <sip:<Teilnehmer/Benutzer>@172.16.100.15:5060>
Max-Forwards: 70
User-Agent: S685 IP/022270000000
Content-Length: 0


[SIP-Packet] 2019/02/21 19:16:07,256 [Packet]: 
Sending datagram (520 Bytes) from 172.16.100.1:5060 to 172.16.100.15:5060 using UDP (RtgTag 1):
SIP/2.0 200 OK
Via: SIP/2.0/UDP 172.16.100.15:5060;branch=z9hG4bK74566e8bbbc3ef1073d3c6bdc224026d;received=172.16.100.15;rport=5060
From: <sip:<Teilnehmer/Benutzer>@172.16.100.1;user=phone>;tag=1900459748
To: <sip:<Gegenstelle>@172.16.100.1;user=phone>;tag=-427150099-1030812341
Call-ID: 2650823467@00a057406ea8
CSeq: 2 BYE
User-Agent: LANCOM 1906VA (over ISDN) / 10.20.0367 / 06.02.2019
Server: Lancom
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REFER, SUBSCRIBE, NOTIFY, REGISTER, PRACK
Supported: timer
Content-Length: 0


[SIP-Packet] 2019/02/21 19:16:07,257 [Packet]: 
Sending datagram (617 Bytes) from <Lancom-WAN-IP4>:11216 to <SIP-Provider-IP4>:5060 using UDP (RtgTag 0):
BYE sip:sgc_c@<SIP-Provider-IP4>;transport=udp SIP/2.0
Via: SIP/2.0/UDP <Lancom-WAN-IP4>:11216;branch=z9hG4bK-a3d4e6b8-a25d8bf0;rport
From: <sip:<SIP-ID-Extern>@hmbsx001.ngn.vodafone.de;user=phone>;tag=2083377501--1745710281
To: <sip:SIP-ID-Gegenstelle@ims.vodafone.de;user=phone>;tag=h7g4Esbg_p65551t1550772025m527836c379417020s1_1068870541-1353243588
Call-ID: p65551t1550772025m527836c379417020s2
CSeq: 1 BYE
Max-Forwards: 70
User-Agent: LANCOM 1906VA (over ISDN) / 10.20.0367 / 06.02.2019
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE
Supported: timer
Content-Length: 0


[SIP-Packet] 2019/02/21 19:16:11,257 [Packet]: 
Sending datagram (698 Bytes) from <Lancom-WAN-IP4>:11216 to <SIP-Provider-IP4>:5060 using UDP (RtgTag 0):
SIP/2.0 200 OK
Via: SIP/2.0/UDP <Lancom-WAN-IP4>:11216;branch=z9hG4bK-a3d4e6b8-a25d8bf0;rport
From: <sip:SIP-ID-Gegenstelle@ims.vodafone.de;user=phone>;tag=h7g4Esbg_p65551t1550772025m527836c379417020s1_1068870541-1353243588
To: <sip:<SIP-ID-Extern>@hmbsx001.ngn.vodafone.de;user=phone>;tag=2083377501--1745710281
Call-ID: p65551t1550772025m527836c379417020s2
CSeq: 3 BYE
User-Agent: LANCOM 1906VA (over ISDN) / 10.20.0367 / 06.02.2019
Server: Lancom
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE
Supported: timer
Contact: <sip:<SIP-ID-Extern>@<Lancom-WAN-IP4>:11216;transport=UDP>
Session-Expires: 1800;refresher=uac
Require: timer
Content-Length: 0


[SIP-Packet] 2019/02/21 19:16:15,258 [Packet]: 
Sending datagram (698 Bytes) from <Lancom-WAN-IP4>:11216 to <SIP-Provider-IP4>:5060 using UDP (RtgTag 0):
SIP/2.0 200 OK
Via: SIP/2.0/UDP <Lancom-WAN-IP4>:11216;branch=z9hG4bK-a3d4e6b8-a25d8bf0;rport
From: <sip:SIP-ID-Gegenstelle@ims.vodafone.de;user=phone>;tag=h7g4Esbg_p65551t1550772025m527836c379417020s1_1068870541-1353243588
To: <sip:<SIP-ID-Extern>@hmbsx001.ngn.vodafone.de;user=phone>;tag=2083377501--1745710281
Call-ID: p65551t1550772025m527836c379417020s2
CSeq: 3 BYE
User-Agent: LANCOM 1906VA (over ISDN) / 10.20.0367 / 06.02.2019
Server: Lancom
Allow: REGISTER, REFER, NOTIFY, SUBSCRIBE, PRACK, UPDATE, INVITE, ACK, OPTIONS, CANCEL, BYE
Supported: timer
Contact: <sip:<SIP-ID-Extern>@<Lancom-WAN-IP4>:11216;transport=UDP>
Session-Expires: 1800;refresher=uac
Require: timer
Content-Length: 0
der Vorhang fällt und ein verdutzter Teilnehmer am Apparat zurückbleibt.

Und nun? Ich meine ja, da wäre irgendwo auf ein OK ein ACK angebracht - bei einem Trying, aber bei der verhunzten Druchleiterei bin ich mir nicht sicher.

Was ist nun der Unterschied zur 10.20.0336?

Er liegt im Verhalten des Lancom, es leitet nicht stumpf Anfragen durch, sondern setzt diese in den bisher bekannten LANCOM-SIP-Standard um.
Mit der Durchleiterei wird sicher manches leichter, wenn es um SIP-Kommunikation geht. Ob ich das gut finde, wie es gelöst ist? Will ich lieber nicht sagen... Ein sehr gut dokumentierter LANCOM-SIP-Standard könnte aber allen helfen, denn wir wissen, wie unterschiedlich SIP in den Weiten des Internet interpretiert wird.

Ich bin noch die Antwort schuldig, warum es mit 10.20.0336 geht. Ganz einfach: RFC 4028 findet intern keine Anwendung. Will heißen: Es gab intern kein "Session-Expires" oder "Min-SE".

Gruß Fully

Ob eine 10.20.04xx das besser kann?
Fully
Beiträge: 113
Registriert: 19 Apr 2007, 13:40

Re: Gelöst: SIP: 10.20.0367, Gesprächsabbruch nach 15 Minuten

Beitrag von Fully »

Moin,

das Problem ist mit der 10.20RU4 gelöst.

Die Zeichenfolge im "Allow:" des "SIP/2.0 200 OK" an den Provider ist nun an das angepasst, was der Teilnehmer/Benutzer bereits an das Lancom übermittelte. Die SIP-Pakete werden also korrekt durchgereicht, wenn kein UPDATE angeboten wird, wird das auch so weitergegeben. :D

Damit kommt vom Provider nun auch kein UPDATE sondern ein re-INVITE, welches ebenfalls korrekt durchgereicht wird. Ob das Lancom mit einem re-INVITE, welches selbst verarbeitet werden muss (ISDN/Analog), nun auch korrekt umgeht, konnte ich noch nicht prüfen (das war in der hier aufgemachten Fehlerbeschreibung auch nicht thematisiert).

Mit Dank und Gruß

Fully
Antworten