folgender Beitrag fasst meine Erkenntnisse zu einem Problem zusammen, deren Ursache bei den Providern liegt. Er hat daher informativen Charakter und ist keine Bugmeldung (jedenfalls nicht an LANCOM), obwohl ich eine Stelle ganz gerne von Georg gelesen habe würde, weil man an der Stelle das Verhalten des LANCOMs möglicherweise auch optimieren könnte.
Kurz-Problembeschreibung: Anrufer A ruft Anrufer B an. B stellt das Telefongespräch an C durch, wobei C in der gleichen Firma sitzt und nicht extern. A und C hören sich nun nicht. Ursache: Re-INVITE wird vom Provider falsch beantwortet. Dieses Problem tritt nicht grundsätzlich auf, sondern ist abhängig davon bei welchem Provider Anrufer A ist. Ist A bei Kabel Deutschland (Vodafone) tritt das Problem grundsätzlich auf. Vereinzelt tritt es anscheinend auch bei Kunden der Telekom auf, hier ist ein genauer Zusammenhang (Plattform/Endgerät) noch nicht geklärt.
Ausführliche, konkrete Problembeschreibung eines Beispielfalles: Anrufer A bei Kabel Deutschland/Vodafone ruft bei einer Firma an. Diese Firma hat einen SIP-Trunk bei der Deutschen Telekom (wobei das Problem auch in Filialen der Firma mit einem normalen SIP-Account auftritt). Dieser SIP-Trunk ist im LANCOM-Router (LCOS 10.12.0284) terminiert, also eingetragen. Vom LANCOM aus geht eine SIP-Gateway-Leitung zur Telefonanlage der Firma in der Zentrale, einer NetPhone. Hier sieht man den eingehenden Ruf von Teilnehmer A am LANCOM-Router:
Code: Alles auswählen
[SIP-Packet] 2018/03/09 11:59:08,610 [Packet]:
Receiving datagram (1269 Bytes) at 87.139.174.89:11901 from 217.0.26.131:5060 using TCP (RtgTag 0):
INVITE sip:+493088888880@87.139.174.89:11901;transport=TCP SIP/2.0\r\n
Via: SIP/2.0/TCP 217.0.26.131:5060;branch=z9hG4bKc73c9bf73038cf2e3e59007d95339b34.089639a4\r\n
Record-Route: <sip:reg.sip-trunk.telekom.de;transport=tcp;lr>\r\n
Max-Forwards: 63\r\n
To: <sip:+4930888888888@telekom.de;user=phone>\r\n
From: <sip:+493022222222@sip-trunk.telekom.de;user=phone>;tag=2980fb74\r\n
Call-ID: 0ef929e159e6a2e8@62.156.103.71\r\n
Contact: <sip:9bdKLvlLdYhpyCZBm/lMgoRmatB2wDmwkRnG4KIiTXHPVvPsir3kWtOM1oH7Gr6m@th1>\r\n
Supported: histinfo,timer\r\n
Session-Expires: 1800;refresher=uac\r\n
CSeq: 10420402 INVITE\r\n
Allow: ACK, BYE, CANCEL, INFO, INVITE, OPTIONS, PRACK, REFER, REGISTER, UPDATE\r\n
Expires: 125\r\n
Min-SE: 900\r\n
P-Asserted-Identity: <sip:+493022222222@sip-trunk.telekom.de;user=phone>\r\n
P-Called-Party-ID: <sip:+4930888888888@sip-trunk.telekom.de;user=phone>\r\n
Content-Type: application/sdp\r\n
Content-Disposition: session\r\n
Content-Length: 357\r\n
\r\n
v=0\r\n
o=- 904476806 0 IN IP4 217.0.26.131\r\n
s=on transit\r\n
c=IN IP4 217.0.132.86\r\n
t=0 0\r\n
m=audio 25130 RTP/AVP 8 0 18 99 98 97 96 101\r\n
a=rtpmap:0 PCMU/8000\r\n
a=rtpmap:18 G729/8000\r\n
a=rtpmap:99 G726-16/8000\r\n
a=rtpmap:98 G726-24/8000\r\n
a=rtpmap:97 G726-32/8000\r\n
a=rtpmap:96 G726-40/8000\r\n
a=rtpmap:101 telephone-event/8000\r\n
a=fmtp:101 0-15\r\n
a=sendrecv\r\n
a=ptime:20\r\n
[SIP-Packet] 2018/03/09 11:59:08,612 [Packet]:
Sending datagram (582 Bytes) from 87.139.174.89:11901 to 217.0.26.131:5060 using TCP (RtgTag 0):
SIP/2.0 100 Trying\r\n
Via: SIP/2.0/TCP 217.0.26.131:5060;branch=z9hG4bKc73c9bf73038cf2e3e59007d95339b34.089639a4;received=217.0.26.131\r\n
Record-Route: <sip:reg.sip-trunk.telekom.de;transport=tcp;lr>\r\n
From: <sip:+493022222222@sip-trunk.telekom.de;user=phone>;tag=2980fb74\r\n
To: <sip:+4930888888888@telekom.de;user=phone>;tag=397133653--857004840\r\n
Call-ID: 0ef929e159e6a2e8@62.156.103.71\r\n
CSeq: 10420402 INVITE\r\n
User-Agent: LANCOM 1783VA (over ISDN) / 10.12.0284 / 23.02.2018\r\n
Server: Lancom\r\n
Allow: ACK, BYE, CANCEL, INVITE, OPTIONS, PRACK, REFER, REGISTER, UPDATE\r\n
Content-Length: 0\r\n
\r\n
Code: Alles auswählen
[SIP-Packet] 2018/03/09 11:59:09,370 [Packet]:
Sending datagram (1215 Bytes) from 192.168.193.1:14851 to 172.20.172.223:5060 using UDP (RtgTag 193):
INVITE sip:+4930888888888@172.20.172.223 SIP/2.0\r\n
Via: SIP/2.0/UDP 192.168.193.1:14851;branch=z9hG4bK-662d04ac-f7bd9b3d;rport\r\n
From: <sip:SIP88888880@172.20.172.223>;tag=1995771045-809459953\r\n
To: <sip:+4930888888888@telekom.de;user=phone>\r\n
Call-ID: 2480571498@00a0572e9685\r\n
CSeq: 100 INVITE\r\n
Max-Forwards: 70\r\n
User-Agent: LANCOM 1783VA (over ISDN) / 10.12.0284 / 23.02.2018\r\n
Allow: ACK, BYE, CANCEL, INVITE, OPTIONS, PRACK, REFER, UPDATE\r\n
Supported: 100rel\r\n
Contact: <sip:SIP88888880@192.168.193.1:14851;transport=UDP>\r\n
P-Preferred-Identity: <sip:+493022222222@sip-trunk.telekom.de;user=phone>\r\n
Authorization: Digest username="SIP88888880", realm="172.20.172.223", algorithm=MD5, uri="sip:+4930888888888@172.20.172.223", nonce="279991588:374b05270d872924780c6c8ec28d4da8", response="b69db4ca77604ad21a825f432beea7f2"\r\n
Content-Type: application/sdp\r\n
Content-Length: 349\r\n
\r\n
v=0\r\n
o=- 1240285749 1240285749 IN IP4 192.168.193.1\r\n
s=call\r\n
c=IN IP4 192.168.193.1\r\n
t=0 0\r\n
m=audio 9684 RTP/AVP 8 0 18 99 98 97 96\r\n
a=rtpmap:8 PCMA/8000\r\n
a=rtpmap:0 PCMU/8000\r\n
a=rtpmap:18 G729/8000\r\n
a=rtpmap:99 G726-16/8000\r\n
a=rtpmap:98 G726-24/8000\r\n
a=rtpmap:97 G726-32/8000\r\n
a=rtpmap:96 G726-40/8000\r\n
a=fmtp:18 annexb=no\r\n
a=sendrecv\r\n
a=ptime:20\r\n
[SIP-Packet] 2018/03/09 11:59:09,389 [Packet]:
Receiving datagram (419 Bytes) at 192.168.193.1:14851 from 172.20.172.223:5060 using UDP (RtgTag 193):
SIP/2.0 100 Trying\r\n
Via: SIP/2.0/UDP 192.168.193.1:14851;branch=z9hG4bK-662d04ac-f7bd9b3d;rport=14851\r\n
To: <sip:+4930888888888@telekom.de;user=phone>\r\n
From: <sip:SIP88888880@172.20.172.223>;tag=1995771045-809459953\r\n
Call-ID: 2480571498@00a0572e9685\r\n
CSeq: 100 INVITE\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, INFO, SUBSCRIBE, UPDATE\r\n
User-Agent: T-Com IpPbxSrv/11.10.0.325\r\n
Content-Length: 0\r\n
\r\n
[SIP-Packet] 2018/03/09 11:59:09,456 [Packet]:
Receiving datagram (605 Bytes) at 192.168.193.1:14851 from 172.20.172.223:5060 using UDP (RtgTag 193):
SIP/2.0 180 Ringing\r\n
Via: SIP/2.0/UDP 192.168.193.1:14851;branch=z9hG4bK-662d04ac-f7bd9b3d;rport=14851\r\n
Contact: <sip:172.20.172.223:5060;transport=udp>\r\n
To: "BLN-ANM-188"<sip:+4930888888888@telekom.de;user=phone>;tag=7d39093f\r\n
From: <sip:SIP88888880@172.20.172.223>;tag=1995771045-809459953\r\n
Call-ID: 2480571498@00a0572e9685\r\n
CSeq: 100 INVITE\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, INFO, SUBSCRIBE, UPDATE\r\n
User-Agent: T-Com IpPbxSrv/11.10.0.325\r\n
X-IPPBXServerCallContext: 8m4znir35vil\r\n
X-IPPBXCalledNumber: +4930888888888\r\n
X-IPPBXCalledName: BLN-ANM-188\r\n
Content-Length: 0\r\n
\r\n
Code: Alles auswählen
[SIP-Packet] 2018/03/09 11:59:09,457 [Packet]:
Sending datagram (583 Bytes) from 87.139.174.89:11901 to 217.0.26.131:5060 using TCP (RtgTag 0):
SIP/2.0 180 Ringing\r\n
Via: SIP/2.0/TCP 217.0.26.131:5060;branch=z9hG4bKc73c9bf73038cf2e3e59007d95339b34.089639a4;received=217.0.26.131\r\n
Record-Route: <sip:reg.sip-trunk.telekom.de;transport=tcp;lr>\r\n
From: <sip:+493022222222@sip-trunk.telekom.de;user=phone>;tag=2980fb74\r\n
To: <sip:+4930888888888@telekom.de;user=phone>;tag=397133653--857004840\r\n
Call-ID: 0ef929e159e6a2e8@62.156.103.71\r\n
CSeq: 10420402 INVITE\r\n
User-Agent: LANCOM 1783VA (over ISDN) / 10.12.0284 / 23.02.2018\r\n
Server: Lancom\r\n
Allow: ACK, BYE, CANCEL, INVITE, OPTIONS, PRACK, REFER, REGISTER, UPDATE\r\n
Content-Length: 0\r\n
\r\n
Code: Alles auswählen
[SIP-Packet] 2018/03/09 11:59:11,464 [Packet]:
Receiving datagram (678 Bytes) at 192.168.193.1:14851 from 172.20.172.223:5060 using UDP (RtgTag 193):
SIP/2.0 200 OK\r\n
Via: SIP/2.0/UDP 192.168.193.1:14851;branch=z9hG4bK-662d04ac-f7bd9b3d;rport=14851\r\n
Contact: <sip:172.20.172.223:5060;transport=udp>\r\n
To: "BLN-ANM-188"<sip:+4930888888888@telekom.de;user=phone>;tag=7d39093f\r\n
From: <sip:SIP88888880@172.20.172.223>;tag=1995771045-809459953\r\n
Call-ID: 2480571498@00a0572e9685\r\n
CSeq: 100 INVITE\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, INFO, SUBSCRIBE, UPDATE\r\n
Content-Type: application/sdp\r\n
User-Agent: T-Com IpPbxSrv/11.10.0.325\r\n
Content-Length: 154\r\n
\r\n
v=0\r\n
o=- 2566215202 1 IN IP4 172.20.172.223\r\n
s=T-Com IpPbxSrv\r\n
c=IN IP4 172.20.172.223\r\n
t=0 0\r\n
m=audio 51260 RTP/AVP 8\r\n
a=rtpmap:8 PCMA/8000\r\n
a=ptime:20\r\n
[SIP-Packet] 2018/03/09 11:59:11,467 [Packet]:
Sending datagram (876 Bytes) from 87.139.174.89:11901 to 217.0.26.131:5060 using TCP (RtgTag 0):
SIP/2.0 200 OK\r\n
Via: SIP/2.0/TCP 217.0.26.131:5060;branch=z9hG4bKc73c9bf73038cf2e3e59007d95339b34.089639a4;received=217.0.26.131\r\n
Record-Route: <sip:reg.sip-trunk.telekom.de;transport=tcp;lr>\r\n
From: <sip:+493022222222@sip-trunk.telekom.de;user=phone>;tag=2980fb74\r\n
To: <sip:+4930888888888@telekom.de;user=phone>;tag=397133653--857004840\r\n
Call-ID: 0ef929e159e6a2e8@62.156.103.71\r\n
CSeq: 10420402 INVITE\r\n
User-Agent: LANCOM 1783VA (over ISDN) / 10.12.0284 / 23.02.2018\r\n
Server: Lancom\r\n
Allow: ACK, BYE, CANCEL, INVITE, OPTIONS, PRACK, REFER, REGISTER, UPDATE\r\n
Contact: <sip:+493088888880@87.139.174.89:11901;transport=TCP>\r\n
Content-Type: application/sdp\r\n
Content-Length: 201\r\n
\r\n
v=0\r\n
o=- 0 0 IN IP4 87.139.174.89\r\n
s=call\r\n
c=IN IP4 87.139.174.89\r\n
t=0 0\r\n
m=audio 11306 RTP/AVP 8 101\r\n
a=rtpmap:8 PCMA/8000\r\n
a=rtpmap:101 telephone-event/8000\r\n
a=fmtp:101 0-15\r\n
a=sendrecv\r\n
a=ptime:20\r\n
[SIP-Packet] 2018/03/09 11:59:11,593 [Packet]:
Receiving datagram (625 Bytes) at 87.139.174.89:11901 from 217.0.26.131:5060 using TCP (RtgTag 0):
ACK sip:+493088888880@87.139.174.89:11901;transport=TCP SIP/2.0\r\n
Via: SIP/2.0/TCP 217.0.26.131;branch=z9hG4bKc73c9bf73038cf2e3e59007d95339b34.790c2172\r\n
Record-Route: <sip:reg.sip-trunk.telekom.de;transport=tcp;lr>\r\n
Max-Forwards: 64\r\n
To: <sip:+4930888888888@telekom.de;user=phone>;tag=397133653--857004840\r\n
From: <sip:+493022222222@sip-trunk.telekom.de;user=phone>;tag=2980fb74\r\n
Call-ID: 0ef929e159e6a2e8@62.156.103.71\r\n
Contact: <sip:9bdKLvlLdYhpyCZBm/lMgoRmatB2wDmwkRnG4KIiTXHPVvPsir3kWtOM1oH7Gr6m@th1>\r\n
CSeq: 10420402 ACK\r\n
Allow: ACK, BYE, CANCEL, INFO, INVITE, OPTIONS, PRACK, REFER, REGISTER, UPDATE\r\n
Content-Length: 0\r\n
\r\n
[SIP-Packet] 2018/03/09 11:59:11,595 [Packet]:
Sending datagram (690 Bytes) from 192.168.193.1:14851 to 172.20.172.223:5060 using UDP (RtgTag 193):
ACK sip:172.20.172.223:5060;transport=udp SIP/2.0\r\n
Via: SIP/2.0/UDP 192.168.193.1:14851;branch=z9hG4bK-d93901da-33a8cbf5;rport\r\n
From: <sip:SIP88888880@172.20.172.223>;tag=1995771045-809459953\r\n
To: <sip:+4930888888888@telekom.de;user=phone>;tag=7d39093f\r\n
Call-ID: 2480571498@00a0572e9685\r\n
CSeq: 100 ACK\r\n
Max-Forwards: 70\r\n
User-Agent: LANCOM 1783VA (over ISDN) / 10.12.0284 / 23.02.2018\r\n
Allow: ACK, BYE, CANCEL, INVITE, OPTIONS, PRACK, REFER, UPDATE\r\n
Authorization: Digest username="SIP88888880", realm="172.20.172.223", algorithm=MD5, uri="sip:+4930888888888@172.20.172.223", nonce="279991588:374b05270d872924780c6c8ec28d4da8", response="b69db4ca77604ad21a825f432beea7f2"\r\n
Content-Length: 0\r\n
\r\n
Code: Alles auswählen
[SIP-Packet] 2018/03/09 12:00:44,077 [Packet]:
Receiving datagram (774 Bytes) at 192.168.193.1:14851 from 172.20.172.223:5060 using UDP (RtgTag 193):
REFER sip:SIP88888880@192.168.193.1:14851;transport=udp SIP/2.0\r\n
Via: SIP/2.0/UDP 172.20.172.223:5060;branch=z9hG4bK-d8754z-6d200864fb38e445-1---d8754z-;rport\r\n
Max-Forwards: 70\r\n
Contact: <sip:+4930888888888@172.20.172.223:5060;transport=udp>\r\n
To: <sip:SIP88888880@172.20.172.223>;tag=1995771045-809459953\r\n
From: <sip:+4930888888888@telekom.de;user=phone>;tag=7d39093f\r\n
Call-ID: 2480571498@00a0572e9685\r\n
CSeq: 1 REFER\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, INFO, SUBSCRIBE, UPDATE\r\n
Supported: timer\r\n
User-Agent: T-Com IpPbxSrv/11.10.0.325\r\n
Refer-To: "BLN-TELL-178"<sip:+4930888888878@172.20.172.223;user=phone?Replaces=x-ippbx-transferid%3Bto-tag%3D521%3Bfrom-tag%3D521>\r\n
Referred-By: <sip:+4930888888888@telekom.de;user=phone>\r\n
Content-Length: 0\r\n
\r\n
[SIP-Packet] 2018/03/09 12:00:44,077 [Packet]:
Sending datagram (549 Bytes) from 192.168.193.1:14851 to 172.20.172.223:5060 using UDP (RtgTag 193):
SIP/2.0 202 Accepted\r\n
Via: SIP/2.0/UDP 172.20.172.223:5060;branch=z9hG4bK-d8754z-6d200864fb38e445-1---d8754z-;received=172.20.172.223;rport=5060\r\n
From: <sip:+4930888888888@telekom.de;user=phone>;tag=7d39093f\r\n
To: <sip:SIP88888880@172.20.172.223>;tag=1995771045-809459953\r\n
Call-ID: 2480571498@00a0572e9685\r\n
CSeq: 1 REFER\r\n
User-Agent: LANCOM 1783VA (over ISDN) / 10.12.0284 / 23.02.2018\r\n
Server: Lancom\r\n
Allow: ACK, BYE, CANCEL, INVITE, OPTIONS, PRACK, REFER, UPDATE\r\n
Contact: <sip:+493022222222@192.168.193.1:14851;transport=UDP>\r\n
Content-Length: 0\r\n
\r\n
Code: Alles auswählen
[SIP-Packet] 2018/03/09 12:00:44,083 [Packet]:
Sending datagram (1250 Bytes) from 192.168.193.1:14851 to 172.20.172.223:5060 using UDP (RtgTag 193):
INVITE sip:+4930888888878@172.20.172.223 SIP/2.0\r\n
Via: SIP/2.0/UDP 192.168.193.1:14851;branch=z9hG4bK-e2facd45-ccfd82cc;rport\r\n
From: <sip:SIP88888880@172.20.172.223>;tag=715566522-284304425\r\n
To: <sip:+4930888888878@172.20.172.223;user=phone>\r\n
Call-ID: 522865208@00a0572e9685\r\n
CSeq: 100 INVITE\r\n
Max-Forwards: 70\r\n
User-Agent: LANCOM 1783VA (over ISDN) / 10.12.0284 / 23.02.2018\r\n
Supported: 100rel\r\n
Contact: <sip:SIP88888880@192.168.193.1:14851;transport=UDP>\r\n
Replaces: x-ippbx-transferid;from-tag=521;to-tag=521\r\n
Referred-By: <sip:+4930888888888@telekom.de>\r\n
P-Asserted-Identity: <sip:+493022222222@sip-trunk.telekom.de;user=phone>\r\n
Authorization: Digest username="SIP88888880", realm="172.20.172.223", algorithm=MD5, uri="sip:+4930888888878@172.20.172.223", nonce="279991588:374b05270d872924780c6c8ec28d4da8", response="a04a5e4749f451cc073c128309a6f908"\r\n
Content-Type: application/sdp\r\n
Content-Length: 347\r\n
\r\n
v=0\r\n
o=- 261432604 261432604 IN IP4 192.168.193.1\r\n
s=call\r\n
c=IN IP4 192.168.193.1\r\n
t=0 0\r\n
m=audio 8656 RTP/AVP 8 0 18 99 98 97 96\r\n
a=rtpmap:8 PCMA/8000\r\n
a=rtpmap:0 PCMU/8000\r\n
a=rtpmap:18 G729/8000\r\n
a=rtpmap:99 G726-16/8000\r\n
a=rtpmap:98 G726-24/8000\r\n
a=rtpmap:97 G726-32/8000\r\n
a=rtpmap:96 G726-40/8000\r\n
a=fmtp:18 annexb=no\r\n
a=sendrecv\r\n
a=ptime:20\r\n
[SIP-Packet] 2018/03/09 12:00:44,084 [Packet]:
Sending datagram (653 Bytes) from 192.168.193.1:14851 to 172.20.172.223:5060 using UDP (RtgTag 193):
NOTIFY sip:172.20.172.223:5060;transport=udp SIP/2.0\r\n
Via: SIP/2.0/UDP 192.168.193.1:14851;branch=z9hG4bK-855bb1c8-f94a4c2d;rport\r\n
From: <sip:SIP88888880@172.20.172.223>;tag=1995771045-809459953\r\n
To: <sip:+4930888888888@telekom.de;user=phone>;tag=7d39093f\r\n
Call-ID: 2480571498@00a0572e9685\r\n
CSeq: 101 NOTIFY\r\n
Max-Forwards: 70\r\n
User-Agent: LANCOM 1783VA (over ISDN) / 10.12.0284 / 23.02.2018\r\n
Allow: ACK, BYE, CANCEL, INVITE, OPTIONS, PRACK, REFER, UPDATE\r\n
Contact: <sip:SIP88888880@192.168.193.1:14851;transport=UDP>\r\n
Event: refer\r\n
Subscription-State: active;expires=600\r\n
Content-Type: message/sipfrag;version=2.0\r\n
Content-Length: 20\r\n
\r\n
SIP/2.0 100 Trying\r\n
[SIP-Packet] 2018/03/09 12:00:44,102 [Packet]:
Receiving datagram (421 Bytes) at 192.168.193.1:14851 from 172.20.172.223:5060 using UDP (RtgTag 193):
SIP/2.0 100 Trying\r\n
Via: SIP/2.0/UDP 192.168.193.1:14851;branch=z9hG4bK-e2facd45-ccfd82cc;rport=14851\r\n
To: <sip:+4930888888878@172.20.172.223;user=phone>\r\n
From: <sip:SIP88888880@172.20.172.223>;tag=715566522-284304425\r\n
Call-ID: 522865208@00a0572e9685\r\n
CSeq: 100 INVITE\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, INFO, SUBSCRIBE, UPDATE\r\n
User-Agent: T-Com IpPbxSrv/11.10.0.325\r\n
Content-Length: 0\r\n
\r\n
[SIP-Packet] 2018/03/09 12:00:44,104 [Packet]:
Receiving datagram (478 Bytes) at 192.168.193.1:14851 from 172.20.172.223:5060 using UDP (RtgTag 193):
SIP/2.0 200 OK\r\n
Via: SIP/2.0/UDP 192.168.193.1:14851;branch=z9hG4bK-855bb1c8-f94a4c2d;rport=14851\r\n
Contact: <sip:172.20.172.223:5060;transport=udp>\r\n
To: <sip:+4930888888888@telekom.de;user=phone>;tag=7d39093f\r\n
From: <sip:SIP88888880@172.20.172.223>;tag=1995771045-809459953\r\n
Call-ID: 2480571498@00a0572e9685\r\n
CSeq: 101 NOTIFY\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, INFO, SUBSCRIBE, UPDATE\r\n
User-Agent: T-Com IpPbxSrv/11.10.0.325\r\n
Content-Length: 0\r\n
\r\n
[SIP-Packet] 2018/03/09 12:00:44,123 [Packet]:
Receiving datagram (680 Bytes) at 192.168.193.1:14851 from 172.20.172.223:5060 using UDP (RtgTag 193):
SIP/2.0 200 OK\r\n
Via: SIP/2.0/UDP 192.168.193.1:14851;branch=z9hG4bK-e2facd45-ccfd82cc;rport=14851\r\n
Contact: <sip:172.20.172.223:5060;transport=udp>\r\n
To: "BLN-TELL-178"<sip:+4930888888878@172.20.172.223;user=phone>;tag=d559295b\r\n
From: <sip:SIP88888880@172.20.172.223>;tag=715566522-284304425\r\n
Call-ID: 522865208@00a0572e9685\r\n
CSeq: 100 INVITE\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, INFO, SUBSCRIBE, UPDATE\r\n
Content-Type: application/sdp\r\n
User-Agent: T-Com IpPbxSrv/11.10.0.325\r\n
Content-Length: 153\r\n
\r\n
v=0\r\n
o=- 2154867875 1 IN IP4 192.168.193.60\r\n
s=T-Com IpPbxSrv\r\n
c=IN IP4 192.168.193.60\r\n
t=0 0\r\n
m=audio 5004 RTP/AVP 8\r\n
a=rtpmap:8 PCMA/8000\r\n
a=ptime:20\r\n
[SIP-Packet] 2018/03/09 12:00:44,126 [Packet]:
Sending datagram (659 Bytes) from 192.168.193.1:14851 to 172.20.172.223:5060 using UDP (RtgTag 193):
NOTIFY sip:172.20.172.223:5060;transport=udp SIP/2.0\r\n
Via: SIP/2.0/UDP 192.168.193.1:14851;branch=z9hG4bK-d36e4857-73939297;rport\r\n
From: <sip:SIP88888880@172.20.172.223>;tag=1995771045-809459953\r\n
To: <sip:+4930888888888@telekom.de;user=phone>;tag=7d39093f\r\n
Call-ID: 2480571498@00a0572e9685\r\n
CSeq: 102 NOTIFY\r\n
Max-Forwards: 70\r\n
User-Agent: LANCOM 1783VA (over ISDN) / 10.12.0284 / 23.02.2018\r\n
Allow: ACK, BYE, CANCEL, INVITE, OPTIONS, PRACK, REFER, UPDATE\r\n
Contact: <sip:SIP88888880@192.168.193.1:14851;transport=UDP>\r\n
Event: refer\r\n
Subscription-State: terminated;reason=noresource\r\n
Content-Type: message/sipfrag;version=2.0\r\n
Content-Length: 16\r\n
\r\n
SIP/2.0 200 OK\r\n
Code: Alles auswählen
[SIP-Packet] 2018/03/09 12:00:44,127 [Packet]:
Sending datagram (1127 Bytes) from 87.139.174.89:11901 to 217.0.26.131:5060 using TCP (RtgTag 0):
INVITE sip:9bdKLvlLdYhpyCZBm/lMgoRmatB2wDmwkRnG4KIiTXHPVvPsir3kWtOM1oH7Gr6m@th1 SIP/2.0\r\n
Via: SIP/2.0/TCP 87.139.174.89:11901;branch=z9hG4bK-f788a36c-78e9d72d;rport\r\n
Route: <sip:reg.sip-trunk.telekom.de;transport=tcp;lr>\r\n
From: <sip:+4930888888888@telekom.de;user=phone>;tag=397133653--857004840\r\n
To: <sip:+493022222222@sip-trunk.telekom.de;user=phone>;tag=2980fb74\r\n
Call-ID: 0ef929e159e6a2e8@62.156.103.71\r\n
CSeq: 1 INVITE\r\n
Max-Forwards: 70\r\n
User-Agent: LANCOM 1783VA (over ISDN) / 10.12.0284 / 23.02.2018\r\n
Supported: 100rel\r\n
Contact: <sip:+493088888880@87.139.174.89:11901;transport=TCP>\r\n
Authorization: Digest username="551129101372", realm="sip-trunk.telekom.de", algorithm=MD5, uri="sip:9bdKLvlLdYhpyCZBm/lMgoRmatB2wDmwkRnG4KIiTXHPVvPsir3kWtOM1oH", nonce="871ec1a1404163fb871ec1a13931b3a11698255c15366f1986278adbe92c36f8", response="95fd4d38be3ab3df802f6d3b023338f3"\r\n
Content-Type: application/sdp\r\n
Content-Length: 201\r\n
\r\n
v=0\r\n
o=- 0 1 IN IP4 87.139.174.89\r\n
s=call\r\n
c=IN IP4 87.139.174.89\r\n
t=0 0\r\n
m=audio 11306 RTP/AVP 8 101\r\n
a=rtpmap:8 PCMA/8000\r\n
a=rtpmap:101 telephone-event/8000\r\n
a=fmtp:101 0-15\r\n
a=sendrecv\r\n
a=ptime:20\r\n
[SIP-Packet] 2018/03/09 12:00:44,144 [Packet]:
Receiving datagram (478 Bytes) at 192.168.193.1:14851 from 172.20.172.223:5060 using UDP (RtgTag 193):
SIP/2.0 200 OK\r\n
Via: SIP/2.0/UDP 192.168.193.1:14851;branch=z9hG4bK-d36e4857-73939297;rport=14851\r\n
Contact: <sip:172.20.172.223:5060;transport=udp>\r\n
To: <sip:+4930888888888@telekom.de;user=phone>;tag=7d39093f\r\n
From: <sip:SIP88888880@172.20.172.223>;tag=1995771045-809459953\r\n
Call-ID: 2480571498@00a0572e9685\r\n
CSeq: 102 NOTIFY\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, INFO, SUBSCRIBE, UPDATE\r\n
User-Agent: T-Com IpPbxSrv/11.10.0.325\r\n
Content-Length: 0\r\n
\r\n
[SIP-Packet] 2018/03/09 12:00:44,144 [Packet]:
Receiving datagram (581 Bytes) at 192.168.193.1:14851 from 172.20.172.223:5060 using UDP (RtgTag 193):
BYE sip:SIP88888880@192.168.193.1:14851;transport=udp SIP/2.0\r\n
Via: SIP/2.0/UDP 172.20.172.223:5060;branch=z9hG4bK-d8754z-af503b5bf164693c-1---d8754z-;rport\r\n
Max-Forwards: 70\r\n
Contact: <sip:+4930888888888@172.20.172.223:5060;transport=udp>\r\n
To: <sip:SIP88888880@172.20.172.223>;tag=1995771045-809459953\r\n
From: <sip:+4930888888888@telekom.de;user=phone>;tag=7d39093f\r\n
Call-ID: 2480571498@00a0572e9685\r\n
CSeq: 2 BYE\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, INFO, SUBSCRIBE, UPDATE\r\n
Supported: timer\r\n
User-Agent: T-Com IpPbxSrv/11.10.0.325\r\n
Content-Length: 0\r\n
\r\n
[SIP-Packet] 2018/03/09 12:00:44,147 [Packet]:
Sending datagram (477 Bytes) from 192.168.193.1:14851 to 172.20.172.223:5060 using UDP (RtgTag 193):
SIP/2.0 200 OK\r\n
Via: SIP/2.0/UDP 172.20.172.223:5060;branch=z9hG4bK-d8754z-af503b5bf164693c-1---d8754z-;received=172.20.172.223;rport=5060\r\n
From: <sip:+4930888888888@telekom.de;user=phone>;tag=7d39093f\r\n
To: <sip:SIP88888880@172.20.172.223>;tag=1995771045-809459953\r\n
Call-ID: 2480571498@00a0572e9685\r\n
CSeq: 2 BYE\r\n
User-Agent: LANCOM 1783VA (over ISDN) / 10.12.0284 / 23.02.2018\r\n
Server: Lancom\r\n
Allow: ACK, BYE, CANCEL, INVITE, OPTIONS, PRACK, REFER, UPDATE\r\n
Content-Length: 0\r\n
\r\n
[SIP-Packet] 2018/03/09 12:00:44,155 [Packet]:
Receiving datagram (320 Bytes) at 87.139.174.89:11901 from 217.0.26.131:5060 using TCP (RtgTag 0):
SIP/2.0 100 Trying\r\n
Via: SIP/2.0/TCP 87.139.174.89:11901;rport;branch=z9hG4bK-f788a36c-78e9d72d\r\n
To: <sip:+493022222222@sip-trunk.telekom.de;user=phone>;tag=2980fb74\r\n
From: <sip:+4930888888888@telekom.de;user=phone>;tag=397133653--857004840\r\n
Call-ID: 0ef929e159e6a2e8@62.156.103.71\r\n
CSeq: 1 INVITE\r\n
Content-Length: 0\r\n
\r\n
Code: Alles auswählen
[SIP-Packet] 2018/03/09 12:00:44,259 [Packet]:
Receiving datagram (836 Bytes) at 87.139.174.89:11901 from 217.0.26.131:5060 using TCP (RtgTag 0):
SIP/2.0 200 OK\r\n
Via: SIP/2.0/TCP 87.139.174.89:11901;rport=11901;branch=z9hG4bK-f788a36c-78e9d72d\r\n
Record-Route: <sip:reg.sip-trunk.telekom.de;transport=tcp;lr>\r\n
To: <sip:+493022222222@sip-trunk.telekom.de;user=phone>;tag=2980fb74\r\n
From: <sip:+4930888888888@telekom.de;user=phone>;tag=397133653--857004840\r\n
Call-ID: 0ef929e159e6a2e8@62.156.103.71\r\n
Contact: <sip:9bdKLvlLdYhpyCZBm/lMgoRmatB2wDmwkRnG4KIiTXHPVvPsir3kWtOM1oH7Gr6m@th1>\r\n
Supported: 100rel\r\n
CSeq: 1 INVITE\r\n
Allow: ACK, BYE, CANCEL, INFO, INVITE, OPTIONS, PRACK, REFER, REGISTER, UPDATE\r\n
Reason: TSSI;cause=0\r\n
Content-Type: application/sdp\r\n
Content-Disposition: session\r\n
Content-Length: 182\r\n
\r\n
v=0\r\n
o=- 904476806 1 IN IP4 217.0.26.131\r\n
s=on transit\r\n
c=IN IP4 0.0.0.0\r\n
t=0 0\r\n
m=audio 0 RTP/AVP 8 101\r\n
a=rtpmap:101 telephone-event/8000\r\n
a=fmtp:101 0-15\r\n
a=sendrecv\r\n
a=ptime:20\r\n
[SIP-Packet] 2018/03/09 12:00:44,262 [Packet]:
Sending datagram (804 Bytes) from 87.139.174.89:11901 to 217.0.26.131:5060 using TCP (RtgTag 0):
ACK sip:9bdKLvlLdYhpyCZBm/lMgoRmatB2wDmwkRnG4KIiTXHPVvPsir3kWtOM1oH7Gr6m@th1 SIP/2.0\r\n
Via: SIP/2.0/TCP 87.139.174.89:11901;branch=z9hG4bK-f76ffe1e-05e92509;rport\r\n
Route: <sip:reg.sip-trunk.telekom.de;transport=tcp;lr>\r\n
From: <sip:+4930888888888@telekom.de;user=phone>;tag=397133653--857004840\r\n
To: <sip:+493022222222@sip-trunk.telekom.de;user=phone>;tag=2980fb74\r\n
Call-ID: 0ef929e159e6a2e8@62.156.103.71\r\n
CSeq: 1 ACK\r\n
Max-Forwards: 70\r\n
User-Agent: LANCOM 1783VA (over ISDN) / 10.12.0284 / 23.02.2018\r\n
Authorization: Digest username="551129101372", realm="sip-trunk.telekom.de", algorithm=MD5, uri="sip:9bdKLvlLdYhpyCZBm/lMgoRmatB2wDmwkRnG4KIiTXHPVvPsir3kWtOM1oH", nonce="871ec1a1404163fb871ec1a13931b3a11698255c15366f1986278adbe92c36f8", response="95fd4d38be3ab3df802f6d3b023338f3"\r\n
Content-Length: 0\r\n
\r\n
[SIP-Packet] 2018/03/09 12:00:44,262 [Packet]:
Sending datagram (628 Bytes) from 192.168.193.1:14851 to 172.20.172.223:5060 using UDP (RtgTag 193):
ACK sip:172.20.172.223:5060;transport=udp SIP/2.0\r\n
Via: SIP/2.0/UDP 192.168.193.1:14851;branch=z9hG4bK-e7e8accd-2d365af3;rport\r\n
From: <sip:SIP88888880@172.20.172.223>;tag=715566522-284304425\r\n
To: <sip:+4930888888878@172.20.172.223;user=phone>;tag=d559295b\r\n
Call-ID: 522865208@00a0572e9685\r\n
CSeq: 100 ACK\r\n
Max-Forwards: 70\r\n
User-Agent: LANCOM 1783VA (over ISDN) / 10.12.0284 / 23.02.2018\r\n
Authorization: Digest username="SIP88888880", realm="172.20.172.223", algorithm=MD5, uri="sip:+4930888888878@172.20.172.223", nonce="279991588:374b05270d872924780c6c8ec28d4da8", response="a04a5e4749f451cc073c128309a6f908"\r\n
Content-Length: 0\r\n
\r\n
Code: Alles auswählen
c=IN IP4 0.0.0.0\r\n
m=audio 0 RTP/AVP 8 101\r\n
Interessant ist übrigens, dass das Re-INVITE beim Anrufer A nicht ankommt. Auch sehe ich natürlich nicht die (fehlerhafte) Rückantwort von Kabel Deutschland auf das Re-INVITE. Aber die Telekom hat hier ja eindeutige Angaben geliefert, weswegen sie den RTP-Stream schließt. Da der Fall aber vereinzelt auch bei Anrufern, die bei der Telekom sind, auftritt, Details dazu aber noch nicht geklärt sind, sind wir nach wie vor mit der Telekom im Gespräch.anbei die Rückmeldung zu den aufgenommen Anrufbeispielen:
Fehler liegt bei A-Tln oder dessen Netzbetreiber (Kabel Deutschland). Die Antwort auf das Re-INVITE enthält veränderten SDP. Somit muss die Versionsnummer der o-line um 1 erhöht werden. Da dies nicht passiert, schließt unser I-BCF den RTP (0.0.0.0). Laut RFC3264 Offer/Answer Modell muss die Version Nummer hochgezählt werden, wenn sich das SDP ändert: "When issuing an offer that modifies the session,the "o=" line of the new SDP MUST be identical to that in the previous SDP, except that the version in the origin field MUST increment by one from the previous SDP. If the version in the origin line does not increment, the SDP MUST be identical to the SDP with that version number." Bitte die Störung über die Netzkontrollstelle an Kabel Deutschland melden.
Ich schätze den Anteil an Problemanrufen auf 10 %. Diese Teilnehmer können in den meisten Fällen zurückgerufen werden. Ist natürlich trotzdem nervig, peinlich und zeitaufwändig.
In der RFC 4566 steht wie folgt:
Code: Alles auswählen
5.2. Origin ("o=")
o=<username> <sess-id> <sess-version> <nettype> <addrtype>
<unicast-address>
The "o=" field gives the originator of the session (her username and
the address of the user's host) plus a session identifier and version
number:
<username> is the user's login on the originating host, or it is "-"
if the originating host does not support the concept of user IDs.
The <username> MUST NOT contain spaces.
<sess-id> is a numeric string such that the tuple of <username>,
<sess-id>, <nettype>, <addrtype>, and <unicast-address> forms a
globally unique identifier for the session. The method of
<sess-id> allocation is up to the creating tool, but it has been
suggested that a Network Time Protocol (NTP) format timestamp be
used to ensure uniqueness [13].
<sess-version> is a version number for this session description. Its
usage is up to the creating tool, so long as <sess-version> is
increased when a modification is made to the session data. Again,
it is RECOMMENDED that an NTP format timestamp is used.
<nettype> is a text string giving the type of network. Initially
"IN" is defined to have the meaning "Internet", but other values
MAY be registered in the future (see Section 8).
<addrtype> is a text string giving the type of the address that
follows. Initially "IP4" and "IP6" are defined, but other values
MAY be registered in the future (see Section 8).
<unicast-address> is the address of the machine from which the
session was created. For an address type of IP4, this is either
the fully qualified domain name of the machine or the dotted-
decimal representation of the IP version 4 address of the machine.
For an address type of IP6, this is either the fully qualified
domain name of the machine or the compressed textual
representation of the IP version 6 address of the machine. For
both IP4 and IP6, the fully qualified domain name is the form that
SHOULD be given unless this is unavailable, in which case the
globally unique address MAY be substituted. A local IP address
MUST NOT be used in any context where the SDP description might
leave the scope in which the address is meaningful (for example, a
local address MUST NOT be included in an application-level
referral that might leave the scope).
Code: Alles auswählen
8 Modifying the Session
At any point during the session, either participant MAY issue a new
offer to modify characteristics of the session. It is fundamental to
the operation of the offer/answer model that the exact same
offer/answer procedure defined above is used for modifying parameters
of an existing session.
The offer MAY be identical to the last SDP provided to the other
party (which may have been provided in an offer or an answer), or it
MAY be different. We refer to the last SDP provided as the "previous
SDP". If the offer is the same, the answer MAY be the same as the
previous SDP from the answerer, or it MAY be different. If the
offered SDP is different from the previous SDP, some constraints are
placed on its construction, discussed below.
Nearly all aspects of the session can be modified. New streams can
be added, existing streams can be deleted, and parameters of existing
streams can change. When issuing an offer that modifies the session,
the "o=" line of the new SDP MUST be identical to that in the
previous SDP, except that the version in the origin field MUST
increment by one from the previous SDP. If the version in the origin
line does not increment, the SDP MUST be identical to the SDP with
that version number. The answerer MUST be prepared to receive an
offer that contains SDP with a version that has not changed; this is
effectively a no-op. However, the answerer MUST generate a valid
answer (which MAY be the same as the previous SDP from the answerer,
or MAY be different), according to the procedures defined in Section
6.
If an SDP is offered, which is different from the previous SDP, the
new SDP MUST have a matching media stream for each media stream in
the previous SDP. In other words, if the previous SDP had N "m="
lines, the new SDP MUST have at least N "m=" lines. The i-th media
stream in the previous SDP, counting from the top, matches the i-th
media stream in the new SDP, counting from the top. This matching is
necessary in order for the answerer to determine which stream in the
new SDP corresponds to a stream in the previous SDP. Because of
these requirements, the number of "m=" lines in a stream never
decreases, but either stays the same or increases. Deleted media
streams from a previous SDP MUST NOT be removed in a new SDP;
however, attributes for these streams need not be present.
Jirka