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
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
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
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
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.
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
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
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
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
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
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
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
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?