Ausgehende Gespräche werden seit 10.90 nicht korrekt aufgebaut

Uller · Beitrag von **Uller** » 04 Mär 2025, 14:17

Hallo zusammen,

in der vergangenen Woche habe ich meinen 1793 VA von der letzten 10.89 auf die 10.90 aktualisiert, die Konfiguration wurde nicht geändert.

Seitdem beobachte ich bei ausgehenden Telefonaten (Telekom) in vielen Fällen das folgende Verhalten

1. Das interne Telefon hat ein Rufzeichen. Auch beim Angerufenen klingelt es, wenn er abnimmt hat er aber eine tote Leitung.
1a. Manchmal hat das interne Telefon kein Rufzeichen, es ist einfach still, trotzdem klingelt es beim Angerufenen und der hat nach dem Abnehmen eine tote Leitung

2. Eingehende Telefonate funktionieren problemlos, auch von Teilnehmern bei denen die ausgehenden nicht funktionieren.

Das beschriebene Verhalten tritt sowohl bei internen VoIP Telefonen (Snom), bei ISDN-Telefonen, die über eine TK-Anlage am Lancom hängen, und bei Dect-Telefonen, die über eine Fritzbox am Lancom hängen, auf. Ich habe es auch mit verschiedenen Empfängern getestet, inklusive Mobiltelefonnummern. Bei manchen Teilnehmern funktioniert es aber auch problemlos, z.B. der Mailbox des Mobiltelefons. Ein wirkliches System habe ich noch nicht erkennen können.

[Edit]
Noch als kleine Ergänzung: Die Fritzbox ist am Lancom registriert und nicht direkt bei der Telekom, die Telefonate der Dect-Telefone laufewn also auch über den Lancom

Ich habe mal versucht einen Trace aufzuzeichnen, der hat aber knapp 10.000 Zeilen, das scheint mich nicht wirklich weiter zu bringen.

Im Changelog der 10.90 habe ich auch nichts gefunden, was ich direkt als Ursache ansehen würde.

Kurz gesagt, ich habe keine Idee was da passiert, über jeden Hinweis würde ich mich freuen, auch dazu, wonach ich im Trace ev. suchen könnte...

Fürs erste werde ich ein Downgrade auf die 10.89 machen um wieder telefonieren zu können, kann aber zwischendurch weitere Tests mit der 10.90 machen.

Schon einmal vielen Dank für die Hilfe!

Uller

awi · Beitrag von **awi** » 04 Mär 2025, 14:30

Hallo,

das klingt alles seltsam.
Kannst du von dem Fehlverhalten einen Trace aufzeichnen (Sip-Packet, Callmanager und Media)?
Am besten auch einen erfolgreichen Ruf mit der 10.80 aufzeichnen.
Ideal wäre, wenn gleichzeitig auch ein Packet-Capture von der LAN- und der WAN-Schnittstelle gemacht werden könnte.
Wenn der Angerufene einen 'toten' Ruf hat, dann heißt das ja wahrscheinlich, dass keine RTP-Daten übertragen werden.
Das könnte man dann im Packet-Capture sehen.
Wird auf irgendeiner Strecke verschlüsselt übertragen?

Warum hat der Trace mehr als 10000 Zeilen?

Gruß
Awi

Uller · Beitrag von **Uller** » 04 Mär 2025, 15:01

awi hat geschrieben: 04 Mär 2025, 14:30 Kannst du von dem Fehlverhalten einen Trace aufzeichnen (Sip-Packet, Callmanager und Media)?

Das habe ich versucht, da kommt dann dieser riesige Trace bei raus. Ich habe hier über 10 Rufnummern im Lancom registriert, da sind alleine schon unheimlich viele Pakete drin, wo irgend ein Teilnehmer sich wieder beim Lancom registriert. Wenn ich nach "To: <sip:12345@tel.t-online.de;user=phone>;" mit der angerufenen Nummer suche, finde ich 41 Treffer, das wäre überschaubar, aber hilft es auch weiter?

Verschlüsseltes SIP habe ich in der Vergangenheit mal versucht einzurichten, dass hat aber nie funktioniert. Ist daher zur Teit nicht aktiviert.

Ich habe auch mal versucht per Diff die Unterschiede des letzten Backups der Konfiguration unter 10.89 mit der aktuellen 10.90 zu vergleichen. Aber da hat sich so viel geändert oder zumindest verschoben, dass das auch nicht auf den ersten Blick aufschlussreich ist.

Ich kann mich entsinnen, vor einigen Jahren mal Probleme mit den Codecs gehabt zu haben, vielleicht auch so etwas?

Ich werde das auch mal versuchen an den Lancom Support zu melden, muss aber erst herausbekommen wie. Für den Router hab ich damals die Advanced Warranty abgeschlossen, falls das irgend etwas wert ist.

awi · Beitrag von **awi** » 04 Mär 2025, 15:10

Wenn du es über den Support machen kannst, dann wäre das natürlich der beste Weg.

An Codecs hatte ich auch schon gedacht nach deiner Fehlerbeschreibung.
Aber was das mit dem Update zu tun haben soll erschließt sich mir nicht.

Uller · Beitrag von **Uller** » 04 Mär 2025, 15:31

awi hat geschrieben: 04 Mär 2025, 15:10 Wenn du es über den Support machen kannst, dann wäre das natürlich der beste Weg.

Ich habe es jetzt geschafft, ein Support Ticket zu eröffnen.

Warum ich meine vor Ewigkeiten bei Lancom registrierte Mailadresse nicht nutzen bzw. das Kennwort nicht zurücksetzen konnte steht auf einem anderen Blatt. Aber nach erneuter Registrierung mit einer anderen Mailadresse hat es geklappt. Sobald ich vom Support etwas höre werde ich mich auch hier wieder melden.

awi hat geschrieben: 04 Mär 2025, 15:10 Aber was das mit dem Update zu tun haben soll erschließt sich mir nicht.

Mein Verdacht war, dass mit dem Update auf 10.90 vielleicht der Support für manche Codecs entfernt wurde oder ein anderer Codec als Default verwendet wird. Ist aber nur geraten. Eigentlich hatte ich gehofft, dass über den Vergleich der Konfigurationen herauszubekommen, dazu muss ich aber mal im Detail suchen, in welchen Tabellen das steht.

Uller · Beitrag von **Uller** » 04 Mär 2025, 15:54

Vom Lancom Service kam schon eine Antwort, leider keine gute:
"LANCOM Systems hat den kostenfreien Supportzugang für Kunden ohne Partner- oder Vertragsstatus eingestellt. Da Ihre PIN bzw. Seriennummer nicht zugeordnet werden konnte, wird Ihr Fall nicht bearbeitet und geschlossen. Dieses Ticket kann nicht erneut geöffnet werden."

Da es hier nicht ins Thema passt nur eine kurze Anmerkung: Eigentlich hatte ich gedacht, dass die Garantieerweiterung auch Support beinhaltet, mag ich falsch verstanden haben. Aber wenigstens Fahler sollte ich ja wohl ohne zu bezahlen melden könne...

awi · Beitrag von **awi** » 04 Mär 2025, 16:51

Hm, dann müssen wir hier mal schauen.
Auf Traces werden wir aber nicht verzichten können.
Ansonsten können wir nur spekulieren.

Uller · Beitrag von **Uller** » 04 Mär 2025, 18:22

Danke schon mal für das Angebot!

Ich habe hier schon mal alle SIP Pakete eines ausgehenden Anrufs von 123456 zu 654321 über ein snom Telefon aus dem Trace herausgesucht und (hoffentlich ausreichend) anoymisiert. Das beginnt mit dem ausgehenden Anruf und hört nach dem Abnehmen am anderen Ende (mit toter Leitung) auf. Das interne Netz hat die Domain domain.internal. Die Callmanager Pakete habe ich erst einmal entfernt, weil es sehr sehr viele waren. Vielleicht ist ja auch so schon etwas zu erkennen...

Die entsprechenden Einstellungen in der Konfigurationsdatei habe ich inzwischen auch verglichen, da gibt es aber keine Unterschiede. Nur einige Parameter, die vorher Default waren sind es mit der 10.90 nicht mehr.

Ich werde selbst in den nächsten Tagen weiter testen, muss aber schauen wann ich dazu komme.

Code: Alles auswählen

trace # call sip-packet

[SIP-Packet] 2025/03/04 13:27:13,067 [Packet]: 
Sending datagram (1482 Bytes) from 93.000.00.00:16033 to 217.0.148.133:5060 using UDP (RtgTag 0):
INVITE sip:654321@tel.t-online.de SIP/2.0\r\n
Via: SIP/2.0/UDP 93.000.00.00:16033;branch=z9hG4bK-59b6dede-b74c1fdf;rport\r\n
From: "+49XXXX123456"<sip:+49XXXX123456@tel.t-online.de;user=phone>;tag=-91729505-639771617\r\n
To: <sip:654321@tel.t-online.de;user=phone>\r\n
Call-ID: 1116498337@00a057814683\r\n
CSeq: 100 INVITE\r\n
Max-Forwards: 70\r\n
User-Agent: LANCOM 1793VA 10.90.0126\r\n
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, INFO, UPDATE\r\n
Supported: 100rel,timer,199\r\n
Contact: <sip:+49XXXX123456@93.000.00.00:16033;transport=UDP>\r\n
P-Preferred-Identity: <sip:+49XXXX123456@tel.t-online.de;user=phone>\r\n
Authorization: Digest username="XYZ@t-online.de", realm="tel.t-online.de", algorithm=MD5, uri="sip:654321@tel.t-online.de", nonce="aaaaaaaaaaaaaaaaaaaaaa", nc=00000001, response="aaaaaaaaaaaaaaaaaaaaaa",\r\n
X-Serialnumber: 00041385323A\r\n
Session-Expires: 3600\r\n
Min-SE: 90\r\n
P-Early-Media: supported\r\n
Date: Tue, 04 Mar 2025 12:27:13 GMT\r\n
Content-Type: application/sdp\r\n
Content-Length: 400\r\n
\r\n
v=0\r\n
o=- 3439245296 3439245296 IN IP4 93.000.00.00\r\n
s=call\r\n
c=IN IP4 93.000.00.00\r\n
t=0 0\r\n
m=audio 12934 RTP/AVP 9 0 8 3 99 111 18 101\r\n
a=rtpmap:9 G722/8000\r\n
a=rtpmap:0 PCMU/8000\r\n
a=rtpmap:8 PCMA/8000\r\n
a=rtpmap:3 GSM/8000\r\n
a=rtpmap:99 G726-32/8000\r\n
a=rtpmap:111 AAL2-G726-32/8000\r\n
a=rtpmap:18 G729/8000\r\n
a=rtpmap:101 telephone-event/8000\r\n
a=fmtp:18 annexb=no\r\n
a=fmtp:101 0-15\r\n
a=sendrecv\r\n
a=ptime:20\r\n

[SIP-Packet] 2025/03/04 13:27:13,079 [Packet]: 
Receiving datagram (308 Bytes) at 93.000.00.00:16033 from 217.0.148.133:5060 using UDP (RtgTag 0):
SIP/2.0 100 Trying\r\n
Via: SIP/2.0/UDP 93.000.00.00:16033;branch=z9hG4bK-59b6dede-b74c1fdf;rport\r\n
From: "+49XXXX123456" <sip:+49XXXX123456@tel.t-online.de;user=phone>;tag=-91729505-639771617\r\n
To: <sip:654321@tel.t-online.de;user=phone>\r\n
Call-ID: 1116498337@00a057814683\r\n
CSeq: 100 INVITE\r\n
Content-Length: 0\r\n
\r\n

[SIP-Packet] 2025/03/04 13:27:13,127 [Packet]: 
Receiving datagram (756 Bytes) at 93.000.00.00:16033 from 217.0.148.133:5060 using UDP (RtgTag 0):
SIP/2.0 407 Proxy Authentication Required\r\n
Via: SIP/2.0/UDP 93.000.00.00:16033;received=93.000.00.00;branch=z9hG4bK-59b6dede-b74c1fdf;rport=16033\r\n
From: "+49XXXX123456" <sip:+49XXXX123456@tel.t-online.de;user=phone>;tag=-91729505-639771617\r\n
To: <sip:654321@tel.t-online.de;user=phone>;tag=mavodi-0-4c-9d-2-ffff00-98d-ffffffffffffffff-85b60000-67b3f022-_0230A89C547B-127a-2b52a700-137d1a7-67c6f1a0-e2705\r\n
Call-ID: 1116498337@00a057814683\r\n
CSeq: 100 INVITE\r\n
Reason: SIP;cause=407;text="CC_IMS_SESS_NEED_AUTHENTICATION"\r\n
Proxy-Authenticate: Digest algorithm=MD5,realm="tel.t-online.de",nonce="aaaaaaaaaaaaaaaaaaaaaa",qop="auth"\r\n
Session-ID: 00000000000000000000000000000000; remote=1d177506f314662ceeb65ddba8fa2e4e\r\n
Content-Length: 0\r\n
\r\n


[SIP-Packet] 2025/03/04 13:27:13,128 [Packet]: 
Sending datagram (380 Bytes) from 93.000.00.00:16033 to 217.0.148.133:5060 using UDP (RtgTag 0):
ACK sip:654321@tel.t-online.de SIP/2.0\r\n
Via: SIP/2.0/UDP 93.000.00.00:16033;branch=z9hG4bK-59b6dede-b74c1fdf;rport\r\n
From: "+49XXXX123456"<sip:+49XXXX123456@tel.t-online.de;user=phone>;tag=-91729505-639771617\r\n
To: <sip:654321@tel.t-online.de;user=phone>\r\n
Call-ID: 1116498337@00a057814683\r\n
CSeq: 100 ACK\r\n
Max-Forwards: 70\r\n
User-Agent: LANCOM 1793VA 10.90.0126\r\n
Content-Length: 0\r\n
\r\n


[SIP-Packet] 2025/03/04 13:27:13,130 [Packet]: 
Sending datagram (1421 Bytes) from 93.000.00.00:16033 to 217.0.148.133:5060 using UDP (RtgTag 0):
INVITE sip:654321@tel.t-online.de SIP/2.0\r\n
Via: SIP/2.0/UDP 93.000.00.00:16033;branch=z9hG4bK-48fb6c62-23daccbd;rport\r\n
From: "+49XXXX123456"<sip:+49XXXX123456@tel.t-online.de;user=phone>;tag=-91729505-639771617\r\n
To: <sip:654321@tel.t-online.de;user=phone>\r\n
Call-ID: 1116498337@00a057814683\r\n
CSeq: 101 INVITE\r\n
Max-Forwards: 70\r\n
User-Agent: LANCOM 1793VA 10.90.0126\r\n
Allow: INVITE, ACK, CANCEL, BYE, REFER, OPTIONS, NOTIFY, SUBSCRIBE, PRACK, INFO, UPDATE\r\n
Supported: 100rel,timer,199\r\n
Proxy-Authorization: Digest username="XYZ@t-online.de", realm="tel.t-online.de", algorithm=MD5, uri="sip:654321@tel.t-online.de", nonce="aaaaaaaaaaaaaaaaaaaaaa", nc=00000001, response="aaaaaaaaaaaaaaaaaaaaaa",\r\n
Contact: <sip:+49XXXX123456@93.000.00.00:16033;transport=UDP>\r\n
Session-Expires: 3600\r\n
Min-SE: 90\r\n
P-Early-Media: supported\r\n
P-Preferred-Identity: <sip:+49XXXX123456@tel.t-online.de;user=phone>\r\n
Content-Type: application/sdp\r\n
Content-Length: 400\r\n
\r\n
v=0\r\n
o=- 3439245296 3439245296 IN IP4 93.000.00.00\r\n
s=call\r\n
c=IN IP4 93.000.00.00\r\n
t=0 0\r\n
m=audio 12934 RTP/AVP 9 0 8 3 99 111 18 101\r\n
a=rtpmap:9 G722/8000\r\n
a=rtpmap:0 PCMU/8000\r\n
a=rtpmap:8 PCMA/8000\r\n
a=rtpmap:3 GSM/8000\r\n
a=rtpmap:99 G726-32/8000\r\n
a=rtpmap:111 AAL2-G726-32/8000\r\n
a=rtpmap:18 G729/8000\r\n
a=rtpmap:101 telephone-event/8000\r\n
a=fmtp:18 annexb=no\r\n
a=fmtp:101 0-15\r\n
a=sendrecv\r\n
a=ptime:20\r\n

[SIP-Packet] 2025/03/04 13:27:13,143 [Packet]: 
Receiving datagram (308 Bytes) at 93.000.00.00:16033 from 217.0.148.133:5060 using UDP (RtgTag 0):
SIP/2.0 100 Trying\r\n
Via: SIP/2.0/UDP 93.000.00.00:16033;branch=z9hG4bK-48fb6c62-23daccbd;rport\r\n
From: "+49XXXX123456" <sip:+49XXXX123456@tel.t-online.de;user=phone>;tag=-91729505-639771617\r\n
To: <sip:654321@tel.t-online.de;user=phone>\r\n
Call-ID: 1116498337@00a057814683\r\n
CSeq: 101 INVITE\r\n
Content-Length: 0\r\n
\r\n

[SIP-Packet] 2025/03/04 13:27:13,512 [Packet]: 
Receiving datagram (876 Bytes) at 93.000.00.00:16033 from 217.0.148.133:5060 using UDP (RtgTag 0):
SIP/2.0 180 Ringing\r\n
Via: SIP/2.0/UDP 93.000.00.00:16033;received=93.000.00.00;branch=z9hG4bK-48fb6c62-23daccbd;rport=16033\r\n
From: "+49XXXX123456" <sip:+49XXXX123456@tel.t-online.de;user=phone>;tag=-91729505-639771617\r\n
To: <sip:654321@tel.t-online.de;user=phone>;tag=p65560t1741091233m7470c126562s1_1685524326-189336732\r\n
Call-ID: 1116498337@00a057814683\r\n
CSeq: 101 INVITE\r\n
Contact: <sip:mavodi-0-266-d83-4-fffffff0-fbda0000-62eed39da5505-83d-ffffffffffffffff-@217.0.148.133:5060>\r\n
Allow: UPDATE,PRACK,OPTIONS,BYE,ACK,CANCEL,INVITE,REGISTER\r\n
Record-Route: <sip:mavodi-0-266-d83-4-ffffffff-fbda0000-62eed39da5505-83d-ffffffffffffffff-mavsipodi-0-26c-191-4-6db10000-62eed39d60d4d-83d@217.0.148.133:5060;transport=udp;lr;mavsipodi-0-26c-191-4-6db10000-62eed39d60d4d-83d>\r\n
Session-ID: 00000000000000000000000000000000; remote=1d177506f314662ceeb65ddba8fa2e4e\r\n
Content-Length: 0\r\n
\r\n

[SIP-Packet] 2025/03/04 13:27:13,514 [Packet]: 
Sending datagram (471 Bytes) from 192.168.90.1:5060 to 192.168.90.90:45000 using UDP (RtgTag 90):
SIP/2.0 180 Ringing\r\n
Via: SIP/2.0/UDP 192.168.90.90:45000;branch=z9hG4bK-wxj2p94iz51d;received=192.168.90.90;rport=45000\r\n
From: "Name"<sip:123456@192.168.90.1>;tag=2uhqp6hirz\r\n
To: <sip:654321@192.168.90.1;user=phone>;tag=1302588193-776679966\r\n
Call-ID: 8df1c667e01a-5mnydcbgrvmu\r\n
CSeq: 2 INVITE\r\n
User-Agent: LANCOM 1793VA 10.90.0126\r\n
Server: Lancom\r\n
Allow: UPDATE, PRACK, OPTIONS, BYE, ACK, CANCEL, INVITE, REGISTER\r\n
Supported: replaces,timer\r\n
Content-Length: 0\r\n
\r\n

[SIP-Packet] 2025/03/04 13:27:13,560 [Packet]: 
Receiving datagram (756 Bytes) at 93.000.00.00:16033 from 217.0.148.133:5060 using UDP (RtgTag 0):
SIP/2.0 407 Proxy Authentication Required\r\n
Via: SIP/2.0/UDP 93.000.00.00:16033;received=93.000.00.00;branch=z9hG4bK-59b6dede-b74c1fdf;rport=16033\r\n
From: "+49XXXX123456" <sip:+49XXXX123456@tel.t-online.de;user=phone>;tag=-91729505-639771617\r\n
To: <sip:654321@tel.t-online.de;user=phone>;tag=mavodi-0-4c-9d-2-ffff00-98d-ffffffffffffffff-85b60000-67b3f022-_0230A89C547B-127a-2b52a700-137d1a7-67c6f1a0-e2705\r\n
Call-ID: 1116498337@00a057814683\r\n
CSeq: 100 INVITE\r\n
Reason: SIP;cause=407;text="CC_IMS_SESS_NEED_AUTHENTICATION"\r\n
Proxy-Authenticate: Digest algorithm=MD5,realm="tel.t-online.de",nonce="aaaaaaaaaaaaaaaaaaaaaa",qop="auth"\r\n
Session-ID: 00000000000000000000000000000000; remote=1d177506f314662ceeb65ddba8fa2e4e\r\n
Content-Length: 0\r\n
\r\n

[SIP-Packet] 2025/03/04 13:27:14,561 [Packet]: 
Receiving datagram (756 Bytes) at 93.000.00.00:16033 from 217.0.148.133:5060 using UDP (RtgTag 0):
SIP/2.0 407 Proxy Authentication Required\r\n
Via: SIP/2.0/UDP 93.000.00.00:16033;received=93.000.00.00;branch=z9hG4bK-59b6dede-b74c1fdf;rport=16033\r\n
From: "+49XXXX123456" <sip:+49XXXX123456@tel.t-online.de;user=phone>;tag=-91729505-639771617\r\n
To: <sip:654321@tel.t-online.de;user=phone>;tag=mavodi-0-4c-9d-2-ffff00-98d-ffffffffffffffff-85b60000-67b3f022-_0230A89C547B-127a-2b52a700-137d1a7-67c6f1a0-e2705\r\n
Call-ID: 1116498337@00a057814683\r\n
CSeq: 100 INVITE\r\n
Reason: SIP;cause=407;text="CC_IMS_SESS_NEED_AUTHENTICATION"\r\n
Proxy-Authenticate: Digest algorithm=MD5,realm="tel.t-online.de",nonce="aaaaaaaaaaaaaaaaaaaaaa",qop="auth"\r\n
Session-ID: 00000000000000000000000000000000; remote=1d177506f314662ceeb65ddba8fa2e4e\r\n
Content-Length: 0\r\n
\r\n

[SIP-Packet] 2025/03/04 13:27:15,499 [Packet]: 
Receiving datagram (0 Bytes) at 192.168.80.1:5060 from 192.168.80.80:5060 using UDP (RtgTag 0):

[SIP-Packet] 2025/03/04 13:27:16,564 [Packet]: 
Receiving datagram (756 Bytes) at 93.000.00.00:16033 from 217.0.148.133:5060 using UDP (RtgTag 0):
SIP/2.0 407 Proxy Authentication Required\r\n
Via: SIP/2.0/UDP 93.000.00.00:16033;received=93.000.00.00;branch=z9hG4bK-59b6dede-b74c1fdf;rport=16033\r\n
From: "+49XXXX123456" <sip:+49XXXX123456@tel.t-online.de;user=phone>;tag=-91729505-639771617\r\n
To: <sip:654321@tel.t-online.de;user=phone>;tag=mavodi-0-4c-9d-2-ffff00-98d-ffffffffffffffff-85b60000-67b3f022-_0230A89C547B-127a-2b52a700-137d1a7-67c6f1a0-e2705\r\n
Call-ID: 1116498337@00a057814683\r\n
CSeq: 100 INVITE\r\n
Reason: SIP;cause=407;text="CC_IMS_SESS_NEED_AUTHENTICATION"\r\n
Proxy-Authenticate: Digest algorithm=MD5,realm="tel.t-online.de",nonce="aaaaaaaaaaaaaaaaaaaaaa",qop="auth"\r\n
Session-ID: 00000000000000000000000000000000; remote=1d177506f314662ceeb65ddba8fa2e4e\r\n
Content-Length: 0\r\n
\r\n




[SIP-Packet] 2025/03/04 13:27:19,435 [Packet]: 
Receiving datagram (1436 Bytes) at 93.000.00.00:16033 from 217.0.148.133:5060 using UDP (RtgTag 0):
SIP/2.0 200 OK\r\n
Via: SIP/2.0/UDP 93.000.00.00:16033;received=93.000.00.00;branch=z9hG4bK-48fb6c62-23daccbd;rport=16033\r\n
From: "+49XXXX123456" <sip:+49XXXX123456@tel.t-online.de;user=phone>;tag=-91729505-639771617\r\n
To: <sip:654321@tel.t-online.de;user=phone>;tag=p65560t1741091233m7470c126562s1_1685524326-189336732\r\n
Call-ID: 1116498337@00a057814683\r\n
CSeq: 101 INVITE\r\n
Require: timer\r\n
Session-Expires: 1800;refresher=uas\r\n
Supported: timer\r\n
Contact: <sip:mavodi-0-266-d83-4-fffffff0-fbda0000-62eed39da5505-83d-ffffffffffffffff-@217.0.148.133:5060>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"\r\n
Allow: REGISTER,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE,PRACK,PUBLISH,UPDATE,INVITE,ACK,OPTIONS,CANCEL,BYE\r\n
Record-Route: <sip:mavodi-0-266-d83-4-ffffffff-fbda0000-62eed39da5505-83d-ffffffffffffffff-mavsipodi-0-26c-191-4-6db10000-62eed39d60d4d-83d@217.0.148.133:5060;transport=udp;lr;mavsipodi-0-26c-191-4-6db10000-62eed39d60d4d-83d>\r\n
Authentication-Info: nc=00000001,cnonce="aaaaaaaaaaaaaaaaaaaaaa",qop=auth\r\n
Session-ID: 00000000000000000000000000000000; remote=1d177506f314662ceeb65ddba8fa2e4e\r\n
Content-Type: application/sdp\r\n
Content-Length: 244\r\n
\r\n
v=0\r\n
o=ccs-0-615-4 061241371920305 2046401920 IN IP4 217.0.160.32\r\n
s=-\r\n
c=IN IP4 217.0.160.32\r\n
t=0 0\r\n
m=audio 30914 RTP/AVP 8 101\r\n
a=sendrecv\r\n
a=maxptime:20\r\n
a=ptime:20\r\n
a=rtpmap:8 PCMA/8000\r\n
a=rtpmap:101 telephone-event/8000\r\n
a=fmtp:101 0-15\r\n

[SIP-Packet] 2025/03/04 13:27:19,900 [Packet]: 
Receiving datagram (1436 Bytes) at 93.000.00.00:16033 from 217.0.148.133:5060 using UDP (RtgTag 0):
SIP/2.0 200 OK\r\n
Via: SIP/2.0/UDP 93.000.00.00:16033;received=93.000.00.00;branch=z9hG4bK-48fb6c62-23daccbd;rport=16033\r\n
From: "+49XXXX123456" <sip:+49XXXX123456@tel.t-online.de;user=phone>;tag=-91729505-639771617\r\n
To: <sip:654321@tel.t-online.de;user=phone>;tag=p65560t1741091233m7470c126562s1_1685524326-189336732\r\n
Call-ID: 1116498337@00a057814683\r\n
CSeq: 101 INVITE\r\n
Require: timer\r\n
Session-Expires: 1800;refresher=uas\r\n
Supported: timer\r\n
Contact: <sip:mavodi-0-266-d83-4-fffffff0-fbda0000-62eed39da5505-83d-ffffffffffffffff-@217.0.148.133:5060>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"\r\n
Allow: REGISTER,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE,PRACK,PUBLISH,UPDATE,INVITE,ACK,OPTIONS,CANCEL,BYE\r\n
Record-Route: <sip:mavodi-0-266-d83-4-ffffffff-fbda0000-62eed39da5505-83d-ffffffffffffffff-mavsipodi-0-26c-191-4-6db10000-62eed39d60d4d-83d@217.0.148.133:5060;transport=udp;lr;mavsipodi-0-26c-191-4-6db10000-62eed39d60d4d-83d>\r\n
Authentication-Info: nc=00000001,cnonce="aaaaaaaaaaaaaaaaaaaaaa",qop=auth\r\n
Session-ID: 00000000000000000000000000000000; remote=1d177506f314662ceeb65ddba8fa2e4e\r\n
Content-Type: application/sdp\r\n
Content-Length: 244\r\n
\r\n
v=0\r\n
o=ccs-0-615-4 061241371920305 2046401920 IN IP4 217.0.160.32\r\n
s=-\r\n
c=IN IP4 217.0.160.32\r\n
t=0 0\r\n
m=audio 30914 RTP/AVP 8 101\r\n
a=sendrecv\r\n
a=maxptime:20\r\n
a=ptime:20\r\n
a=rtpmap:8 PCMA/8000\r\n
a=rtpmap:101 telephone-event/8000\r\n
a=fmtp:101 0-15\r\n

[SIP-Packet] 2025/03/04 13:27:20,576 [Packet]: 
Receiving datagram (756 Bytes) at 93.000.00.00:16033 from 217.0.148.133:5060 using UDP (RtgTag 0):
SIP/2.0 407 Proxy Authentication Required\r\n
Via: SIP/2.0/UDP 93.000.00.00:16033;received=93.000.00.00;branch=z9hG4bK-59b6dede-b74c1fdf;rport=16033\r\n
From: "+49XXXX123456" <sip:+49XXXX123456@tel.t-online.de;user=phone>;tag=-91729505-639771617\r\n
To: <sip:654321@tel.t-online.de;user=phone>;tag=mavodi-0-4c-9d-2-ffff00-98d-ffffffffffffffff-85b60000-67b3f022-_0230A89C547B-127a-2b52a700-137d1a7-67c6f1a0-e2705\r\n
Call-ID: 1116498337@00a057814683\r\n
CSeq: 100 INVITE\r\n
Reason: SIP;cause=407;text="CC_IMS_SESS_NEED_AUTHENTICATION"\r\n
Proxy-Authenticate: Digest algorithm=MD5,realm="tel.t-online.de",nonce="aaaaaaaaaaaaaaaaaaaaaa",qop="auth"\r\n
Session-ID: 00000000000000000000000000000000; remote=1d177506f314662ceeb65ddba8fa2e4e\r\n
Content-Length: 0\r\n
\r\n

[SIP-Packet] 2025/03/04 13:27:20,900 [Packet]: 
Receiving datagram (1436 Bytes) at 93.000.00.00:16033 from 217.0.148.133:5060 using UDP (RtgTag 0):
SIP/2.0 200 OK\r\n
Via: SIP/2.0/UDP 93.000.00.00:16033;received=93.000.00.00;branch=z9hG4bK-48fb6c62-23daccbd;rport=16033\r\n
From: "+49XXXX123456" <sip:+49XXXX123456@tel.t-online.de;user=phone>;tag=-91729505-639771617\r\n
To: <sip:654321@tel.t-online.de;user=phone>;tag=p65560t1741091233m7470c126562s1_1685524326-189336732\r\n
Call-ID: 1116498337@00a057814683\r\n
CSeq: 101 INVITE\r\n
Require: timer\r\n
Session-Expires: 1800;refresher=uas\r\n
Supported: timer\r\n
Contact: <sip:mavodi-0-266-d83-4-fffffff0-fbda0000-62eed39da5505-83d-ffffffffffffffff-@217.0.148.133:5060>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"\r\n
Allow: REGISTER,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE,PRACK,PUBLISH,UPDATE,INVITE,ACK,OPTIONS,CANCEL,BYE\r\n
Record-Route: <sip:mavodi-0-266-d83-4-ffffffff-fbda0000-62eed39da5505-83d-ffffffffffffffff-mavsipodi-0-26c-191-4-6db10000-62eed39d60d4d-83d@217.0.148.133:5060;transport=udp;lr;mavsipodi-0-26c-191-4-6db10000-62eed39d60d4d-83d>\r\n
Authentication-Info: nc=00000001,cnonce="aaaaaaaaaaaaaaaaaaaaaa",qop=auth\r\n
Session-ID: 00000000000000000000000000000000; remote=1d177506f314662ceeb65ddba8fa2e4e\r\n
Content-Type: application/sdp\r\n
Content-Length: 244\r\n
\r\n
v=0\r\n
o=ccs-0-615-4 061241371920305 2046401920 IN IP4 217.0.160.32\r\n
s=-\r\n
c=IN IP4 217.0.160.32\r\n
t=0 0\r\n
m=audio 30914 RTP/AVP 8 101\r\n
a=sendrecv\r\n
a=maxptime:20\r\n
a=ptime:20\r\n
a=rtpmap:8 PCMA/8000\r\n
a=rtpmap:101 telephone-event/8000\r\n
a=fmtp:101 0-15\r\n



[SIP-Packet] 2025/03/04 13:27:22,902 [Packet]: 
Receiving datagram (1436 Bytes) at 93.000.00.00:16033 from 217.0.148.133:5060 using UDP (RtgTag 0):
SIP/2.0 200 OK\r\n
Via: SIP/2.0/UDP 93.000.00.00:16033;received=93.000.00.00;branch=z9hG4bK-48fb6c62-23daccbd;rport=16033\r\n
From: "+49XXXX123456" <sip:+49XXXX123456@tel.t-online.de;user=phone>;tag=-91729505-639771617\r\n
To: <sip:654321@tel.t-online.de;user=phone>;tag=p65560t1741091233m7470c126562s1_1685524326-189336732\r\n
Call-ID: 1116498337@00a057814683\r\n
CSeq: 101 INVITE\r\n
Require: timer\r\n
Session-Expires: 1800;refresher=uas\r\n
Supported: timer\r\n
Contact: <sip:mavodi-0-266-d83-4-fffffff0-fbda0000-62eed39da5505-83d-ffffffffffffffff-@217.0.148.133:5060>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"\r\n
Allow: REGISTER,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE,PRACK,PUBLISH,UPDATE,INVITE,ACK,OPTIONS,CANCEL,BYE\r\n
Record-Route: <sip:mavodi-0-266-d83-4-ffffffff-fbda0000-62eed39da5505-83d-ffffffffffffffff-mavsipodi-0-26c-191-4-6db10000-62eed39d60d4d-83d@217.0.148.133:5060;transport=udp;lr;mavsipodi-0-26c-191-4-6db10000-62eed39d60d4d-83d>\r\n
Authentication-Info: nc=00000001,cnonce="aaaaaaaaaaaaaaaaaaaaaa",qop=auth\r\n
Session-ID: 00000000000000000000000000000000; remote=1d177506f314662ceeb65ddba8fa2e4e\r\n
Content-Type: application/sdp\r\n
Content-Length: 244\r\n
\r\n
v=0\r\n
o=ccs-0-615-4 061241371920305 2046401920 IN IP4 217.0.160.32\r\n
s=-\r\n
c=IN IP4 217.0.160.32\r\n
t=0 0\r\n
m=audio 30914 RTP/AVP 8 101\r\n
a=sendrecv\r\n
a=maxptime:20\r\n
a=ptime:20\r\n
a=rtpmap:8 PCMA/8000\r\n
a=rtpmap:101 telephone-event/8000\r\n
a=fmtp:101 0-15\r\n


[SIP-Packet] 2025/03/04 13:27:24,586 [Packet]: 
Receiving datagram (756 Bytes) at 93.000.00.00:16033 from 217.0.148.133:5060 using UDP (RtgTag 0):
SIP/2.0 407 Proxy Authentication Required\r\n
Via: SIP/2.0/UDP 93.000.00.00:16033;received=93.000.00.00;branch=z9hG4bK-59b6dede-b74c1fdf;rport=16033\r\n
From: "+49XXXX123456" <sip:+49XXXX123456@tel.t-online.de;user=phone>;tag=-91729505-639771617\r\n
To: <sip:654321@tel.t-online.de;user=phone>;tag=mavodi-0-4c-9d-2-ffff00-98d-ffffffffffffffff-85b60000-67b3f022-_0230A89C547B-127a-2b52a700-137d1a7-67c6f1a0-e2705\r\n
Call-ID: 1116498337@00a057814683\r\n
CSeq: 100 INVITE\r\n
Reason: SIP;cause=407;text="CC_IMS_SESS_NEED_AUTHENTICATION"\r\n
Proxy-Authenticate: Digest algorithm=MD5,realm="tel.t-online.de",nonce="aaaaaaaaaaaaaaaaaaaaaa",qop="auth"\r\n
Session-ID: 00000000000000000000000000000000; remote=1d177506f314662ceeb65ddba8fa2e4e\r\n
Content-Length: 0\r\n
\r\n

[SIP-Packet] 2025/03/04 13:27:26,913 [Packet]: 
Receiving datagram (1436 Bytes) at 93.000.00.00:16033 from 217.0.148.133:5060 using UDP (RtgTag 0):
SIP/2.0 200 OK\r\n
Via: SIP/2.0/UDP 93.000.00.00:16033;received=93.000.00.00;branch=z9hG4bK-48fb6c62-23daccbd;rport=16033\r\n
From: "+49XXXX123456" <sip:+49XXXX123456@tel.t-online.de;user=phone>;tag=-91729505-639771617\r\n
To: <sip:654321@tel.t-online.de;user=phone>;tag=p65560t1741091233m7470c126562s1_1685524326-189336732\r\n
Call-ID: 1116498337@00a057814683\r\n
CSeq: 101 INVITE\r\n
Require: timer\r\n
Session-Expires: 1800;refresher=uas\r\n
Supported: timer\r\n
Contact: <sip:mavodi-0-266-d83-4-fffffff0-fbda0000-62eed39da5505-83d-ffffffffffffffff-@217.0.148.133:5060>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"\r\n
Allow: REGISTER,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE,PRACK,PUBLISH,UPDATE,INVITE,ACK,OPTIONS,CANCEL,BYE\r\n
Record-Route: <sip:mavodi-0-266-d83-4-ffffffff-fbda0000-62eed39da5505-83d-ffffffffffffffff-mavsipodi-0-26c-191-4-6db10000-62eed39d60d4d-83d@217.0.148.133:5060;transport=udp;lr;mavsipodi-0-26c-191-4-6db10000-62eed39d60d4d-83d>\r\n
Authentication-Info: nc=00000001,cnonce="aaaaaaaaaaaaaaaaaaaaaa",qop=auth\r\n
Session-ID: 00000000000000000000000000000000; remote=1d177506f314662ceeb65ddba8fa2e4e\r\n
Content-Type: application/sdp\r\n
Content-Length: 244\r\n
\r\n
v=0\r\n
o=ccs-0-615-4 061241371920305 2046401920 IN IP4 217.0.160.32\r\n
s=-\r\n
c=IN IP4 217.0.160.32\r\n
t=0 0\r\n
m=audio 30914 RTP/AVP 8 101\r\n
a=sendrecv\r\n
a=maxptime:20\r\n
a=ptime:20\r\n
a=rtpmap:8 PCMA/8000\r\n
a=rtpmap:101 telephone-event/8000\r\n
a=fmtp:101 0-15\r\n

[SIP-Packet] 2025/03/04 13:27:28,601 [Packet]: 
Receiving datagram (756 Bytes) at 93.000.00.00:16033 from 217.0.148.133:5060 using UDP (RtgTag 0):
SIP/2.0 407 Proxy Authentication Required\r\n
Via: SIP/2.0/UDP 93.000.00.00:16033;received=93.000.00.00;branch=z9hG4bK-59b6dede-b74c1fdf;rport=16033\r\n
From: "+49XXXX123456" <sip:+49XXXX123456@tel.t-online.de;user=phone>;tag=-91729505-639771617\r\n
To: <sip:654321@tel.t-online.de;user=phone>;tag=mavodi-0-4c-9d-2-ffff00-98d-ffffffffffffffff-85b60000-67b3f022-_0230A89C547B-127a-2b52a700-137d1a7-67c6f1a0-e2705\r\n
Call-ID: 1116498337@00a057814683\r\n
CSeq: 100 INVITE\r\n
Reason: SIP;cause=407;text="CC_IMS_SESS_NEED_AUTHENTICATION"\r\n
Proxy-Authenticate: Digest algorithm=MD5,realm="tel.t-online.de",nonce="aaaaaaaaaaaaaaaaaaaaaa",qop="auth"\r\n
Session-ID: 00000000000000000000000000000000; remote=1d177506f314662ceeb65ddba8fa2e4e\r\n
Content-Length: 0\r\n
\r\n

[SIP-Packet] 2025/03/04 13:27:30,920 [Packet]: 
Receiving datagram (1436 Bytes) at 93.000.00.00:16033 from 217.0.148.133:5060 using UDP (RtgTag 0):
SIP/2.0 200 OK\r\n
Via: SIP/2.0/UDP 93.000.00.00:16033;received=93.000.00.00;branch=z9hG4bK-48fb6c62-23daccbd;rport=16033\r\n
From: "+49XXXX123456" <sip:+49XXXX123456@tel.t-online.de;user=phone>;tag=-91729505-639771617\r\n
To: <sip:654321@tel.t-online.de;user=phone>;tag=p65560t1741091233m7470c126562s1_1685524326-189336732\r\n
Call-ID: 1116498337@00a057814683\r\n
CSeq: 101 INVITE\r\n
Require: timer\r\n
Session-Expires: 1800;refresher=uas\r\n
Supported: timer\r\n
Contact: <sip:mavodi-0-266-d83-4-fffffff0-fbda0000-62eed39da5505-83d-ffffffffffffffff-@217.0.148.133:5060>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"\r\n
Allow: REGISTER,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE,PRACK,PUBLISH,UPDATE,INVITE,ACK,OPTIONS,CANCEL,BYE\r\n
Record-Route: <sip:mavodi-0-266-d83-4-ffffffff-fbda0000-62eed39da5505-83d-ffffffffffffffff-mavsipodi-0-26c-191-4-6db10000-62eed39d60d4d-83d@217.0.148.133:5060;transport=udp;lr;mavsipodi-0-26c-191-4-6db10000-62eed39d60d4d-83d>\r\n
Authentication-Info: nc=00000001,cnonce="aaaaaaaaaaaaaaaaaaaaaa",qop=auth\r\n
Session-ID: 00000000000000000000000000000000; remote=1d177506f314662ceeb65ddba8fa2e4e\r\n
Content-Type: application/sdp\r\n
Content-Length: 244\r\n
\r\n
v=0\r\n
o=ccs-0-615-4 061241371920305 2046401920 IN IP4 217.0.160.32\r\n
s=-\r\n
c=IN IP4 217.0.160.32\r\n
t=0 0\r\n
m=audio 30914 RTP/AVP 8 101\r\n
a=sendrecv\r\n
a=maxptime:20\r\n
a=ptime:20\r\n
a=rtpmap:8 PCMA/8000\r\n
a=rtpmap:101 telephone-event/8000\r\n
a=fmtp:101 0-15\r\n

[SIP-Packet] 2025/03/04 13:27:32,616 [Packet]: 
Receiving datagram (756 Bytes) at 93.000.00.00:16033 from 217.0.148.133:5060 using UDP (RtgTag 0):
SIP/2.0 407 Proxy Authentication Required\r\n
Via: SIP/2.0/UDP 93.000.00.00:16033;received=93.000.00.00;branch=z9hG4bK-59b6dede-b74c1fdf;rport=16033\r\n
From: "+49XXXX123456" <sip:+49XXXX123456@tel.t-online.de;user=phone>;tag=-91729505-639771617\r\n
To: <sip:654321@tel.t-online.de;user=phone>;tag=mavodi-0-4c-9d-2-ffff00-98d-ffffffffffffffff-85b60000-67b3f022-_0230A89C547B-127a-2b52a700-137d1a7-67c6f1a0-e2705\r\n
Call-ID: 1116498337@00a057814683\r\n
CSeq: 100 INVITE\r\n
Reason: SIP;cause=407;text="CC_IMS_SESS_NEED_AUTHENTICATION"\r\n
Proxy-Authenticate: Digest algorithm=MD5,realm="tel.t-online.de",nonce="aaaaaaaaaaaaaaaaaaaaaa",qop="auth"\r\n
Session-ID: 00000000000000000000000000000000; remote=1d177506f314662ceeb65ddba8fa2e4e\r\n
Content-Length: 0\r\n
\r\n

[SIP-Packet] 2025/03/04 13:27:34,929 [Packet]: 
Receiving datagram (1436 Bytes) at 93.000.00.00:16033 from 217.0.148.133:5060 using UDP (RtgTag 0):
SIP/2.0 200 OK\r\n
Via: SIP/2.0/UDP 93.000.00.00:16033;received=93.000.00.00;branch=z9hG4bK-48fb6c62-23daccbd;rport=16033\r\n
From: "+49XXXX123456" <sip:+49XXXX123456@tel.t-online.de;user=phone>;tag=-91729505-639771617\r\n
To: <sip:654321@tel.t-online.de;user=phone>;tag=p65560t1741091233m7470c126562s1_1685524326-189336732\r\n
Call-ID: 1116498337@00a057814683\r\n
CSeq: 101 INVITE\r\n
Require: timer\r\n
Session-Expires: 1800;refresher=uas\r\n
Supported: timer\r\n
Contact: <sip:mavodi-0-266-d83-4-fffffff0-fbda0000-62eed39da5505-83d-ffffffffffffffff-@217.0.148.133:5060>;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"\r\n
Allow: REGISTER,REFER,NOTIFY,SUBSCRIBE,INFO,MESSAGE,PRACK,PUBLISH,UPDATE,INVITE,ACK,OPTIONS,CANCEL,BYE\r\n
Record-Route: <sip:mavodi-0-266-d83-4-ffffffff-fbda0000-62eed39da5505-83d-ffffffffffffffff-mavsipodi-0-26c-191-4-6db10000-62eed39d60d4d-83d@217.0.148.133:5060;transport=udp;lr;mavsipodi-0-26c-191-4-6db10000-62eed39d60d4d-83d>\r\n
Authentication-Info: nc=00000001,cnonce="aaaaaaaaaaaaaaaaaaaaaa",qop=auth\r\n
Session-ID: 00000000000000000000000000000000; remote=1d177506f314662ceeb65ddba8fa2e4e\r\n
Content-Type: application/sdp\r\n
Content-Length: 244\r\n
\r\n
v=0\r\n
o=ccs-0-615-4 061241371920305 2046401920 IN IP4 217.0.160.32\r\n
s=-\r\n
c=IN IP4 217.0.160.32\r\n
t=0 0\r\n
m=audio 30914 RTP/AVP 8 101\r\n
a=sendrecv\r\n
a=maxptime:20\r\n
a=ptime:20\r\n
a=rtpmap:8 PCMA/8000\r\n
a=rtpmap:101 telephone-event/8000\r\n
a=fmtp:101 0-15\r\n

[SIP-Packet] 2025/03/04 13:27:35,512 [Packet]: 
Receiving datagram (0 Bytes) at 192.168.80.1:5060 from 192.168.80.80:5060 using UDP (RtgTag 0):

[SIP-Packet] 2025/03/04 13:27:36,420 [Packet]: 
Receiving datagram (614 Bytes) at 192.168.90.1:5060 from 192.168.90.90:45000 using UDP (RtgTag 90):
CANCEL sip:654321@192.168.90.1;user=phone SIP/2.0\r\n
Via: SIP/2.0/UDP 192.168.90.90:45000;branch=z9hG4bK-wxj2p94iz51d;rport\r\n
From: "Name" <sip:123456@192.168.90.1>;tag=2uhqp6hirz\r\n
To: <sip:654321@192.168.90.1;user=phone>\r\n
Call-ID: 8df1c667e01a-5mnydcbgrvmu\r\n
CSeq: 2 CANCEL\r\n
Max-Forwards: 70\r\n
User-Agent: snomD345/10.1.175.10\r\n
Reason: SIP;cause=487;text="Request terminated by user"\r\n
Authorization: Digest username="123456",realm="domain.internal",nonce="aaaaaaaaaaaaaaaaaaaaaa",algorithm=MD5\r\n
Content-Length: 0\r\n
\r\n

[SIP-Packet] 2025/03/04 13:27:36,421 [Packet]: 
Sending datagram (365 Bytes) from 192.168.90.1:5060 to 192.168.90.90:45000 using UDP (RtgTag 90):
SIP/2.0 200 OK\r\n
Via: SIP/2.0/UDP 192.168.90.90:45000;branch=z9hG4bK-wxj2p94iz51d;received=192.168.90.90;rport=45000\r\n
From: "Name"<sip:123456@192.168.90.1>;tag=2uhqp6hirz\r\n
To: <sip:654321@192.168.90.1;user=phone>\r\n
Call-ID: 8df1c667e01a-5mnydcbgrvmu\r\n
CSeq: 2 CANCEL\r\n
User-Agent: LANCOM 1793VA 10.90.0126\r\n
Server: Lancom\r\n
Supported: timer\r\n
Content-Length: 0\r\n
\r\n

[SIP-Packet] 2025/03/04 13:27:36,421 [Packet]: 
Sending datagram (482 Bytes) from 192.168.90.1:5060 to 192.168.90.90:45000 using UDP (RtgTag 90):
SIP/2.0 487 Request Terminated\r\n
Via: SIP/2.0/UDP 192.168.90.90:45000;branch=z9hG4bK-wxj2p94iz51d;received=192.168.90.90;rport=45000\r\n
From: "Name"<sip:123456@192.168.90.1>;tag=2uhqp6hirz\r\n
To: <sip:654321@192.168.90.1;user=phone>;tag=1302588193-776679966\r\n
Call-ID: 8df1c667e01a-5mnydcbgrvmu\r\n
CSeq: 2 INVITE\r\n
User-Agent: LANCOM 1793VA 10.90.0126\r\n
Server: Lancom\r\n
Allow: UPDATE, PRACK, OPTIONS, BYE, ACK, CANCEL, INVITE, REGISTER\r\n
Supported: replaces,timer\r\n
Content-Length: 0\r\n
\r\n


[SIP-Packet] 2025/03/04 13:27:36,424 [Packet]: 
Sending datagram (624 Bytes) from 93.000.00.00:16033 to 217.0.148.133:5060 using UDP (RtgTag 0):
CANCEL sip:654321@tel.t-online.de SIP/2.0\r\n
Via: SIP/2.0/UDP 93.000.00.00:16033;branch=z9hG4bK-48fb6c62-23daccbd;rport\r\n
Route: <sip:mavodi-0-266-d83-4-ffffffff-fbda0000-62eed39da5505-83d-ffffffffffffffff-mavsipodi-0-26c-191-4-6db10000-62eed39d60d4d-83d@217.0.148.133:5060;transport=udp;lr;mavsipodi-0-26c-191-4-6db10000-62eed39d60d4d-83d>\r\n
From: "+49XXXX123456"<sip:+49XXXX123456@tel.t-online.de;user=phone>;tag=-91729505-639771617\r\n
To: <sip:654321@tel.t-online.de;user=phone>\r\n
Call-ID: 1116498337@00a057814683\r\n
CSeq: 101 CANCEL\r\n
Max-Forwards: 70\r\n
User-Agent: LANCOM 1793VA 10.90.0126\r\n
Supported: timer\r\n
Content-Length: 0\r\n
\r\n

[SIP-Packet] 2025/03/04 13:27:36,437 [Packet]: 
Receiving datagram (407 Bytes) at 93.000.00.00:16033 from 217.0.148.133:5060 using UDP (RtgTag 0):
SIP/2.0 200 OK\r\n
Via: SIP/2.0/UDP 93.000.00.00:16033;received=93.000.00.00;branch=z9hG4bK-48fb6c62-23daccbd;rport=16033\r\n
From: "+49XXXX123456" <sip:+49XXXX123456@tel.t-online.de;user=phone>;tag=-91729505-639771617\r\n
To: <sip:654321@tel.t-online.de;user=phone>;tag=p65560t1741091233m7470c126562s1_1685524326-189336732\r\n
Call-ID: 1116498337@00a057814683\r\n
CSeq: 101 CANCEL\r\n
Supported: timer\r\n
Content-Length: 0\r\n
\r\n

[SIP-Packet] 2025/03/04 13:27:36,456 [Packet]: 
Receiving datagram (642 Bytes) at 192.168.90.1:5060 from 192.168.90.90:45000 using UDP (RtgTag 90):
ACK sip:654321@192.168.90.1;user=phone SIP/2.0\r\n
Via: SIP/2.0/UDP 192.168.90.90:45000;branch=z9hG4bK-wxj2p94iz51d;rport\r\n
From: "Name" <sip:123456@192.168.90.1>;tag=2uhqp6hirz\r\n
To: <sip:654321@192.168.90.1;user=phone>;tag=1302588193-776679966\r\n
Call-ID: 8df1c667e01a-5mnydcbgrvmu\r\n
CSeq: 2 ACK\r\n
Max-Forwards: 70\r\n
User-Agent: snomD345/10.1.175.10\r\n
Contact: "Name" <sip:123456@192.168.90.90:45000>;reg-id=1\r\n
Authorization: Digest username="123456",realm="domain.internal",nonce="aaaaaaaaaaaaaaaaaaaaaa",algorithm=MD5\r\n
Content-Length: 0\r\n
\r\n

[SIP-Packet] 2025/03/04 13:27:36,628 [Packet]: 
Receiving datagram (756 Bytes) at 93.000.00.00:16033 from 217.0.148.133:5060 using UDP (RtgTag 0):
SIP/2.0 407 Proxy Authentication Required\r\n
Via: SIP/2.0/UDP 93.000.00.00:16033;received=93.000.00.00;branch=z9hG4bK-59b6dede-b74c1fdf;rport=16033\r\n
From: "+49XXXX123456" <sip:+49XXXX123456@tel.t-online.de;user=phone>;tag=-91729505-639771617\r\n
To: <sip:654321@tel.t-online.de;user=phone>;tag=mavodi-0-4c-9d-2-ffff00-98d-ffffffffffffffff-85b60000-67b3f022-_0230A89C547B-127a-2b52a700-137d1a7-67c6f1a0-e2705\r\n
Call-ID: 1116498337@00a057814683\r\n
CSeq: 100 INVITE\r\n
Reason: SIP;cause=407;text="CC_IMS_SESS_NEED_AUTHENTICATION"\r\n
Proxy-Authenticate: Digest algorithm=MD5,realm="tel.t-online.de",nonce="aaaaaaaaaaaaaaaaaaaaaa",qop="auth"\r\n
Session-ID: 00000000000000000000000000000000; remote=1d177506f314662ceeb65ddba8fa2e4e\r\n
Content-Length: 0\r\n
\r\n

Dr.Einstein · Beitrag von **Dr.Einstein** » 04 Mär 2025, 19:34

Der Lancom schickt nach dem 2. 407 Proxy Authentication Required (oder Session Progress, was hier aber im Mitschnitt fehlt?) anders als in der 10.80 kein PRACK mehr. Komisch, wie so etwas durch die LCOS Qualitätssicherung rutschen konnte.

Uller · Beitrag von **Uller** » 04 Mär 2025, 22:10

Dr.Einstein hat geschrieben: 04 Mär 2025, 19:34 Der Lancom schickt nach dem 2. 407 Proxy Authentication Required (oder Session Progress, was hier aber im Mitschnitt fehlt?) anders als in der 10.80 kein PRACK mehr. Komisch, wie so etwas durch die LCOS Qualitätssicherung rutschen konnte.

Danke fürs Anschauen. Ich prüfe morgen noch einmal die komplette Datei, ob mit da ein PRACK oder Session Progress durchgerutscht ist.

Dann wäre es wohl ein Bug in der 10.90, den ich aber offensichtlich ohne kostenpflichtigen Support nicht melden kann… Gibt es sonst eine Möglichkeit, wie ich Lancom drauf stoßen kann?

Uller · Beitrag von **Uller** » 05 Mär 2025, 11:43

Habe mir den ursprünglichen Trace noch einmal angeschaut. Einträge der Art "PRACK sip:..." finde ich nur zu eingehenden Verbindungen, die ja auch korrekt abgewickelt werden.

Einträge bezüglich Progress gibt es nur in dieser Art, das war aber vermutlich nicht gemeint:

Code: Alles auswählen

[Callmanager] 2025/03/04 13:27:13,129 [SIP-CALL] : - info       : progress-info      : yes
[Callmanager] 2025/03/04 13:27:13,129 [SIP-CALL] : - info       : Progress           : Len=2, Location=85, ProgDesc=83

Ich gehe jetzt erst einmal von einem Fehler in LCOS 10.90 aus, bei dem ich selbst nichts weiter machen kann. Euch allen vielen Dank für Eure Hilfe!!

Dr.Einstein · Beitrag von **Dr.Einstein** » 05 Mär 2025, 13:13

Du sagtest Telekom ist dein Provider? Stell mal testweise die SIP-Leitung von UDP auf TLS (bzw automatisch) um. Der Lancom muss beim Aufbau bezogen auf Proxy Auth. etwas anders machen. Vielleicht hast du Glück, dass es dann durchgeht, weil der Zustand so gar nicht abgearbeitet werden muss.

Uller · Beitrag von **Uller** » 05 Mär 2025, 13:48

Dr.Einstein hat geschrieben: 05 Mär 2025, 13:13 Du sagtest Telekom ist dein Provider? Stell mal testweise die SIP-Leitung von UDP auf TLS (bzw automatisch) um. Der Lancom muss beim Aufbau bezogen auf Proxy Auth. etwas anders machen. Vielleicht hast du Glück, dass es dann durchgeht, weil der Zustand so gar nicht abgearbeitet werden muss.

Super, sehr guter Tipp, vielen Dank!

Wenn ich auf TLS Umstelle können die Leitungen nicht registriert werden, Das hatte ich in der Vergangenheit schon, als ich mal versucht habe auf verschlüsseltes SIP umzustellen. Warum auch immer, nach allem was ich gelesen habe, sollte das bei der Telekom eigentlich funktionieren.

Wenn ich auf TCP stelle, wird die Leitung aber registriert und nach einem ersten Test können damit auch die Telefonate wieder aufgebaut werden. Ich habe jetzt alle Leitungen umgestellt und werde das ganze weiter beobachten. Vielleicht ist es deswegen auch bei Lancom und im Betatest nicht aufgefallen, wobei UDP ja so ungewöhnlich eigentlich nicht ist.

Das SIPS Thema werde ich bei Gelegenheit noch einmal angehen.

Dr.Einstein · Beitrag von **Dr.Einstein** » 05 Mär 2025, 14:02

Interessenhalber, auf was verhandelt der Lancom, wenn du auf automatisch stellst? TCP ohne TLS? Oder versucht er TLS kommt aber nicht hoch? Eigentlich müsste mittlerweile alles gehen:

Code: Alles auswählen

C:\Users\User>nslookup -q=SRV _sip._tcp.tel.t-online.de 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

Nicht autorisierende Antwort:
_sip._tcp.tel.t-online.de       SRV service location:
          priority       = 20
          weight         = 0
          port           = 5060
          svr hostname   = hno002-l01-mav-pc-rt-001.edns.t-ipnet.de
_sip._tcp.tel.t-online.de       SRV service location:
          priority       = 30
          weight         = 0
          port           = 5060
          svr hostname   = nes008-f01-mav-pc-rt-001.edns.t-ipnet.de
_sip._tcp.tel.t-online.de       SRV service location:
          priority       = 10
          weight         = 0
          port           = 5060
          svr hostname   = ber500-l01-mav-pc-rt-001.edns.t-ipnet.de

C:\Users\User>nslookup -q=SRV _sips._tcp.tel.t-online.de 8.8.8.8
Server:  dns.google
Address:  8.8.8.8

Nicht autorisierende Antwort:
_sips._tcp.tel.t-online.de      SRV service location:
          priority       = 30
          weight         = 0
          port           = 5061
          svr hostname   = nes008-f01-mav-pc-rt-001.edns.t-ipnet.de
_sips._tcp.tel.t-online.de      SRV service location:
          priority       = 20
          weight         = 0
          port           = 5061
          svr hostname   = hno002-l01-mav-pc-rt-001.edns.t-ipnet.de
_sips._tcp.tel.t-online.de      SRV service location:
          priority       = 10
          weight         = 0
          port           = 5061
          svr hostname   = ber500-l01-mav-pc-rt-001.edns.t-ipnet.de

Uller · Beitrag von **Uller** » 05 Mär 2025, 15:17

Dr.Einstein hat geschrieben: 05 Mär 2025, 14:02 Interessenhalber, auf was verhandelt der Lancom, wenn du auf automatisch stellst? TCP ohne TLS? Oder versucht er TLS kommt aber nicht hoch? Eigentlich müsste mittlerweile alles gehen:

Ich schätze mal, dass geht dann wohl auf meine Blödheit....

Nur auf "automatisch" kann die Nummer nicht registriert werden. Wenn ich aber dann auch den Port auf 5061 umstelle, erfolgt die Registrierung per TLS. Eigentlich hatte ich die Doku so verstanden, dass der Port automatisch ermittelt wird, hätte ich allerdings auch gleich mal testen können.

Ich habe es jetzt auf "automatisch" eingestellt, Sprachverschlüsselung auf "bevorzugt", wobei ich auch da die Doku so verstehe, dass die eh automatisch eingestellt wird, wenn die Registrierung per TLS erfolgt und werde weiter beobachten....

Was ich bei meinen Tests damals als Port eingestellt hatte kann ich nicht mehr sagen, ev. lag es da auch schon daran.

Noch einmal vielen Dank!

LANCOM-Forum.de

Ausgehende Gespräche werden seit 10.90 nicht korrekt aufgebaut

Ausgehende Gespräche werden seit 10.90 nicht korrekt aufgebaut

Re: Ausgehende Gespräche werden seit 10.90 nicht korrekt aufgebaut

Re: Ausgehende Gespräche werden seit 10.90 nicht korrekt aufgebaut

Re: Ausgehende Gespräche werden seit 10.90 nicht korrekt aufgebaut

Re: Ausgehende Gespräche werden seit 10.90 nicht korrekt aufgebaut

Re: Ausgehende Gespräche werden seit 10.90 nicht korrekt aufgebaut

Re: Ausgehende Gespräche werden seit 10.90 nicht korrekt aufgebaut

Re: Ausgehende Gespräche werden seit 10.90 nicht korrekt aufgebaut

Re: Ausgehende Gespräche werden seit 10.90 nicht korrekt aufgebaut

Re: Ausgehende Gespräche werden seit 10.90 nicht korrekt aufgebaut

Re: Ausgehende Gespräche werden seit 10.90 nicht korrekt aufgebaut

Re: Ausgehende Gespräche werden seit 10.90 nicht korrekt aufgebaut

Re: Ausgehende Gespräche werden seit 10.90 nicht korrekt aufgebaut

Re: Ausgehende Gespräche werden seit 10.90 nicht korrekt aufgebaut

Re: Ausgehende Gespräche werden seit 10.90 nicht korrekt aufgebaut