Hallo,
SIP-Verbindungen zu VoIP-Anschlüssen bei Arcor werden (in meinem Fall) nach exakt 120 s getrennt.
Meine Analyse des Problems führt mich zu dieser Annahme:
Bei LANCOM werden SIP Req OPTIONS weder beantwortet noch an SIP-Clients weitergeleitet, obwohl das nach RFC3261 (11.2) wohl erforderlich wäre. Arcor gibt eine Karenzzeit von 2 min und trennt danach.
Die Einzelheiten:
Arcor trennt nach 120 Sekunden mit Cseq 4 BYE (Reason Q.850; cause=41; text="0"). Der LANCOM als
Relay gibt "Cseq 3 BYE" weiter.
[quote]Cause No. 41 - temporary failure [Q.850]
This cause indicates that the network is not functioning correctly and that the condition is likely to be resolved quickly;
e.g., the user may wish to try another call attempt almost immediately.
Typical scenarios include: Network failure.
[/quote]
Nach einiger Recherche im Internet scheint ein mögliche Ursache zu sein, dass die Registrierung
nicht aufgefrischt wird.
Sniffern der SIP-Kommunikation auf dem WAN-Interface zeigt, dass LANCOM bei VCM SIP-
Leitungen je nach Provider unterschiedliche TTLs (Expire) in den "SIP Req REGISTER" verwendet:
bei sipgate.de 60 s, bei dus.net 300 s, bei arcor.de 1800 s.
Test:
Manuelles Setzen von >/setup/voice/general/register-time von 120 s auf 60 s und Neuregistrierung aller Provider-Leitungen. Wieder Sniffern am WAN. Ergebnis: Die REGISTER TTLs sind wieder wie vorher gesetzt. Sie werden wohl so verwendet, wie es das entfernte Ende wünscht, oder die Einstellung funktioniert nicht, wenn die Gegenseite einen Wert vorgibt.
Testverbindung via arcor.de: bricht wieder nach exakt 120 s ab.
Arcor schickt SIP Req OPTIONS an den Router, die vom Router nicht beantwortet werden und
auch nicht an den UA im LAN weitergeleitet werden!
[quote]http://www.voip-info.org/wiki/view/SIP+method+options
The SIP method OPTIONS allows a UA to query another UA or a proxy server as to its capabilities. This allows a client to discover information about the supported methods, content types, extensions, codecs, etc. without "ringing" the other party.
For example, before a client inserts a Require header field into an INVITE listing an option that it is not certain the destination UAS supports, the client can query the destination UAS with an OPTIONS to see if this option is returned in a Supported header field.
All UAs MUST support the OPTIONS method.
[/quote]
Das scheint die richtige Spur, denn http://www.ip-phone-forum.de/showthread.php?t=130016
(#12) berichtet von abgelehnten OPTIONS-Requests, die von Arcor sofort mit BYE quittiert werden.
Seit September 2007 plage ich mich mit diesem Problem. 2 Versuche über den Support sind (trotz Bekundung guten Willens) ohne Ergebnis verlaufen. Kennt jemand aus dieser (erweiterten) Runde eine stabile Lösung?
Gruß,
rougu
Verbindungsabbruch nach 120 s bei Arcor-VoIP, SIP OPTIONS?
Moderator: Lancom-Systems Moderatoren
Hi Rougu,
das Problem hier ist, das der LC auf OPTION-Pakete auf dem WAN-Interface nicht antwortet, bzw. mit "481 Call/Transaction Does Not Exist" antwortet. Das Ganze ist Schlicht und Einfach noch nicht implementiert.
Du schreibst, du hast das Ganze auf dem WAN mitgesnifft, sowohl den erfolgreichen Fall mit dem SoftClient von Arcor als auch den scheiternden Fall mit dem LANCOM.
Wenn wir das Einbauen wollen, wäre es gut, wenn du mir die Traces von WAN per PM zukommen lassen kannst. Vor allem den des Erfolgfalls.
Gruß
Anton
das Problem hier ist, das der LC auf OPTION-Pakete auf dem WAN-Interface nicht antwortet, bzw. mit "481 Call/Transaction Does Not Exist" antwortet. Das Ganze ist Schlicht und Einfach noch nicht implementiert.
Du schreibst, du hast das Ganze auf dem WAN mitgesnifft, sowohl den erfolgreichen Fall mit dem SoftClient von Arcor als auch den scheiternden Fall mit dem LANCOM.
Wenn wir das Einbauen wollen, wäre es gut, wenn du mir die Traces von WAN per PM zukommen lassen kannst. Vor allem den des Erfolgfalls.
Gruß
Anton
Es könnte schlimmer kommen ....
... Ach ja, 'nen Router hab' ich auch ...
... Ach ja, 'nen Router hab' ich auch ...
Hi Rougu,
wenn das zur nächsten Freigabe noch was werden soll, bräuchten wir die Traces relativ bald. Am wichtigsten wäre der auf der WAN-Seite, um die Kommunikation ungefiltert genießen zu können.
Eine andere Sache ist mir auch noch eingefallen. Da du bestimmt nicht der Einzige hier bist, der ARCOR nutzt, könnte es doch sein, das die Ursache an einer ganz anderen Stelle deiner Konfig zu suchen ist. Manche Provider pollen die Gegenstelle in regelmäßigen Abständen durch ein ganz einfaches ICMP-Paket. Hast du das Ping-Blocking aktiviert, antwortet dein Router nicht auf das Polling und ARCOR schmeißt die Registrierung weg.
Überprüfe doch bitte, ob du unter /Setup/IP-Router/Firewall das Ping-Blocking aktiviert hast.
Gruß
Anton
wenn das zur nächsten Freigabe noch was werden soll, bräuchten wir die Traces relativ bald. Am wichtigsten wäre der auf der WAN-Seite, um die Kommunikation ungefiltert genießen zu können.
Eine andere Sache ist mir auch noch eingefallen. Da du bestimmt nicht der Einzige hier bist, der ARCOR nutzt, könnte es doch sein, das die Ursache an einer ganz anderen Stelle deiner Konfig zu suchen ist. Manche Provider pollen die Gegenstelle in regelmäßigen Abständen durch ein ganz einfaches ICMP-Paket. Hast du das Ping-Blocking aktiviert, antwortet dein Router nicht auf das Polling und ARCOR schmeißt die Registrierung weg.
Überprüfe doch bitte, ob du unter /Setup/IP-Router/Firewall das Ping-Blocking aktiviert hast.
Gruß
Anton
Es könnte schlimmer kommen ....
... Ach ja, 'nen Router hab' ich auch ...
... Ach ja, 'nen Router hab' ich auch ...
Hi Anton,
die Traces sind fertig. Es hat etwas gedauert, weil ich ein Projekt abschließen musste und für die Traces mein Setup umbauen musste (ext. ADSL-Modem und Hub aufbauen, etc.).
Das ICMP-Polling ist nicht die Ursache, sondern SIP OPTIONS. Die Traces gehen Dir per PM zu; sie sind
eindeutig. Du findest zwei Traces, einmal mit LCOS 7.30, das die Provider-Line "arcor" bedient und als zweites ein Mitschnitt, wenn ein Snom 370 die Leitung direkt bedient. Das Snom verhält sich korrekt und beantwortet SIP OPTIONS, Arcor trennt nicht.
Zum Filtern in Wireshark bringt "udp.port == 5060 && ip.addr == 212.144.24.233" die schnellste Übersicht.
Es wäre denkbar, dass Arcor regional unterschiedliche Hardware einsetzt, so dass nicht jeder das Problem bekommt, das ich habe.
Gruß,
Rougu
die Traces sind fertig. Es hat etwas gedauert, weil ich ein Projekt abschließen musste und für die Traces mein Setup umbauen musste (ext. ADSL-Modem und Hub aufbauen, etc.).
Das ICMP-Polling ist nicht die Ursache, sondern SIP OPTIONS. Die Traces gehen Dir per PM zu; sie sind
eindeutig. Du findest zwei Traces, einmal mit LCOS 7.30, das die Provider-Line "arcor" bedient und als zweites ein Mitschnitt, wenn ein Snom 370 die Leitung direkt bedient. Das Snom verhält sich korrekt und beantwortet SIP OPTIONS, Arcor trennt nicht.
Zum Filtern in Wireshark bringt "udp.port == 5060 && ip.addr == 212.144.24.233" die schnellste Übersicht.
Es wäre denkbar, dass Arcor regional unterschiedliche Hardware einsetzt, so dass nicht jeder das Problem bekommt, das ich habe.
Gruß,
Rougu
Hi Rougu,
zwischenzeitlich haben wir hier schon ein paar Tests mit unterschiedlichen Accounts von ARCOR gemacht. Wir können hier kein Fehler im LCOS feststellen.
Diese waren auch Regional unterschiedlich ans Netz.
Ich denke, du solltes mal eine Anfrage bei ARCOR starten, um das Problem einzugrenzen. Das der LANCOM hier auf die OPTION-Pakete nicht antwortet, kann auf jeden Fall nicht das Problem sein.
Was mir auffällt in deinem Dump ist der Unterschied im FROM-Header der Pakete, die von ARCOR kommen. Dietmar ist hier mit einem / unterteilt. Prüfe mal, wo das herkommt. Bei dem Dump deines Softclient steht da Anonymous. Der / im Paket kann hier den Fehler durchaus verursachen.
From: "Diet/mar
Gruß
Oliver[/code]
zwischenzeitlich haben wir hier schon ein paar Tests mit unterschiedlichen Accounts von ARCOR gemacht. Wir können hier kein Fehler im LCOS feststellen.
Diese waren auch Regional unterschiedlich ans Netz.
Ich denke, du solltes mal eine Anfrage bei ARCOR starten, um das Problem einzugrenzen. Das der LANCOM hier auf die OPTION-Pakete nicht antwortet, kann auf jeden Fall nicht das Problem sein.
Was mir auffällt in deinem Dump ist der Unterschied im FROM-Header der Pakete, die von ARCOR kommen. Dietmar ist hier mit einem / unterteilt. Prüfe mal, wo das herkommt. Bei dem Dump deines Softclient steht da Anonymous. Der / im Paket kann hier den Fehler durchaus verursachen.
From: "Diet/mar
Gruß
Oliver[/code]
Es könnte schlimmer kommen ....
... Ach ja, 'nen Router hab' ich auch ...
... Ach ja, 'nen Router hab' ich auch ...
Hi Anton,
Der Hinweis mit dem "/" ist interessant, aber nicht die Ursache des Problems. Die Einstellung war im Nutzerprofil des Snom-Endgeräts vorhanden. Ich habe mit einem Anzeigenamen nur aus Buchstaben getestet: keine Änderung.
Kannst du mir erklären, warum Du die fehlende Antwort auf "SIP OPTIONS" Requests als Ursache ausschließen kannst? Habt Ihr bei Euren Tests solche Requests von der Arcor-Hardware erhalten?
Soweit zu LCOS 7.30
Mit LCOS 7.52:
NB: Nach dem FW-Update war die Konfiguration weg (Auslieferungszustand).
Der unter 7.30 getracete Testanruf mit einem Snom-Client im LAN, der am LC registriert ist, ist zunächst einmal nicht mehr möglich. Vielleicht muss auch ich erst vom Support die 7.54 anfordern, damit interne SIP-Clients wieder mit VLANs funktionieren.
Ein analoger Client am LC mit 7.52 kann mit Arcor-Providerline ohne Abbruch telefonieren.
Ich werde also mit 7.5x weiter testen und vor allem mal eine Abhängigkeit vom Client berücksichtigen (Tests mit Phoner, Snom, und a/b-Clients).
Gruß,
Rougu
PS: Bitte keine Quotes mit persönlichen Details in den Antworten! Ich stelle meine Traces unter dem Vorbehalt der Vertraulichkeit zur Verfügung.
Der Hinweis mit dem "/" ist interessant, aber nicht die Ursache des Problems. Die Einstellung war im Nutzerprofil des Snom-Endgeräts vorhanden. Ich habe mit einem Anzeigenamen nur aus Buchstaben getestet: keine Änderung.
Kannst du mir erklären, warum Du die fehlende Antwort auf "SIP OPTIONS" Requests als Ursache ausschließen kannst? Habt Ihr bei Euren Tests solche Requests von der Arcor-Hardware erhalten?
Soweit zu LCOS 7.30
Mit LCOS 7.52:
NB: Nach dem FW-Update war die Konfiguration weg (Auslieferungszustand).
Der unter 7.30 getracete Testanruf mit einem Snom-Client im LAN, der am LC registriert ist, ist zunächst einmal nicht mehr möglich. Vielleicht muss auch ich erst vom Support die 7.54 anfordern, damit interne SIP-Clients wieder mit VLANs funktionieren.
Ein analoger Client am LC mit 7.52 kann mit Arcor-Providerline ohne Abbruch telefonieren.
Ich werde also mit 7.5x weiter testen und vor allem mal eine Abhängigkeit vom Client berücksichtigen (Tests mit Phoner, Snom, und a/b-Clients).
Gruß,
Rougu
PS: Bitte keine Quotes mit persönlichen Details in den Antworten! Ich stelle meine Traces unter dem Vorbehalt der Vertraulichkeit zur Verfügung.
Hi Anton,
mit der BETA von LCOS 7.5x läuft nun der SNOM-Client wieder im VLAN-Intranet.
Und, ich glaub es noch kaum, die Abbrüche nach 120 s gehören anscheinend der Vergangenheit an.
- Client Snom 370 mit fw 7.1.30 läuft
- a/b-Client läuft
Die alphanumerische Zusammensetzung des Anzeigenamens ist übrigens ohne Einfluss auf diesen Erfolg, d. h. ein "/" stört nicht.
Wenn ich ein bisschen mehr Zeit habe, werde das nochmal genauer tracen.Danke für die Mithilfe und die Tests. Ich würde ja gerne verstehen, warum es jetzt läuft...
Aber einstweilen bin ich zufrieden und kann diesen Fall schließen.
Gruß,
Rougu
mit der BETA von LCOS 7.5x läuft nun der SNOM-Client wieder im VLAN-Intranet.
Und, ich glaub es noch kaum, die Abbrüche nach 120 s gehören anscheinend der Vergangenheit an.
- Client Snom 370 mit fw 7.1.30 läuft
- a/b-Client läuft
Die alphanumerische Zusammensetzung des Anzeigenamens ist übrigens ohne Einfluss auf diesen Erfolg, d. h. ein "/" stört nicht.
Wenn ich ein bisschen mehr Zeit habe, werde das nochmal genauer tracen.Danke für die Mithilfe und die Tests. Ich würde ja gerne verstehen, warum es jetzt läuft...
Aber einstweilen bin ich zufrieden und kann diesen Fall schließen.
Gruß,
Rougu