Arcor VOIP abbruch nach ca 2 min
- Ersteller Woodruff
- Erstellt am
Sorry 
ich kam auch noch nicht dazu. Es kann sein das ich es heute abend mach. Bitte nicht sauer sein wenn es dann doch nichts wird. Aber ich werd es noch machen. Versprochen
ich kam auch noch nicht dazu. Es kann sein das ich es heute abend mach. Bitte nicht sauer sein wenn es dann doch nichts wird. Aber ich werd es noch machen. Versprochen[Edit Novize: 20.10.2009 - Link gelöscht, um Unfug mit den darin enthaltenen Passwörtern zu verhindern]
Bitteschön der Trace der neuen .76 Firmware. Nach ca 2:20 gibts Abbruch.
Bitteschön der Trace der neuen .76 Firmware. Nach ca 2:20 gibts Abbruch.
Zuletzt bearbeitet:
Nein, auch mit meiner alten Fritz!Box Fon habe ich nun seit ca. zwei Monaten den Arcor-Schlamassel.
:-(
Gruß
a_schiller
Zuletzt bearbeitet:
Ich habe heute auch die aktuelle Firmware Version getestet.
Leider mit dem gleichen Ergebnis, jetzt bricht die Verbindung immer bei 1:58min anstatt 1:59min ab...
Leider mit dem gleichen Ergebnis, jetzt bricht die Verbindung immer bei 1:58min anstatt 1:59min ab...
Hmm, die Box antwortet auf die Options-Pakete, Arcor sendet trotzdem ein BYE. - Jetzt wäre ein Vergleich mit einer "funktionierenden" Box interessant...
**berni**
ich kann den trace der gleichen box samt .59 Firmware anbieten. damit klappen ja Arcor Voip Gespräche...einverstanden ?
Mir fällt auf dass der Server die Cseq immer mit der gleichen Anforderungsnummer sendet. Im Log von **Bernie** mit Twinkle hat das SBC von Arcor die Cseq immer hochgezählt. Also der Server sendet immer die gleiche Optionsanfrage weil er vermutlich die Antwort die die FritzBox sendet, nicht als Antwort auf seine Anfrage interpretiert. Nach dem 4. mal ohne Antwort legt er auf, da er denkt die Gegenstelle wäre nicht mehr erreichbar (steht sogar direkt in Wireshark, nach dem 1. OPTIONS Paket hat jedes weitere das Flag Resent Packet: True).
Wo hier genau der Fehler liegt seh ich jetzt nicht, für mich mit ungeschultem Auge sieht die Antwort korrekt aus, aber irgendwas schmeckt dem SBC nicht, sonst würde er sie nicht ignorieren. Ein Fragmentierungsproblem kanns nicht sein, der Frame ist nur knapp 500 Bytes groß. Die IPs stimmen auch, also kanns auch nix mit den DNSSRV Records zu tun haben, der Inhalt sieht für mich auch gut aus. Eventuell müsste man echt nochmal ein 1:1 Vergleich zwischen den Firmwares haben um den Fehler zu finden. Hat aber schonmal auf jedenfall was mit der keep-alive über die OPTION zu tun.
Wo hier genau der Fehler liegt seh ich jetzt nicht, für mich mit ungeschultem Auge sieht die Antwort korrekt aus, aber irgendwas schmeckt dem SBC nicht, sonst würde er sie nicht ignorieren. Ein Fragmentierungsproblem kanns nicht sein, der Frame ist nur knapp 500 Bytes groß. Die IPs stimmen auch, also kanns auch nix mit den DNSSRV Records zu tun haben, der Inhalt sieht für mich auch gut aus. Eventuell müsste man echt nochmal ein 1:1 Vergleich zwischen den Firmwares haben um den Fehler zu finden. Hat aber schonmal auf jedenfall was mit der keep-alive über die OPTION zu tun.
Zuletzt bearbeitet:
Um 100%ig sagen zu können was dem Cisco nicht an der Antwort von der FritzBox gefällt ja. Beheben können wirs aber eh nicht, das muss AVM ja machen. Frage ist ob es nicht einfach reicht den Trace an AVM zu schicken mit dem Hinweis dass der Cisco von Arcor das Options Paket immer neu sendet, weil die Antwort der FritzBox wohl nicht korrekt ist. Dann können die den Fehler nämlich gerade mal selbst suchen den se da eingebaut haben
Nach ganz scharfem hinsehen ist mir aufgefallen dass Twinkle eine andere Reihenfolge der Tags hat. Dort ist es Via, To, From, wie auch beim Cisco SBC von Arcor. Bei der FritzBox in der Antwort ist es Via, From, To - ich kenn mich mit den RFCs jetzt zwar nicht aus, aber das sollte eigentlich kein Problem sein. Sonst ist mir kein Unterschied aufgefallen, bis auf die fehlende SDP Payload bei Twinkle zur FritzBox.
Nach ganz scharfem hinsehen ist mir aufgefallen dass Twinkle eine andere Reihenfolge der Tags hat. Dort ist es Via, To, From, wie auch beim Cisco SBC von Arcor. Bei der FritzBox in der Antwort ist es Via, From, To - ich kenn mich mit den RFCs jetzt zwar nicht aus, aber das sollte eigentlich kein Problem sein. Sonst ist mir kein Unterschied aufgefallen, bis auf die fehlende SDP Payload bei Twinkle zur FritzBox.
Keine Ahnung ob das bekannt ist. Hab ich gerade im Lancom-Forum via Google gefunden:
http://www.lancom-forum.de/htopic,6928,reason++850+cause++text.html
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.
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
Hi Anton, ich werd mal schaun, wie ich die Sache neu tracen kann, denn die alten Logs sind längst nach /dev/null verschoben. Auf jeden Fall FREUE ich mich über die anklingende Bereitschaft zur Implementierung. Ich melde mich. Gruß, rougu
Hi Rougu, merci, werde die Traces mit Freuden erwarten ;-) Gruß Anton
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
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
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: "[b:12903f76c7]Diet/mar[/b:12903f76c7] Gruß Oliver[/code]
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.
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
http://www.lancom-forum.de/htopic,6928,reason++850+cause++text.html
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.
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!
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
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
Hi Anton, ich werd mal schaun, wie ich die Sache neu tracen kann, denn die alten Logs sind längst nach /dev/null verschoben. Auf jeden Fall FREUE ich mich über die anklingende Bereitschaft zur Implementierung. Ich melde mich. Gruß, rougu
Hi Rougu, merci, werde die Traces mit Freuden erwarten ;-) Gruß Anton
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
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
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: "[b:12903f76c7]Diet/mar[/b:12903f76c7] Gruß Oliver[/code]
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.
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
Zuletzt bearbeitet:
Wenn ichs richtig verstanden hab gabs mit LANCOM Routern das gleiche Problem, welches dann mit einem Firmware Update behoben wurde. Die Aussage dass es nicht an den OPTION Paketen bei LANCOM lag halt ich für falsch. Habs bei mir am Asterisk damals darauf zurückführen können, bei der FritzBox siehts dieses mal ebenfalls so aus, und der User hats beim LANCOM ja auch auf die OPTION Pakete zurückführen können. Warum der Moderator/LANCOM Support was anderes behauptet weiß ich jetzt spontan nicht. Aber wie gesagt, mit wireshark das Trace aus der FritzBox analysiert sieht man bei der 2. 3. und 4. OPTION Anfrage ja deutlich, dass es sich um retransmitted Packets handelt, was auf irgendein Problem mit den Antworten schließen lässt. Ob das jetzt an Arcor (genauer dem Cisco SBC) oder AVM liegt, weiß ich nicht, da die Antwort für mich korrekt ausschaut, allerdings muss AVM was verändert haben, wenn der Cisco SBC die Antworten der Box mal akzeptiert hat. Eventuell hats was mit dem HD Audio zu tun, das wird bei der Antwort auf die OPTION im SDP Payload erwähnt und daran hat AVM soweit ich weiß auch geschraubt. Aber das wird AVM selbst am besten wissen, wir stochern hier ja eigentlich nur im Dunkeln.
Interessant ist, dass alle Hard- u. Software-Clients, die ich mir jetzt diesbezüglich angeschaut habe, das SIP-Protokoll geringfügig unterschiedlich implementieren. Für Interessierte hab' ich mal einen "Mitschnitt" der "funktionierenden" Arcor Sprachsoftware 2.0 beigefügt:
Um die Ursprungsfrage nochmals aufzugreifen: Ich tendiere nach wie vor dazu, dass die Verbindungsabbrüche in der "fehlerhaften" Implementierung der Clients begründet liegt. Ich unterstelle hierbei einfach mal, dass Arcors OPTIONS-Abfrage RFC-konform ist. Hierzu sollte sich ggf. mal jemand äußern, der Ahnung von der Materie hat, oder an der Quelle sitzt...
**berni**
Code:
REGISTER sip:arcor.de SIP/2.0
Via: SIP/2.0/UDP 192.168.1.13:5065;rport;branch=z9hG4b1132793
From: <sip:[email protected]>;tag=4136965176
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 9 REGISTER
Contact: <sip:[email protected]:5065>
Max-Forwards: 70
User-Agent: wengo/v1/wengophoneng/wengo/rev3a20f8a46b39/trunk/
Expires: 60
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.13:5065;received=84.60.157.89;branch=z9hG4b1132793;rport=5065
From: <sip:[email protected]>;tag=4136965176
To: <sip:[email protected]>;tag=aprqgc6hpd1-tc2lm810000i0
Call-ID: [email protected]
CSeq: 9 REGISTER
Contact: <sip:[email protected]:5065>;expires=60
INVITE sip:[email protected]:5065 SIP/2.0
Via: SIP/2.0/UDP 88.79.153.73:5060;branch=z9hG4bK0050ehdgcgv7o1.1
To: <sip:[email protected];user=phone>
From: "0211305390" <sip:[email protected];user=phone>;tag=SD9cq-df922546
Call-ID: SD9cq-dbf4dcfbd14497624e185b4c36f-iikchk2
CSeq: 1 INVITE
Max-Forwards: 69
Contact: <sip:[email protected]:5060;transport=udp>
Allow: INVITE, ACK, PRACK, CANCEL, BYE, OPTIONS, MESSAGE, NOTIFY, UPDATE, REGISTER, INFO, REFER, SUBSCRIBE
Accept: application/sdp, application/isup, application/xml, application/dtmf-relay
Content-Type: application/sdp
Content-Length: 201
v=0
o=- 0 75752575 IN IP4 88.79.153.73
s=IMSS
c=IN IP4 88.79.153.73
t=0 0
m=audio 11896 RTP/AVP 8 101 18 106
a=rtpmap:101 G726-32/8000
a=rtpmap:106 telephone-event/8000
a=sendrecv
a=ptime:20
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 88.79.153.73:5060;branch=z9hG4bK0050ehdgcgv7o1.1
From: "0211305390" <sip:[email protected];user=phone>;tag=SD9cq-df922546
To: <sip:[email protected];user=phone>
Call-ID: SD9cq-dbf4dcfbd14497624e185b4c36f-iikchk2
CSeq: 1 INVITE
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, MESSAGE, INFO, REFER
Content-Length: 0
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 88.79.153.73:5060;branch=z9hG4bK0050ehdgcgv7o1.1
From: "0211305390" <sip:[email protected];user=phone>;tag=SD9cq-df922546
To: <sip:[email protected];user=phone>;tag=1279634140
Call-ID: SD9cq-dbf4dcfbd14497624e185b4c36f-iikchk2
CSeq: 1 INVITE
Contact: <sip:[email protected]:5065>
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, MESSAGE, INFO, REFER
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP 88.79.153.73:5060;branch=z9hG4bK0050ehdgcgv7o1.1
From: "0211305390" <sip:[email protected];user=phone>;tag=SD9cq-df922546
To: <sip:[email protected];user=phone>;tag=1279634140
Call-ID: SD9cq-dbf4dcfbd14497624e185b4c36f-iikchk2
CSeq: 1 INVITE
Contact: <sip:[email protected]:5065>
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, MESSAGE, INFO, REFER
Content-Type: application/sdp
Content-Length: 184
v=0
o=userX 20000001 20000001 IN IP4 192.168.1.13
s=IMSS
c=IN IP4 192.168.1.13
t=0 0
m=audio 10600 RTP/AVP 8 112
a=ptime:20
a=rtpmap:8 PCMA/8000/1
a=rtpmap:112 G726-32/8000/1
ACK sip:[email protected]:5065 SIP/2.0
Via: SIP/2.0/UDP 88.79.153.73:5060;branch=z9hG4bK3dtkr3209olhogsjs1g1.1
To: <sip:[email protected];user=phone>;tag=1279634140
From: "0211305390" <sip:[email protected];user=phone>;tag=SD9cq-df922546
Call-ID: SD9cq-dbf4dcfbd14497624e185b4c36f-iikchk2
CSeq: 1 ACK
Max-Forwards: 69
Content-Length: 0
OPTIONS sip:[email protected]:5065 SIP/2.0
Via: SIP/2.0/UDP 88.79.153.73:5060;branch=z9hG4bK3dtkr3209olhogsjs1g1ch0000010.1
To: <sip:[email protected];user=phone>;tag=1279634140
From: "0211305390" <sip:[email protected];user=phone>;tag=SD9cq-df922546
Call-ID: SD9cq-dbf4dcfbd14497624e185b4c36f-iikchk2
CSeq: 2 OPTIONS
Max-Forwards: 69
Content-Length: 0
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 88.79.153.73:5060;branch=z9hG4bK3dtkr3209olhogsjs1g1ch0000010.1
From: "0211305390" <sip:[email protected];user=phone>;tag=SD9cq-df922546
To: <sip:[email protected];user=phone>;tag=1279634140
Call-ID: SD9cq-dbf4dcfbd14497624e185b4c36f-iikchk2
CSeq: 2 OPTIONS
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, MESSAGE, INFO, REFER
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP 88.79.153.73:5060;branch=z9hG4bK3dtkr3209olhogsjs1g1ch0000010.1
From: "0211305390" <sip:[email protected];user=phone>;tag=SD9cq-df922546
To: <sip:[email protected];user=phone>;tag=1279634140
Call-ID: SD9cq-dbf4dcfbd14497624e185b4c36f-iikchk2
CSeq: 2 OPTIONS
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, MESSAGE, INFO, REFER
Content-Length: 0
OPTIONS sip:[email protected]:5065 SIP/2.0
Via: SIP/2.0/UDP 88.79.153.73:5060;branch=z9hG4bK3dtkr3209olhogsjs1g1ch0000g10.1
To: <sip:[email protected];user=phone>;tag=1279634140
From: "0211305390" <sip:[email protected];user=phone>;tag=SD9cq-df922546
Call-ID: SD9cq-dbf4dcfbd14497624e185b4c36f-iikchk2
CSeq: 3 OPTIONS
Max-Forwards: 69
Content-Length: 0
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 88.79.153.73:5060;branch=z9hG4bK3dtkr3209olhogsjs1g1ch0000g10.1
From: "0211305390" <sip:[email protected];user=phone>;tag=SD9cq-df922546
To: <sip:[email protected];user=phone>;tag=1279634140
Call-ID: SD9cq-dbf4dcfbd14497624e185b4c36f-iikchk2
CSeq: 3 OPTIONS
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, MESSAGE, INFO, REFER
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP 88.79.153.73:5060;branch=z9hG4bK3dtkr3209olhogsjs1g1ch0000g10.1
From: "0211305390" <sip:[email protected];user=phone>;tag=SD9cq-df922546
To: <sip:[email protected];user=phone>;tag=1279634140
Call-ID: SD9cq-dbf4dcfbd14497624e185b4c36f-iikchk2
CSeq: 3 OPTIONS
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, MESSAGE, INFO, REFER
Content-Length: 0
OPTIONS sip:[email protected]:5065 SIP/2.0
Via: SIP/2.0/UDP 88.79.153.73:5060;branch=z9hG4bK3dtkr3209olhogsjs1g1ch0000020.1
To: <sip:[email protected];user=phone>;tag=1279634140
From: "0211305390" <sip:[email protected];user=phone>;tag=SD9cq-df922546
Call-ID: SD9cq-dbf4dcfbd14497624e185b4c36f-iikchk2
CSeq: 4 OPTIONS
Max-Forwards: 69
Content-Length: 0
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 88.79.153.73:5060;branch=z9hG4bK3dtkr3209olhogsjs1g1ch0000020.1
From: "0211305390" <sip:[email protected];user=phone>;tag=SD9cq-df922546
To: <sip:[email protected];user=phone>;tag=1279634140
Call-ID: SD9cq-dbf4dcfbd14497624e185b4c36f-iikchk2
CSeq: 4 OPTIONS
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, MESSAGE, INFO, REFER
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP 88.79.153.73:5060;branch=z9hG4bK3dtkr3209olhogsjs1g1ch0000020.1
From: "0211305390" <sip:[email protected];user=phone>;tag=SD9cq-df922546
To: <sip:[email protected];user=phone>;tag=1279634140
Call-ID: SD9cq-dbf4dcfbd14497624e185b4c36f-iikchk2
CSeq: 4 OPTIONS
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, MESSAGE, INFO, REFER
Content-Length: 0
BYE sip:[email protected]:5065 SIP/2.0
Via: SIP/2.0/UDP 88.79.153.73:5060;branch=z9hG4bK3dtkr3209olhogsjs1g1cd0000g20.1
To: <sip:[email protected];user=phone>;tag=1279634140
From: "0211305390" <sip:[email protected];user=phone>;tag=SD9cq-df922546
Call-ID: SD9cq-dbf4dcfbd14497624e185b4c36f-iikchk2
CSeq: 5 BYE
Max-Forwards: 69
Reason: Q.850 ;cause=16 ;text="0"
Content-Length: 0
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 88.79.153.73:5060;branch=z9hG4bK3dtkr3209olhogsjs1g1cd0000g20.1
From: "0211305390" <sip:[email protected];user=phone>;tag=SD9cq-df922546
To: <sip:[email protected];user=phone>;tag=1279634140
Call-ID: SD9cq-dbf4dcfbd14497624e185b4c36f-iikchk2
CSeq: 5 BYE
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, MESSAGE, INFO, REFER
Content-Length: 0
SIP/2.0 200 OK
Via: SIP/2.0/UDP 88.79.153.73:5060;branch=z9hG4bK3dtkr3209olhogsjs1g1cd0000g20.1
From: "0211305390" <sip:[email protected];user=phone>;tag=SD9cq-df922546
To: <sip:[email protected];user=phone>;tag=1279634140
Call-ID: SD9cq-dbf4dcfbd14497624e185b4c36f-iikchk2
CSeq: 5 BYE
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, MESSAGE, INFO, REFER
Content-Length: 0Um die Ursprungsfrage nochmals aufzugreifen: Ich tendiere nach wie vor dazu, dass die Verbindungsabbrüche in der "fehlerhaften" Implementierung der Clients begründet liegt. Ich unterstelle hierbei einfach mal, dass Arcors OPTIONS-Abfrage RFC-konform ist. Hierzu sollte sich ggf. mal jemand äußern, der Ahnung von der Materie hat, oder an der Quelle sitzt...
**berni**
Auch Content-Length: 0, könnte echt was mit der HD Telefonie zu tun haben, da die neue FritzFirmware im Content Part noch ihre ganzen HD Fähigkeiten und Codecs übermittelt. Das würde dann aber eher auf nen Fehler bei Arcor schließen lassen wenn der Server von zusätzlichen Fähigkeiten verwirrt wird. Meiner Meinung nach müsste er das was er nicht kann einfach ignorieren und dann nicht komplett den Zugang verweigern.
gleiches Problem
Hallo zusammen,
ich plage mich leider mit dem gleichen Problem rum. Habe auch eine Störungsmeldung an Vodafone geschickt und die sind im Moment an der Behebung dran. Erste genannte Ursache sei anscheinend meine hohe Dämpfung des DSLs. Leider funktionieren damit alle anderen Voip-Anbieter bis auf Arcor/Vodafone ;( Nach einer Leitungsprüfung, die hätte am 06.07 geschehen sollen, hat sich keiner mehr gemeldet.
Irgendwie habe ich im Moment nicht so das Gefühl, dass das Problem in absehbarer Zeit gelöst wird...
Hallo zusammen,
ich plage mich leider mit dem gleichen Problem rum. Habe auch eine Störungsmeldung an Vodafone geschickt und die sind im Moment an der Behebung dran. Erste genannte Ursache sei anscheinend meine hohe Dämpfung des DSLs. Leider funktionieren damit alle anderen Voip-Anbieter bis auf Arcor/Vodafone ;( Nach einer Leitungsprüfung, die hätte am 06.07 geschehen sollen, hat sich keiner mehr gemeldet.
Irgendwie habe ich im Moment nicht so das Gefühl, dass das Problem in absehbarer Zeit gelöst wird...
Zuletzt bearbeitet:
Neueste Beiträge
-
Suche Telefonanlage für kleine Kanzlei
- Letzte: crackerwilli
-
[Sammlung] AVM-Gateway-kompatible Zigbee-Geräte
- Letzte: Schmutzfee
-
AVM Geofencing - Smart Home: Fragen
- Letzte: pens
-
Hicom 3500
- Letzte: TelMike
-
[Problem] 5690 wlan modul
- Letzte: KunterBunter
-
Be.IP hinter Fritzbox Fiber
- Letzte: KunterBunter
