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
VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3
Moderator: Lancom-Systems Moderatoren
Re: VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3
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.
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.
Re: VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3
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?
Vielen Dank und viele Grüße,
Jirka
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?
Vielen Dank und viele Grüße,
Jirka
Re: VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3
Moin Jirka,
normalerweise sollte der gewünschte Wert im Antwortpaket mit der Fehlermeldung stehen. Ist zumindest bei anderen Timeouts so.
Ciao, Georg
normalerweise sollte der gewünschte Wert im Antwortpaket mit der Fehlermeldung stehen. Ist zumindest bei anderen Timeouts so.
Ciao, Georg
Re: VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3
Hallo MoinMoin,
tatsächlich, über dem Reason steht
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
tatsächlich, über dem Reason steht
Code: Alles auswählen
Min-SE: 900Also 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: 3224
- Registriert: 12 Jan 2010, 14:10
Re: VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3
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
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
Re: VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3
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
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
Re: VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3
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
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
Re: VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3
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.
P. S.: Hallo auch an hyperjojo. Ich hatte hier schon angefangen mit dem Posting, da war Deines noch nicht da
Viele Grüße,
Jirka
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.
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:37Bin mal gespannt, ob du sporadische ankommende Nichterreichbarkeit des Anschlusses oder ähnliches hast.
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.
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.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
P. S.: Hallo auch an hyperjojo. Ich hatte hier schon angefangen mit dem Posting, da war Deines noch nicht da
Viele Grüße,
Jirka
Re: VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3
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.
Der LANCOM sagt dazu - wie immer - Trying.
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.
Telekom sagt Trying.
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.)
Das bestätigt der LANCOM-Router.
Und leitet nun das ganze an die NetPhone weiter. (Die Zeile "Reason: TSSI;cause=4220001" wird übrigens verschluckt.)
Die NetPhone bestätigt das.
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.
Der LANCOM-Router sagt zur NetPhone Trying, das ist unspektakulär.
Aber jetzt geht es schon los, der LANCOM-Router sagt zur NetPhone OK! Ja wie denn das bitteschön?
Jetzt nimmt das Unheil seinen Lauf, der LANCOM-Router sagt - 2 Minuten später - zur NetPhone "SIP/2.0 408 Request Timeout".
Und cancelt den Anruf beim Provider.
Der sagt natürlich inwzischen, dass der Anruf nicht existiert.
Das schickt der LANCOM-Router dann wiederum an die NetPhone.
Um dann weitere 25 Sekunden später dazu dann noch ein Timeout zu senden.
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\nCode: 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\nCode: 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\nCode: 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\nCode: 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\nCode: 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\nCode: 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\nCode: 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\nCode: 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\nCode: 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\nCode: 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\nCode: 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\nCode: 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\nCode: 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\nCode: 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\nCode: 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.
Re: VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3
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
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
Re: VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3
Moin Jirka,
mit der aktuellen Beta auf dem FTP-Server sollte das Problem gefixt sein.
Ciao, Georg
mit der aktuellen Beta auf dem FTP-Server sollte das Problem gefixt sein.
Ciao, Georg
Re: VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3
Hallo Georg,
Du meinst die 10.20.0363? Dazu hatte ich schon geschrieben im Eingangs-Posting:
Vielen Dank und viele Grüße,
Jirka
Du meinst die 10.20.0363? Dazu hatte ich schon geschrieben im Eingangs-Posting:
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.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.
Vielen Dank und viele Grüße,
Jirka
Re: VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3
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
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
Re: VCM in Kombination mit NetPhone/Swyx - keine abgehenden Gespräche mehr mit 10.20-RU3
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
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