VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3

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

Moderator: Lancom-Systems Moderatoren

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

VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3

Beitrag von Jirka »

Hallo zusammen,

insbesondere an die Telekomiker hier die Frage, ob sie mir weiterhelfen können.

Gegeben ist eine NetPhone (Version 11.32.3220 de-DE) und ein LANCOM mit VCM, hier jetzt ein 1906VA, aber das spielt ja eher eine untergeordnete Rolle (welcher LANCOM konkret). Der LANCOM-VCM ist der NetPhone vorgeschaltet. Mit der Firmware 10.20-RU2 läuft alles (na ja, jedenfalls kann man ein- und ausgehend telefonieren). Mit der Installation der 10.20-RU3 gehen nur noch eingehende Telefonate, ausgehend geht nichts mehr. Die Telekom lehnt die Telefonate mit "SIP/2.0 422 Session Interval Too Small" ab (Reason: TSSI;cause=4220001). Wenn man sich die Unterschiede zwischen 10.20-RU2 und -RU3 anschaut, dann sieht man, dass bei der 10.20-RU3 ein "Session-Expires: 90;refresher=uac" im INVITE durchgereicht wird, was bei der 10.20-RU2 noch nicht der Fall war. In der Folge kommt bei der Telekom der schon angegebene Hinweis, dass das Session Interval, also der Session-Expires-Wert von 90 Sekunden, zu niedrig ist. Nun kann man das dem LANCOM wohl nicht anlasten, folglich müsste ich diesen Wert an der NetPhone editieren. Weiß jemand wo genau?! Ich habe leider nichts gefunden. Und welche Werte akzeptiert die Telekom denn? Oder wie sollte man den Wert einstellen? Prinzipiell ist zu der NetPhone auch ein Telekom-Wartungsvertrag abgeschlossen, sonst müsste ich das Problem durchreichen, wenn hier keiner eine Lösung hat. Aber da dieser Fall eine Standardkonstellation ist, müsste der ja auch andere betreffen - vermutlich hat die 10.20-RU3 noch keiner installiert? Ich wollte es auch mal mit einer Beta probieren, aber für die 190x-er Reihe gibt es anscheinend keine Beta-10.20.0363.

Vielen Dank und viele Grüße,
Jirka
he
Beiträge: 24
Registriert: 17 Dez 2005, 08:39

Re: VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3

Beitrag von he »

Hi Jirka,

wenn der LANCOM via LinkManager angebunden ist, lässt sich das Session Interval in der Swyx mittels Reg-Key anpassen:

HKLM\Software\Wow6432Node\Swyx\LinkMgr\CurrentVersion\Options

create two new DWORD values
SipMinSessionTimerIntervalSeconds
SipSessionTimerIntervalSeconds

(jeweils dezimal in Sekunden)

Nach der Änderung muss der LinkMgr-Dienst neu gestartet werden.

Ggfls. heißt der Reg-Pfad bei der NetPhone etwas anders.
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3

Beitrag von Jirka »

Hallo "he",

oha, die Antwort kam ja sehr schnell...
Also der Pfad lautet hier tatsächlich HKLM\Software\Wow6432Node\T-Com\LinkMgr\CurrentVersion\Options, obwohl es den Swyx-Pfad auch gibt, aber da steht nur ganz wenig drunter. Und was stelle ich da jetzt sinnvollerweise ein? Dr. Einstein? hyperjojo? :roll:

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

Re: VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3

Beitrag von MoinMoin »

Moin Jirka,

normalerweise sollte der gewünschte Wert im Antwortpaket mit der Fehlermeldung stehen. Ist zumindest bei anderen Timeouts so.

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

Re: VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3

Beitrag von Jirka »

Hallo MoinMoin,

tatsächlich, über dem Reason steht

Code: Alles auswählen

Min-SE: 900
dabei habe ich mir doch das ganze Paket angeschaut! So ist das immer, wenn es schnell gehen soll, zack zack und schon übersehen.
Also 10 mal so hoch, wie die NetPhone standardmäßig macht (90 Sek.). Oder anders ausgedrückt 15 Minuten - ah, da haben wir dann auch wieder die ReINVITE-Zeit, die man kennt aus früheren Bugs, Abbruch nach 15 Minuten.

Ok, dann werde ich heute Abend mal mein Glück versuchen.

Vielen Dank und viele Grüße,
Jirka
Dr.Einstein
Beiträge: 2893
Registriert: 12 Jan 2010, 14:10

Re: VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3

Beitrag von Dr.Einstein »

Hallo Jirka,

irgendwie seltsam, dass der Registertimer dein einziges Problem mit der 10.20-RU3 in Zusammenhang mit Swyx sein soll. Bin mal gespannt, ob du sporadische ankommende Nichterreichbarkeit des Anschlusses oder ähnliches hast. Auch Rufumleitungen verursachen wohl Probleme. Unser erstes Ticket wurde vom Support schon als Fehler akzeptiert. Mal schauen, was noch so eingetütet wird. Denke mal, VoIP und 10.20 wird wieder so zur RU6 voll nutzbar sein =)

Gruß Dr.Einstein

PS: Hab deine Mail letztens irgendwie nicht beantwortet. Das TK-System hatte ich aber noch nie eingesetzt, drum konnte ich eh nichts zu beisteuern :(
Benutzeravatar
MoinMoin
Moderator
Moderator
Beiträge: 1978
Registriert: 12 Nov 2004, 16:04

Re: VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3

Beitrag von MoinMoin »

Moin Jirka,

leitet das LANCOM die Response nicht an die NetPhone weiter? Die sollte dann von sich aus die Zeit hochsetzen und den nächsten Versuch starten.

Ciao, Georg
Benutzeravatar
hyperjojo
Beiträge: 801
Registriert: 26 Jul 2009, 02:26

Re: VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3

Beitrag von hyperjojo »

Hallo,

ich habe nur mitbekommen, dass es mit der RU3 einen Bug gibt, welcher grundsätzlich mit der Netphone Probleme macht. Hatte noch keine Zeit, mich näher damit zu beschäftigen. Die Kollegen empfehlen aktuell nur ein Downgrade auf die LCOS 10.20 RU2. Workaround habe ich noch keinen gelesen. Wie Dr. Einstein schon schreibt, scheint es mehrere Probleme zu geben und der Support ist fleißig am arbeiten...
Habe aber mal angefragt, ob es Details dazu gibt.

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

Re: VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3

Beitrag von Jirka »

Hallo Dr. Einstein, hallo Georg,

ich hatte überlegt, ob ich den gesamten Trace oder zumindest ein paar Pakete poste, aber dann habe ich gedacht, schaut sich sowieso keiner an, wenn das Problem schon so weit analysiert ist. Und dann habe ich es alles wieder gestrichen, obwohl ich es schon anonymisiert hatte. Jetzt merke ich aber, dass es wohl doch sinnvoll gewesen wäre, denn ich nehme an, dass Ihr beide jetzt in die falsche Schublade gerutscht seid. Es geht hier nicht um das Timeout des REGISTERs, sondern, wie oben geschrieben, um das Session-Expires im INVITE(!). Das hat der LANCOM bisher - ich sage mal rausgefiltert - und nun tut er es nicht mehr und deswegen kracht es. Je intensiver man sich aber die Sache anschaut, je mehr Bugs kommen wieder an die Oberfläche, das wollte ich eigentlich verhindern, weil man kommt hier immer vom Hundersten ins Tausendste. Aber nach dem Hinweis/der Frage von Georg, ob das LANCOM denn nicht die Response an die NetPhone weiterleitet, wodurch die von sich aus die Zeit hochsetzen sollte und den nächsten Versuch starten, habe ich gedacht, ja, da hat er ja eigentlich Recht, schau Dir mal den Rest vom Trace an und siehe da, Georg hat Recht, aber es kracht dann eben trotzdem, weil der LANCOM wieder alles durcheinander bringt. Das wiederum habe ich schon mit zig anderen Traces belegt, die hier seit einem Jahr im Forum liegen, sauber analysiert und dokumentiert und diese Probleme sind ja auch noch nicht gefixt, ich sehe zumindest einige davon regelmäßig, genauso wie hängende Calls. Also doch noch den Trace? Eigentlich bin ich der Meinung ist zwecklos, aber die Hoffnung stirbt zuletzt... Der Trace folgt im nächsten Posting.
Dr.Einstein hat geschrieben: 05 Feb 2019, 16:37Bin mal gespannt, ob du sporadische ankommende Nichterreichbarkeit des Anschlusses oder ähnliches hast.
Oh, soweit bin ich ja noch gar nicht. Bisher ging ja ausgehend gar nichts, da fallen derartige Probleme ja nicht ins Gewicht.
Dr.Einstein hat geschrieben: 05 Feb 2019, 16:37Auch Rufumleitungen verursachen wohl Probleme.
Da habe ich schon mit der 10.20 Probleme. Leider bin ich noch nicht zum Analysieren gekommen. Ganz schlimm ist es mit der Weiterleitung eines anonymen Anrufers, da muss ich definitv noch schauen, da werde ich schon regelmäßig genervt deswegen.
Dr.Einstein hat geschrieben: 05 Feb 2019, 16:37PS: Hab deine Mail letztens irgendwie nicht beantwortet. Das TK-System hatte ich aber noch nie eingesetzt, drum konnte ich eh nichts zu beisteuern :(
Alles klar. Ich hatte vermutet, Du hast so viel zu tun oder bist in Urlaub, insofern wollte ich da nicht noch mal nachfragen. Allerdings wartet tatsächlich noch eine ganze Belegschaft eines mittelständigen Unternehmens, dass es für das Problem eine Lösung gibt. Offiziell gibt es keine. Nur mit Bintec, denn die können bei einem SIP-Trunk-Benutzer FROM und PPI tauschen, der LANCOM kann das nicht. Koppelfeld hat gesagt, dass das geht, man müsse da nur in der Telefonanlage was umstellen, an einer Stelle im Webinterface, "wo man es nicht vermutet". Dann habe ich gesagt, er soll das machen, selbstverständlich auch bezahlt. Aber er meldet sich nicht. Deswegen und weil der Hersteller das auch sagt, glaube ich hingegen, dass das nicht geht oder eben nur mit Bintec-Router, was die aber nicht wollen, weil sie niemanden haben, der sich damit auskennt.

P. S.: Hallo auch an hyperjojo. Ich hatte hier schon angefangen mit dem Posting, da war Deines noch nicht da :-)

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

Re: VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3

Beitrag von Jirka »

So, hier der Trace. Zum besseren Verständnis natürlich auskommentiert. Leider erschweren die seit dem letzten Foren-Software-Update größenbegrenzten Code-Felder die Lesbarkeit, sorry.

Es geht los. Die NetPhone sendet ein INVITE an den LANCOM-Router. Das hat sie schon immer so gemacht. Nichts neues.

Code: Alles auswählen

[SIP-Packet] 2019/02/04 10:01:17,691  Devicetime: 2019/02/04 10:01:19,663 [Packet]: 
Receiving datagram (1116 Bytes) at 192.168.193.1:12609 from 172.20.172.223:5060 using UDP (RtgTag 193):
INVITE sip:SIP666660@192.168.193.1:12609;transport=udp SIP/2.0\r\n
Via: SIP/2.0/UDP 172.20.172.223:5060;branch=z9hG4bK-524287-1---be62715f2a3ccd28;rport\r\n
Max-Forwards: 70\r\n
Contact: <sip:SIP666660@172.20.172.223:5060;transport=udp>\r\n
To: <sip:+491712223344@172.20.172.223;user=phone>\r\n
From: "ARZT-188"<sip:SIP666660@172.20.172.223>;tag=3e51447d\r\n
Call-ID: GlgzHKjEAVFkL6LWIPU3KA..\r\n
CSeq: 1 INVITE\r\n
Session-Expires: 90;refresher=uac\r\n
Min-SE: 90\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, INFO, SUBSCRIBE, UPDATE\r\n
Content-Type: application/sdp\r\n
Supported: timer\r\n
User-Agent: T-Com IpPbxSrv/11.32.0.331\r\n
P-Asserted-Identity: "ARZT-188"<sip:+49306666666@172.20.172.223;user=phone>\r\n
P-Asserted-Identity: <sip:+49306666688@172.20.172.223;user=phone;x-type=unknown;x-plan=unknown;x-pres=allowed;x-screen=network;x-sendingcomplete>\r\n
P-Preferred-Identity: "ARZT-188"<sip:+49306666666@172.20.172.223;user=phone>\r\n
Content-Length: 153\r\n
\r\n
v=0\r\n
o=- 3394126053 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
Der LANCOM sagt dazu - wie immer - Trying.

Code: Alles auswählen

[SIP-Packet] 2019/02/04 10:01:17,691  Devicetime: 2019/02/04 10:01:19,670 [Packet]: 
Sending datagram (559 Bytes) from 192.168.193.1:12609 to 172.20.172.223:5060 using UDP (RtgTag 193):
SIP/2.0 100 Trying\r\n
Via: SIP/2.0/UDP 172.20.172.223:5060;branch=z9hG4bK-524287-1---be62715f2a3ccd28;received=172.20.172.223;rport=5060\r\n
From: "ARZT-188"<sip:SIP666660@172.20.172.223>;tag=3e51447d\r\n
To: <sip:+491712223344@172.20.172.223;user=phone>;tag=-1687632881--846416631\r\n
Call-ID: GlgzHKjEAVFkL6LWIPU3KA..\r\n
CSeq: 1 INVITE\r\n
User-Agent: LANCOM 1906VA (over ISDN) / 10.20.0355 / 19.01.2019\r\n
Server: Lancom\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, SUBSCRIBE, UPDATE, PRACK\r\n
Supported: 100rel,replaces,timer\r\n
Content-Length: 0\r\n
\r\n
Jetzt gibt der LANCOM das INVITE an den Provider, hier die Telekom. Das macht er aber mit der 10.20-RU3 anders als bisher. Bisher hat er die Zeile "Session-Expires: 90;refresher=uac\r\n" rausgefiltert, jetzt überträgt er sie.

Code: Alles auswählen

[SIP-Packet] 2019/02/04 10:01:18,439  Devicetime: 2019/02/04 10:01:20,435 [Packet]: 
Sending datagram (1237 Bytes) from 87.139.1.1:10844 to 217.0.26.35:5060 using TCP (RtgTag 0):
INVITE sip:+491712223344@sip-trunk.telekom.de SIP/2.0\r\n
Via: SIP/2.0/TCP 87.139.1.1:10844;branch=z9hG4bK-e32ea837-0fc358c1;rport\r\n
From: "ARZT-188"<sip:+49306666666@sip-trunk.telekom.de;user=phone>;tag=-387964506-1537813046\r\n
To: <sip:+491712223344@sip-trunk.telekom.de>\r\n
Call-ID: 1483628639@00a05746735d\r\n
CSeq: 100 INVITE\r\n
Max-Forwards: 70\r\n
User-Agent: LANCOM 1906VA (over ISDN) / 10.20.0355 / 19.01.2019\r\n
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, SUBSCRIBE, UPDATE, PRACK\r\n
Supported: 100rel,timer\r\n
Contact: <sip:+4930666660@87.139.1.1:10844;transport=TCP>\r\n
P-Asserted-Identity: <sip:+49306666688@sip-trunk.telekom.de;user=phone>\r\n
Authorization: Digest username="551122334455", realm="sip-trunk.telekom.de", algorithm=MD5, uri="sip:+491712223344@sip-trunk.telekom.de", nonce="d92129bb94de7ee7d92129bbe833b5b92df7007622db0690ff06d6e46c8ffd96", response="faa45ad6926e2eb8a75d9aa82f432e97"\r\n
Session-Expires: 90;refresher=uac\r\n
Min-SE: 90\r\n
Content-Type: application/sdp\r\n
Content-Length: 219\r\n
\r\n
v=0\r\n
o=- 3247420175 3247420175 IN IP4 87.139.1.1\r\n
s=call\r\n
c=IN IP4 87.139.1.1\r\n
t=0 0\r\n
m=audio 10916 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
Telekom sagt Trying.

Code: Alles auswählen

[SIP-Packet] 2019/02/04 10:01:18,440  Devicetime: 2019/02/04 10:01:20,464 [Packet]: 
Receiving datagram (315 Bytes) at 87.139.1.1:10844 from 217.0.26.35:5060 using TCP (RtgTag 0):
SIP/2.0 100 Trying\r\n
Via: SIP/2.0/TCP 87.139.1.1:10844;rport;branch=z9hG4bK-e32ea837-0fc358c1\r\n
To: <sip:+491712223344@sip-trunk.telekom.de>\r\n
From: ARZT-188 <sip:+49306666666@sip-trunk.telekom.de;user=phone>;tag=-387964506-1537813046\r\n
Call-ID: 1483628639@00a05746735d\r\n
CSeq: 100 INVITE\r\n
Content-Length: 0\r\n
\r\n
Die Telekom sagt SIP/2.0 422 Session Interval Too Small. Das ist eine Folge davon, dass der LANCOM-Router das Session-Expires: 90 nun durchreicht und der Telekom das nicht gefällt. (Hier mein Ansatz: Die NetPhone muss gleich das richtige Session-Expires liefern, dann haben wir diese Probleme nicht.)

Code: Alles auswählen

[SIP-Packet] 2019/02/04 10:01:18,455  Devicetime: 2019/02/04 10:01:20,486 [Packet]: 
Receiving datagram (562 Bytes) at 87.139.1.1:10844 from 217.0.26.35:5060 using TCP (RtgTag 0):
SIP/2.0 422 Session Interval Too Small\r\n
Via: SIP/2.0/TCP 87.139.1.1:10844;rport=10844;branch=z9hG4bK-e32ea837-0fc358c1\r\n
To: <sip:+491712223344@sip-trunk.telekom.de>;tag=485986d7\r\n
From: ARZT-188 <sip:+49306666666@sip-trunk.telekom.de;user=phone>;tag=-387964506-1537813046\r\n
Call-ID: 1483628639@00a05746735d\r\n
Contact: <sip:eMbw8ew4lSvrcMET3r7k26SKvB5QNBskyW+Ov1qvKwmuYIdyiHPkDvMTPf0zjP6SXF48@th1>\r\n
CSeq: 100 INVITE\r\n
Allow: ACK, BYE, CANCEL, INVITE, OPTIONS, PRACK, REGISTER, SUBSCRIBE, UPDATE\r\n
Min-SE: 900\r\n
Reason: TSSI;cause=4220001\r\n
Content-Length: 0\r\n
\r\n
Das bestätigt der LANCOM-Router.

Code: Alles auswählen

[SIP-Packet] 2019/02/04 10:01:18,455  Devicetime: 2019/02/04 10:01:20,487 [Packet]: 
Sending datagram (524 Bytes) from 87.139.1.1:10844 to 217.0.26.35:5060 using TCP (RtgTag 0):
ACK sip:+491712223344@sip-trunk.telekom.de SIP/2.0\r\n
Via: SIP/2.0/TCP 87.139.1.1:10844;branch=z9hG4bK-e32ea837-0fc358c1;rport\r\n
From: "ARZT-188"<sip:+49306666666@sip-trunk.telekom.de;user=phone>;tag=-387964506-1537813046\r\n
To: <sip:+491712223344@sip-trunk.telekom.de>;tag=485986d7\r\n
Call-ID: 1483628639@00a05746735d\r\n
CSeq: 100 ACK\r\n
Max-Forwards: 70\r\n
User-Agent: LANCOM 1906VA (over ISDN) / 10.20.0355 / 19.01.2019\r\n
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, SUBSCRIBE, UPDATE, PRACK\r\n
Content-Length: 0\r\n
\r\n
Und leitet nun das ganze an die NetPhone weiter. (Die Zeile "Reason: TSSI;cause=4220001" wird übrigens verschluckt.)

Code: Alles auswählen

[SIP-Packet] 2019/02/04 10:01:18,456  Devicetime: 2019/02/04 10:01:20,487 [Packet]: 
Sending datagram (652 Bytes) from 192.168.193.1:12609 to 172.20.172.223:5060 using UDP (RtgTag 193):
SIP/2.0 422 Session Interval Too Small\r\n
Via: SIP/2.0/UDP 172.20.172.223:5060;branch=z9hG4bK-524287-1---be62715f2a3ccd28;received=172.20.172.223;rport=5060\r\n
From: "ARZT-188"<sip:SIP666660@172.20.172.223>;tag=3e51447d\r\n
To: <sip:+491712223344@172.20.172.223;user=phone>;tag=-1687632881--846416631\r\n
Call-ID: GlgzHKjEAVFkL6LWIPU3KA..\r\n
CSeq: 1 INVITE\r\n
User-Agent: LANCOM 1906VA (over ISDN) / 10.20.0355 / 19.01.2019\r\n
Server: Lancom\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, SUBSCRIBE, UPDATE, PRACK\r\n
Supported: 100rel,replaces,timer\r\n
Contact: <sip:SIP666660@192.168.193.1:12609;transport=UDP>\r\n
Min-SE: 900\r\n
Content-Length: 0\r\n
\r\n
Die NetPhone bestätigt das.

Code: Alles auswählen

[SIP-Packet] 2019/02/04 10:01:18,524  Devicetime: 2019/02/04 10:01:20,503 [Packet]: 
Receiving datagram (378 Bytes) at 192.168.193.1:12609 from 172.20.172.223:5060 using UDP (RtgTag 193):
ACK sip:SIP666660@192.168.193.1:12609;transport=udp SIP/2.0\r\n
Via: SIP/2.0/UDP 172.20.172.223:5060;branch=z9hG4bK-524287-1---be62715f2a3ccd28;rport\r\n
Max-Forwards: 70\r\n
To: <sip:+491712223344@172.20.172.223;user=phone>;tag=-1687632881--846416631\r\n
From: "ARZT-188"<sip:SIP666660@172.20.172.223>;tag=3e51447d\r\n
Call-ID: GlgzHKjEAVFkL6LWIPU3KA..\r\n
CSeq: 1 ACK\r\n
Content-Length: 0\r\n
\r\n
Die NetPhone nicht dumm, macht, wie Georg beschrieben hat, einen zweiten Versuch und erhöht jetzt die Session-Expires auf die geforderten 900 Sekunden. Alles gut könnte man meinen, allerdings rechnet die NetPhone nicht damit, das derartige "ReINVITEs" den LANCOM immer durcheinander bringen. Call-ID bleibt also wie gehabt.

Code: Alles auswählen

[SIP-Packet] 2019/02/04 10:01:18,524  Devicetime: 2019/02/04 10:01:20,506 [Packet]: 
Receiving datagram (1118 Bytes) at 192.168.193.1:12609 from 172.20.172.223:5060 using UDP (RtgTag 193):
INVITE sip:SIP666660@192.168.193.1:12609;transport=udp SIP/2.0\r\n
Via: SIP/2.0/UDP 172.20.172.223:5060;branch=z9hG4bK-524287-1---db6ab301f4430b37;rport\r\n
Max-Forwards: 70\r\n
Contact: <sip:SIP666660@172.20.172.223:5060;transport=udp>\r\n
To: <sip:+491712223344@172.20.172.223;user=phone>\r\n
From: "ARZT-188"<sip:SIP666660@172.20.172.223>;tag=3e51447d\r\n
Call-ID: GlgzHKjEAVFkL6LWIPU3KA..\r\n
CSeq: 2 INVITE\r\n
Session-Expires: 900;refresher=uac\r\n
Min-SE: 900\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, INFO, SUBSCRIBE, UPDATE\r\n
Content-Type: application/sdp\r\n
Supported: timer\r\n
User-Agent: T-Com IpPbxSrv/11.32.0.331\r\n
P-Asserted-Identity: "ARZT-188"<sip:+49306666666@172.20.172.223;user=phone>\r\n
P-Asserted-Identity: <sip:+49306666688@172.20.172.223;user=phone;x-type=unknown;x-plan=unknown;x-pres=allowed;x-screen=network;x-sendingcomplete>\r\n
P-Preferred-Identity: "ARZT-188"<sip:+49306666666@172.20.172.223;user=phone>\r\n
Content-Length: 153\r\n
\r\n
v=0\r\n
o=- 3394126053 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
Der LANCOM-Router sagt zur NetPhone Trying, das ist unspektakulär.

Code: Alles auswählen

[SIP-Packet] 2019/02/04 10:01:18,524  Devicetime: 2019/02/04 10:01:20,506 [Packet]: 
Sending datagram (559 Bytes) from 192.168.193.1:12609 to 172.20.172.223:5060 using UDP (RtgTag 193):
SIP/2.0 100 Trying\r\n
Via: SIP/2.0/UDP 172.20.172.223:5060;branch=z9hG4bK-524287-1---db6ab301f4430b37;received=172.20.172.223;rport=5060\r\n
From: "ARZT-188"<sip:SIP666660@172.20.172.223>;tag=3e51447d\r\n
To: <sip:+491712223344@172.20.172.223;user=phone>;tag=-1687632881--846416631\r\n
Call-ID: GlgzHKjEAVFkL6LWIPU3KA..\r\n
CSeq: 2 INVITE\r\n
User-Agent: LANCOM 1906VA (over ISDN) / 10.20.0355 / 19.01.2019\r\n
Server: Lancom\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, SUBSCRIBE, UPDATE, PRACK\r\n
Supported: 100rel,replaces,timer\r\n
Content-Length: 0\r\n
\r\n
Aber jetzt geht es schon los, der LANCOM-Router sagt zur NetPhone OK! Ja wie denn das bitteschön?

Code: Alles auswählen

[SIP-Packet] 2019/02/04 10:01:18,525  Devicetime: 2019/02/04 10:01:20,508 [Packet]: 
Sending datagram (555 Bytes) from 192.168.193.1:12609 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-524287-1---db6ab301f4430b37;received=172.20.172.223;rport=5060\r\n
From: "ARZT-188"<sip:SIP666660@172.20.172.223>;tag=3e51447d\r\n
To: <sip:+491712223344@172.20.172.223;user=phone>;tag=-1687632881--846416631\r\n
Call-ID: GlgzHKjEAVFkL6LWIPU3KA..\r\n
CSeq: 2 INVITE\r\n
User-Agent: LANCOM 1906VA (over ISDN) / 10.20.0355 / 19.01.2019\r\n
Server: Lancom\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, SUBSCRIBE, UPDATE, PRACK\r\n
Supported: 100rel,replaces,timer\r\n
Content-Length: 0\r\n
\r\n
Jetzt nimmt das Unheil seinen Lauf, der LANCOM-Router sagt - 2 Minuten später - zur NetPhone "SIP/2.0 408 Request Timeout".

Code: Alles auswählen

[SIP-Packet] 2019/02/04 10:03:17,667  Devicetime: 2019/02/04 10:03:19,684 [Packet]: 
Sending datagram (568 Bytes) from 192.168.193.1:12609 to 172.20.172.223:5060 using UDP (RtgTag 193):
SIP/2.0 408 Request Timeout\r\n
Via: SIP/2.0/UDP 172.20.172.223:5060;branch=z9hG4bK-524287-1---db6ab301f4430b37;received=172.20.172.223;rport=5060\r\n
From: "ARZT-188"<sip:SIP666660@172.20.172.223>;tag=3e51447d\r\n
To: <sip:+491712223344@172.20.172.223;user=phone>;tag=-1687632881--846416631\r\n
Call-ID: GlgzHKjEAVFkL6LWIPU3KA..\r\n
CSeq: 2 INVITE\r\n
User-Agent: LANCOM 1906VA (over ISDN) / 10.20.0355 / 19.01.2019\r\n
Server: Lancom\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, SUBSCRIBE, UPDATE, PRACK\r\n
Supported: 100rel,replaces,timer\r\n
Content-Length: 0\r\n
\r\n
Und cancelt den Anruf beim Provider.

Code: Alles auswählen

[SIP-Packet] 2019/02/04 10:03:17,667  Devicetime: 2019/02/04 10:03:19,686 [Packet]: 
Sending datagram (535 Bytes) from 87.139.1.1:10844 to 217.0.26.35:5060 using TCP (RtgTag 0):
CANCEL sip:+491712223344@sip-trunk.telekom.de SIP/2.0\r\n
Via: SIP/2.0/TCP 87.139.1.1:10844;branch=z9hG4bK-e32ea837-0fc358c1;rport\r\n
From: "ARZT-188"<sip:+49306666666@sip-trunk.telekom.de;user=phone>;tag=-387964506-1537813046\r\n
To: <sip:+491712223344@sip-trunk.telekom.de>\r\n
Call-ID: 1483628639@00a05746735d\r\n
CSeq: 100 CANCEL\r\n
Max-Forwards: 70\r\n
User-Agent: LANCOM 1906VA (over ISDN) / 10.20.0355 / 19.01.2019\r\n
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, SUBSCRIBE, UPDATE, PRACK\r\n
Supported: timer\r\n
Content-Length: 0\r\n
\r\n
Der sagt natürlich inwzischen, dass der Anruf nicht existiert.

Code: Alles auswählen

[SIP-Packet] 2019/02/04 10:03:17,683  Devicetime: 2019/02/04 10:03:19,715 [Packet]: 
Receiving datagram (353 Bytes) at 87.139.1.1:10844 from 217.0.26.35:5060 using TCP (RtgTag 0):
SIP/2.0 481 Call/Transaction Does Not Exist\r\n
Via: SIP/2.0/TCP 87.139.1.1:10844;rport;branch=z9hG4bK-e32ea837-0fc358c1\r\n
To: <sip:+491712223344@sip-trunk.telekom.de>;tag=6e942a05\r\n
From: ARZT-188 <sip:+49306666666@sip-trunk.telekom.de;user=phone>;tag=-387964506-1537813046\r\n
Call-ID: 1483628639@00a05746735d\r\n
CSeq: 100 CANCEL\r\n
Content-Length: 0\r\n
\r\n
Das schickt der LANCOM-Router dann wiederum an die NetPhone.

Code: Alles auswählen

[SIP-Packet] 2019/02/04 10:03:17,683  Devicetime: 2019/02/04 10:03:19,716 [Packet]: 
Sending datagram (601 Bytes) from 192.168.193.1:12609 to 172.20.172.223:5060 using UDP (RtgTag 193):
SIP/2.0 481 Call/Transaction Does Not Exist\r\n
Via: SIP/2.0/UDP 172.20.172.223:5060;branch=z9hG4bK-524287-1---db6ab301f4430b37;received=172.20.172.223;rport=5060\r\n
From: "ARZT-188"<sip:SIP666660@172.20.172.223>;tag=3e51447d\r\n
To: <sip:+491712223344@172.20.172.223;user=phone>\r\n
Call-ID: GlgzHKjEAVFkL6LWIPU3KA..\r\n
CSeq: 2 CANCEL\r\n
User-Agent: LANCOM 1906VA (over ISDN) / 10.20.0355 / 19.01.2019\r\n
Server: Lancom\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, SUBSCRIBE, UPDATE, PRACK\r\n
Supported: timer\r\n
Contact: <sip:SIP666660@192.168.193.1:12609;transport=UDP>\r\n
Content-Length: 0\r\n
\r\n
Um dann weitere 25 Sekunden später dazu dann noch ein Timeout zu senden.

Code: Alles auswählen

[SIP-Packet] 2019/02/04 10:03:42,644  Devicetime: 2019/02/04 10:03:44,692 [Packet]: 
Sending datagram (568 Bytes) from 192.168.193.1:12609 to 172.20.172.223:5060 using UDP (RtgTag 193):
SIP/2.0 408 Request Timeout\r\n
Via: SIP/2.0/UDP 172.20.172.223:5060;branch=z9hG4bK-524287-1---db6ab301f4430b37;received=172.20.172.223;rport=5060\r\n
From: "ARZT-188"<sip:SIP666660@172.20.172.223>;tag=3e51447d\r\n
To: <sip:+491712223344@172.20.172.223;user=phone>;tag=-1687632881--846416631\r\n
Call-ID: GlgzHKjEAVFkL6LWIPU3KA..\r\n
CSeq: 2 INVITE\r\n
User-Agent: LANCOM 1906VA (over ISDN) / 10.20.0355 / 19.01.2019\r\n
Server: Lancom\r\n
Allow: REGISTER, INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, SUBSCRIBE, UPDATE, PRACK\r\n
Supported: 100rel,replaces,timer\r\n
Content-Length: 0\r\n
\r\n
Zuletzt geändert von Jirka am 07 Feb 2019, 18:51, insgesamt 1-mal geändert.
Benutzeravatar
Jirka
Beiträge: 5225
Registriert: 03 Jan 2005, 13:39
Wohnort: Ex-OPAL-Gebiet
Kontaktdaten:

Re: VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3

Beitrag von Jirka »

Hallo,

ich hatte, wie angekündigt, gestern Abend auf der NetPhone die beiden Registry-Einträge

SipMinSessionTimerIntervalSeconds
und
SipSessionTimerIntervalSeconds

erstellt mit jeweils 900 Sekunden. Danach habe ich den LinkManager-Dienst neu gestartet, wie angegeben. Auswirkungen sehe ich heute allerdings keine... Vermutlich muss doch die ganze Telefonanlage neu gestartet werden oder zumindest ein weiterer Dienst. Das kann ich jetzt aber nicht mitten am Tag machen.

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

Re: VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3

Beitrag von MoinMoin »

Moin Jirka,

mit der aktuellen Beta auf dem FTP-Server sollte das Problem gefixt sein.

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

Re: VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3

Beitrag von Jirka »

Hallo Georg,

Du meinst die 10.20.0363? Dazu hatte ich schon geschrieben im Eingangs-Posting:
Jirka hat geschrieben: 05 Feb 2019, 11:25Ich wollte es auch mal mit einer Beta probieren, aber für die 190x-er Reihe gibt es anscheinend keine Beta-10.20.0363.
Und die 10.20 habe ich nur auf neuen 1906VA-Geräten, alle anderen laufen noch mit der 10.12 oder gar der 9.24.

Vielen Dank und viele Grüße,
Jirka
mächti
Beiträge: 48
Registriert: 08 Jun 2008, 10:31

Re: VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3

Beitrag von mächti »

das gleiche kann ich bei mir feststellen, allerdings nicht mit einem SIP-Trunk sondern mit einem DIPVD Telekom (Einzelnummern) über VCM.

Netphone/Swyx 11.32.3220

Lancom 1783VA
10.20.0298RU2: abgehend i.O / ankommend i.O
10.20.0355RU3: abgehend geht nicht / ankommend i.O
10.20.0363Beta: abgehend geht nicht / ankommend i.O

Hab aber keine Zeit weiter zum testen, nach Downgrade auf 10.20.0298RU geht abgehend wieder.

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

Re: VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3

Beitrag von Jirka »

Hallo mächti,

danke für die Infos. Das widerlegt ja dann die Aussage von Georg, dass das Problem mit der 10.20.0363-Beta gefixt sein soll.

Vielen Dank und viele Grüße,
Jirka
Antworten