Fritzbox SIP Fehler 481

[McMicha]

Hallo,
seit einiger Zeit funktionert die Telefonie meiner Fritzbox nicht mehr. Diese habe ich als Client laufen und ist nur für das Telefon da. die Verbindung stellt das Ubiquiti Gateway her, was auch problemlos jahrelang funktioniert hat. Nachdem unser I-Net ausgefallen war, ließen sich die Telefonummern nicht mehr registrieren. Nun habe ich ein TCPdump der WAN und LAN Schnittstellen des USG's gemacht, da die Fritzbox keine detailierten infos herausgab. Hier taucht der SIP Fehler 481 von der Telekom -> Fritzbox: 481 Fetch Binding not supported.
Überbrücke ich das Gateway und lasse das Modem die Verbindung herstellen klappt die Registrierung, genauso wie wenn die Fritzbox die Verbindung herstellt.

Hat hier jemand eine Idee was ich noch versuchen kann?

Viele Grüße
Micha

 

[PeterPawn]

da die Fritzbox keine detailierten infos herausgab.

Das sollte sie in den Support-Daten aber tun - dort ist auch der komplette SIP-Traffic zu finden, afaik.

Man kann/sollte hier aber noch prüfen, ob das ALG für das SIP-Protokoll im USG deaktiviert ist (dazu war bisher nichts zu lesen in #1), denn 481 deutet auf eine falsche ID in der (gesendeten) Message hin und das kann - auch bei den beschriebenen "Umbauten", die es wieder funktionieren lassen - eigentlich nur daran liegen, daß da jemand im Pfad den Inhalt von SIP-Paketen ändert.

 

[sonyKatze]

Fetch Binding not supported

Ab Werk will die FRITZ!Box vom SIP-Anbieter bestehende SIP-Registrierungen auflisten, um Doppel-Registrierungen zu vermeiden. Das ist ein optionales Verfahren und daher unterstützt nicht jeder SIP-Anbieter dies. Ich müsste jetzt nachschauen, ob die Telekom Deutschland es unterstützt. Anders formuliert: Es ist wenn überhaupt ein Symptom, nicht die Ursache.

da die Fritzbox keine detailierten infos herausgab

Du könntest auch auf der FRITZ!Box mitschneiden … Aber direkt auf dem UniFi Security Gateway (USG) das LAN mitzuschneiden ist gleichwertig. Außerdem bist Du genau richtig vorgegangen und hast auch das WAN mitgeschnitten.

eine Idee

UniFi bietet Connection-Tracking … Solche Software-Module überwachen oft nicht nur die Verbindung, sondern greifen in den SIP/SDP-Datenstrom ein. Dabei könnten dann Dinge wie das SIP-Fetch-Bindung kaputt gehen. Das nennt man dann ALG. Das siehst Du, indem Du Dir das ursprüngliche SIP-Paket – ein SIP-REGISTER ohne Header Contact – sowohl auf LAN und WAN anschaust. Ist es 100% gleich? Dann hat – jedenfalls in das Paket – kein ALG eingegriffen.

Als Helfender müsste man eine USG haben und Telekom Deutschland haben, um genau zu schauen, ob hier was kaputt gemacht wird. Ich empfehle solche Module abzuschalten und auch kein Port-Freigaben einzurichten, denn die FRITZ!Box hat Mechanismen an Bord das alles selbstständig (viel besser) zu tun. Aber der Thread in ComputerBase ist erfolgreich und macht es genau anders herum.

seit einiger Zeit

Nachdem unser I-Net ausgefallen war

Sind das zwei verschiedene Zeitpunkte oder derselbe? Problem ist, dass die Telekom Deutschland aktuell ein neues, weiteres IMS ausrollt. Mal bekommt man das alte. Mal ist man dauerhaft auf dem neuen. Wie helfen Dir gerne so gut es geht, Deine Ursache zu finden. Aber Du merkst, es sind viele Neben-Bedingungen (Telekom Deutschland, welches IMS, UniFi USG, …). Daher und bevor wir uns komplett verlaufen, ganz andere Frage: Muss es ein USG sein, muss UniFi unbedingt auch Router spielen, ginge nicht auch eine Cloud Key Gen 2 Plus (UCK-G2-PLUS)?

 

[McMicha]

[Edit Novize: Überflüssiges Fullquote gelöscht - siehe Forumsregeln]

Hallo PeterPawn,
das es Support-Daten gab wusste ich nicht. Nun habe ich mich schlau gemacht und die Datei gezogen - nun bin ich aber genauso schlau wie vorher...
Das ALG hatte ich bereits deaktiviert. Wie (und wer) kann in den Pfaden der Paketinhalt geändert werden?

Ich habe mal die Supportdatei angehangen. Vielleicht wird ja einer von euch daraus schlau....

[Edit Novize: Beiträge zusammengefasst - siehe Forumsregeln]

Ab Werk will die FRITZ!Box vom SIP-Anbieter bestehende SIP-Registrierungen auflisten, um Doppel-Registrierungen zu vermeiden. Das ist ein optionales Verfahren und daher unterstützt nicht jeder SIP-Anbieter dies. Ich müsste jetzt nachschauen, ob die Telekom Deutschland es unterstützt. Anders formuliert: Es ist wenn überhaupt ein Symptom, nicht die Ursache.

Du könntest auch auf der FRITZ!Box mitschneiden … Aber direkt auf dem UniFi Security Gateway (USG) das LAN mitzuschneiden ist gleichwertig. Außerdem bist Du genau richtig vorgegangen und hast auch das WAN mitgeschnitten.

UniFi hat ein SIP-Modul für das Connection-Tracking (Conntrack Modules). Solche Module überwachen oft nicht nur die Verbindung, sondern greifen in den SIP/SDP-Datenstrom ein. Dabei könnten dann Dinge wie das SIP-Fetch-Bindung kaputt gehen. Das nennt man dann ALG. Das siehst Du, indem Du Dir das ursprüngliche SIP-Paket – ein SIP-REGISTER ohne Header Contact – sowohl auf LAN und WAN anschaust. Ist es 100% gleich? Dann hat – jedenfalls in das Paket – kein ALG eingegriffen.

Als Helfender müsste man eine USG haben und Telekom Deutschland haben, um genau zu schauen, ob hier was kaputt gemacht wird. Ich empfehle solche Module abzuschalten und auch kein Port-Freigaben einzurichten, denn die FRITZ!Box hat Mechanismen an Bord das alles selbstständig (viel besser) zu tun. Aber der Thread in ComputerBase ist erfolgreich und macht es genau anders herum.


Sind das zwei verschiedene Zeitpunkte oder derselbe? Problem ist, dass die Telekom Deutschland aktuell ein neues, weiteres IMS ausrollt. Mal bekommt man das alte. Mal ist man dauerhaft auf dem neuen. Wie helfen Dir gerne so gut es geht, Deine Ursache zu finden. Aber Du merkst, es sind viele Neben-Bedingungen (Telekom Deutschland, welches IMS, UniFi USG, …). Daher und bevor wir uns komplett verlaufen, ganz andere Frage: Muss es ein USG sein, muss UniFi unbedingt auch Router spielen, ginge nicht auch eine Cloud Key Gen 2 Plus (UCK-G2-PLUS)?

Hallo SonyKatze,

das mit den Listen der SIP Registrierung war mir neu- man lernt halt nicht aus.
Die SIP-ALG habe ich bereits deaktiviert. Im Lan & Wan sehe ich bei tcpdump keinen SIP Header. Mit welchem Befehl kann ich mir den auf beiden Seiten ansehen? Ich kann dir höchstens den Netzwerkmitschnitt der Fritzbox als PN mal schicken...

Was die Zeitpunkte betrifft - das war wohl etwas unglücklich ausgdrückt von mir - es war ein Zeitpunkt.

Deine letzte Äußerung verstehe ich nicht ganz- der Cloudkey verwaltet doch das ganze nur. Auch ohne ihn müsste theoretisch ein Verbindungsaufbau stattfinden.
Zur Kompettierung: Im Netzwerk befinden sich USG4Pro, UCK-G2+, US16-150W, USW-Lite16-POE,US-8-60W, US8, U6-Pro, U6-LR, UAP-AC-Pro,UAP-AC-M-Pro, UAP-AC-LR und U6-IW

 

[sonyKatze]

der Cloudkey verwaltet doch das ganze nur. Auch ohne ihn müsste theoretisch ein Verbindungsaufbau stattfinden.

Die Frage war: Muss UniFi bei Dir auch unbedingt die Rolle des Internet-Routers spielen?
Wenn nicht, würde anstatt der USG auch ein CloudKey ausreichen. Dann müssten wir die Telefonie gar nicht zum Laufen bekommen, weil dann die FRITZ!Box Dein Internet-Router ist.

Im Lan & Wan sehe ich bei tcpdump keinen SIP Header.

tcpdump erlaubt Dir alles zu sehen. Aber dazu musst Du die Informationen intern weiterleiten. Diese Anleitung ist ganz nett …

 

[McMicha]

Hallo,
ja das USG muss die Rolle des Routers übernehmen, da die Auerswald sich in einem anderen Raum befindet als der Telefonanschluss und man dorthin keine Leitung legen kann oder nur mit hohen baulichen Aufwand.

 

[sonyKatze]

Ich dachte eher daran, die FRITZ!Box als Router zu nehmen. Wenn daran eine Telefon-Anlage angeschlossen werden muss, könntest Du ein LAN-Kabel missbrauchen, also analog bzw. ISDN auf LAN-Kabel und das LAN-Kabel dann (über das Y-Kabel) in die FRITZ!Box TAE- bzw. ISDN-Buchse.

 

[McMicha]

Habe das Problem behoben - war wohl ein Fehler des Modems. Habe nun die FRITZ!Box als Modem konfiguriert. Nun läuft es wieder