All-IP/VoIP: Nach Gesprächsübergabe stumm - zur Info

Forum zu LANCOM Systems VoIP Router/Gateways und zur LANCOM VoIP Option

Moderator: Lancom-Systems Moderatoren

Antworten
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

All-IP/VoIP: Nach Gesprächsübergabe stumm - zur Info

Beitrag von Jirka »

Hallo zusammen,

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
Der LANCOM-Router übergibt den Ruf an die NetPhone:

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
Gibt das Ringing an den Provider weiter:

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
Jetzt bekommt der LANCOM-Router von der NetPhone das Ok und gibt dieses an den Provider weiter:

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
Jetzt besteht das Telefongespräch. Und zwar zwischen Anrufer (A) und NetPhone (B). Die NetPhone spielt dem Anrufer einen Willkommens-Ansagetext vor und nach diesem Wartemusik, da die drei Telefone, an die der Ruf zugestellt werden könnte, gerade noch besetzt sind. Nach kurzer Zeit ist die Warteschlange abgearbeitet und die NetPhone würde diesen Anruf jetzt gerne an Teilnehmer C durchstellen. Dazu schickt sie dem LANCOM ein REFER, was dieser akzeptiert

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
Nun schickt der LANCOM-Router ein INVITE an die NetPhone (der Anruf soll jetzt an Teilnehmer C gehen), welches von der NetPhone mit OK bestätigt wird:

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
Jetzt kommt der Punkt, an dem ich Georg gerne fragen würde, ob man das nicht optimieren könnte, denn der LANCOM-Router schickt jetzt auch zum Provider ein INVITE. Er macht dies, weil er natürlich SIP-Proxy ist und weil bei der Übergabe des Telefongesprächs von B zu C sich ja die Codecs ändern können und der LANCOM-Router kann oder möchte (konnte er doch aber früher mal, oder?) die Codecs nicht umrechnen, falls C jetzt einen anderen Codec nutzt als B. C hat aber dem LANCOM exakt den gleichen Codec wie B mitgeteilt, demzufolge bräuchte der LANCOM dem Provider hier gar kein Re-INVITE schicken. Er tut es aber trotzdem. Das ist nicht falsch, aber in meinen Augen unnötig. Der LANCOM-Router schickt dem Provider also ein Re-INVITE, das alte Telefonat mit der NetPhone beendet er:

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
Und nun kommt das OK-Paket vom Provider zurück, was ich als "fehlerhaft" rausgefunden habe,

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
weil es im SDP folgende fehlerhafte Parameter enthält:

Code: Alles auswählen

c=IN IP4 0.0.0.0\r\n
m=audio 0 RTP/AVP 8 101\r\n
Eine IT-Mitarbeiterin des Unternehmens meldete den Fall sogleich der Telekom, da hatte ich den Trace noch gar nicht richtig aufgearbeitet. Diese - und das muss man hier mal ausdrücklich lobend erwähnen - nahm sich des Problems selbst ohne Trace an und lieferte innerhalb von wenigen Stunden eine professionelle Antwort:
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.
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.

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).
Und in der RFC 3264, der von der Telekom zitierte Satz:

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.
Vielen Dank und viele Grüße,
Jirka
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: All-IP/VoIP: Nach Gesprächsübergabe stumm - zur Info

Beitrag von Jirka »

Hallo,

im "normalen" SIP-Account der Telekom sieht man die Provider-Herkunft des Anrufers im Trace,

Code: Alles auswählen

<sip:+493022222222@kabeldeutschland.de;user=phone>
der SIP-Trunk der Telekom "filtert" diesbezüglich leider einiges aus (siehe oben).

Zumindest am Standort mit dem SIP-Account kamen heute alle Anrufer, wo der Fehler auftrat, von Kabel Deutschland.

Vielen Dank und viele Grüße,
Jirka
Benutzeravatar
MoinMoin
Moderator
Moderator
Beiträge: 1978
Registriert: 12 Nov 2004, 16:04

Re: All-IP/VoIP: Nach Gesprächsübergabe stumm - zur Info

Beitrag von MoinMoin »

Moin Jirka!

Ich habe die Fragen an awi abgegeben. Ich nehme aber an, das ReInvite wird an den Provider geschickt, damit der Transport für die neue Verbindung "automatisch" richtig aufgesetzt wird.

Ciao, Georg
Koppelfeld
Beiträge: 967
Registriert: 20 Nov 2013, 09:17

Re: All-IP/VoIP: Nach Gesprächsübergabe stumm - zur Info

Beitrag von Koppelfeld »

Völlig korrekt!

Es könnte ja auch an einen Teilnehmer in einem ganz anderen Netz vermittelt werden - warum soll der Provider den Payload da noch "über Bande" schicken?

Es wäre nur unendlich praktisch, wenn man den Reinvite abschalten könnte.
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: All-IP/VoIP: Nach Gesprächsübergabe stumm - zur Info

Beitrag von Jirka »

Koppelfeld hat geschrieben:Völlig korrekt!
Ich habe ja oben auch geschrieben, dass ich der Auffassung bin, dass es nicht falsch ist. Aber es ist im konkreten Fall, wo sich der Codec gar nicht ändert, unnötig. Und im Sinne der Vermeidung von unnötigen Nachrichten/Benachrichtigungen könnte ich mir vorstellen, dass man es hier auch unterlässt. Wäre natürlich ein Eingriff in die SIP-Aushandlung, den man, wenn man sich auf den Standpunkt stellt, dass der LANCOM lediglich SIP-Proxy sein soll, der stur nach Schema F arbeitet, natürlich rechtfertigen muss. Im konkreten Fall würde das Problem damit gelöst werden, aber nicht die eigentliche Ursache für das Problem.

Weitere Bemerkungen zu meinem letzten Posting:
Inzwischen steht eindeutig fest, dass auch Anrufer von Arcor (Vodafone-DSL) und vereinzelt auch Telekom betroffen sind (danke an hyperjojo). Ja selbst wenn man von einer Filiale mit Telekom-SIP-Trunk zur anderen Filiale mit Telekom-SIP-Account anruft (also extern und nicht intern über die Telefonanlage), ist das Problem nachstellbar. Und da sehe ich ja die Pakete die der eine LANCOM abschickt und die beim anderen ankommen. Nur funkt da der SIP-Server der Telekom dazwischen. Die Telekom hat also nachweislich auch selber Probleme und kann nicht alles auf Kabel Deutschland abschieben.

Vielen Dank und viele Grüße,
Jirka
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: All-IP/VoIP: Nach Gesprächsübergabe stumm - zur Info

Beitrag von Jirka »

Hallo zusammen,

gestern waren zwei Telekom-Techniker da, die hauptsächlich mit Traces feststellen wollten, ob soweit alles ok ist. Es wurde angefragt, ob es seitens LANCOM zu dem Problem eine Stellungnahme gibt. Im Sinne der Vermeidung überflüssiger ReINVITEs ist man der Auffassung, dass hier auch auf das ReINVITE verzichtet werden könnte und sollte. Ich habe gesagt, dass sich LANCOM bisher noch nicht dazu geäußert hat.

Das Problem ist seit dem Wochenende größtenteils gefixt. Anrufe von anderen Providern sind nach dem ReINVITE (verursacht durch die Gesprächsübergabe) ohne Mangel (kein 0.0.0.0 mehr im SDP). Probleme treten jetzt noch bei Telekom-Kunden auf (Provider des Anrufers bei eingehenden Ruf: Telekom). Entweder antworten dort die Telefonanlagen oder Router falsch, oder es gibt Probleme zwischen den verschiedenen Telekom-Systemen. Genauere Angaben liegen hierzu derzeit nicht vor. Ca. 80 bis 90 % der fehlerhaften Anrufe sind dadurch jetzt erst mal vom Tisch.

Viele Grüße,
Jirka
COMCARGRU
Beiträge: 1202
Registriert: 10 Nov 2004, 17:56
Wohnort: Hessen

Re: All-IP/VoIP: Nach Gesprächsübergabe stumm - zur Info

Beitrag von COMCARGRU »

Ohne Worte!
Wann zum Teufel werden ALLE PCs grundsätzlich nur noch mit Hardware RAID 1 ausgestattet???
Antworten