FritzBox Fehler 488 bei Voip 2te Leitung

Gelöst

Hallo,

 

FritzBox wie üblich eingerichtet, Verbindung besteht und funktioniert alles außer:

bei Telefonat mit 2ter Leitung kommt besetzt und in FritzBox Fehler "Internettelefonie mit xxxxxxxx@tel.t-online.de über tel.t-online.de war nicht erfolgreich. Ursache: Not Acceptable Here (488)"

Ebenso ist die Leitung bei eingehenden Anrufen belegt (Funktion "busy on busy" ist deaktiviert)

 

Laut AVM alles richtig eingestellt, auch schon mehrfach so erfolgreich gemacht. Telekom nicht zuständig??? ..kann doch nur seitens Telekom blockiert werden?

 

Lösungsvorschläge?

1 AKZEPTIERTE LÖSUNG
Lösung

Hallo in die Runde,

 

vor einigen Wochen schrieb ich hier im Thread:


@Helge aus H. schrieb am 31. März 2015:

Der technische Auslöser ist [...] einerseits das Verhalten des DSL-Endgerätes gegenüber dem Netz, andererseits die notwendige Qualitätssicherung im Netz selbst. Es geht um das Zusammenspiel (die „Interoperabilität“) von Endgerät und Netz – weder das Netz noch das Endgerät verhalten sich hier falsch. Lösungen sind daher sowohl im Netz als auch am Endgerät möglich. Wir arbeiten für Sie auch bereits an einer Lösung im Netz, konkret im IP Multimedia Subsystem (IMS).

 

Heute nun ist es soweit: Laut unseren Kolleginnen und Kollegen sind die Lösungsschritte im Netz der Telekom abgeschlossen. Auch mit geeigneten FRITZ!Boxen sollten nun an DSL 2000 RAM IP und DSL 6000 RAM wie gewohnt gleichzeitig zwei IP-basierte Telefonate möglich sein.

 

Damit hat sich *eine* Hoffnung von Bodo-Hybrid bereits erfüllt:


@Bodo-Hybrid schrieb:

@prodo_1

 

Hoffnung auf nen baldiges Update sowohl Firmware als auch Netzrichtlinien der Telekom.

 

Bei dieser Gelegenheit zwei klare Worte an HeikoHärtel:


@Gelöschter Nutzer schrieb:
wenn Du darauf warten willst das die Telekom da etwas einsieht und ändert wirst Du warten bis Dir ein langer Bart wächst.

Mir ist bewusst, dass wir nicht jede Einschränkung am Dienst, im Netz oder beim Einsatz eines Endgerätes der Telekom so rasch beseitigen konnten wie in diesem Fall.

 

Wir schneiden aber seit geraumer Zeit alte Zöpfe & Bärte ab und gehen Ihren Hinweisen auf solche Einschränkungen aktiv für Sie nach.

 

Alle Kolleginnen und Kollegen unserer Fachbereiche, denen ich in diesem Zusammenhang begegnet bin, haben sowohl Einsichtsfähigkeit als auch guten Willen gezeigt und durch die erfolgten Änderungen im Netz für Sie erlebbar bewiesen.

 


@Gelöschter Nutzer schrieb:
@ohoh @prodo_1 gleich kommt magenta Bruno
und schimpft wieder über Deine Wortwahl bezüglich des kaputten SIP-ALG

 

Sie beziehen sich auf einen Hinweis von @prodo_1; da wir hier nicht im Kindergarten sind und weder ein Community Guide noch das Telekom hilft Team mit jemandem „schimpft”, der ein Anliegen sachlich darstellt, gehe ich gern in der Sache direkt auf prodo_1 ein:


@prodo_1 schrieb:
Das zweite Thema ist der kaputte SIP-ALG im SP-H der preferred in der Telekomspezifikation als verpflichtend auslegt und einen Teil des Registrierungsvorgangs verschluckt (wenn fetch bindings genutzt wird, was die Fritz macht). Wenn man das nicht beachtet, gibt es einen temporären Bann vom Telekom VOIP Serverfür zufällige Rufnummern. Telefonieren ist dann Glücksspiel.

Zum Thema „fetch binding” und der Tatsache, dass dieses Verhalten im Netz der Telekom laut SIP-Spezifikation erklärtermaßen unerwünscht ist, hatten wir uns ja in einem Parallel-Thread ausgetauscht. Wir gehen der technischen Ursache für die Situation im geschilderten Nutzungsszenario und denkbaren Lösungen intern bereits nach.

 

Bis dahin ist ein zuverlässiger Workaround verfügbar, indem nämlich das Verhalten der FRITZ!Box beim Einsatz als IP-Client hinter einem Speedport Hybrid entsprechend angepasst wird. Auch das FRITZ!OS könnte sicherlich hierzu beitragen, wenn es noch genauer auf den Betrieb an den IP-basierten Anschlüssen der Telekom abgestimmt würde – wie beim SIP-Fehler 488 gehören halt auch hier zwei Seiten zu der einen Medaille . . .

 

 

Beste Grüße

von

Helge R.

Lösung in ursprünglichem Beitrag anzeigen  


@Johannes S. schrieb:

 

Wir wollen Ihnen - wie bisher - das qualitativ hochwertige Produkt zu attraktiven Preisen bieten.


Die Realität sieht leider anders aus. Der Telekom-hilft-Bereich beweist es.

 


@Johannes S. schrieb:

 

An der Migration auf ALL-IP führt dabei aus verschiedenen Gründen kein Weg vorbei. Nicht zuletzt deshalb, weil die Alttechnik nur noch für einen überschaubaren Zeitraum auf dem Markt für uns verfügbar ist [...]


 Komischerweise sehen das andere Anbieter nicht so pessimistisch.

 


@Johannes S. schrieb:

 

Die Priorisierung von VoIP  dient letztendlich der Sicherung der Sprachqualität - besonders da, wo VoIP bei weniger performanten DSL-Verbindungen in Konkurrenz zu Nicht-Echzeit-Anwendungen steht. Die Bandbreitenreservierung erfolgt innerhalb unserer IP-Infrastruktur.


Danke für die Herausarbeitung der konzeptionellen Nachteile von VoIP gegenüber der abgeschafften Qualitätstelekommunikationsinfrastruktur.

 


@Johannes S. schrieb:

 

@bankrobbery

Sie haben die Details in Ihrem letzten Beitrag super auf den Punkt gebracht. Dem ist nicht viel hinzuzufügen. 


Dann haben wir nach all dem monatelangen Hinhalten und Herumgerede um den heißen Brei jetzt endlich eine offizielle, konkretisierende Erklärung/Erläuterung des Problems von der Telekom.

 

Ich kann nur erneut fordern, diesen undurchdachten und unvollständig implementierten Bandbreitenreservierungsmechanismus, den die Telekom benutzt, sofort zu deaktivieren und nachzubessern.

Es wird ein Gespräch mit G.711 oder G.722 geführt, und die Telekom meint, statt 64 kBit/s netto das doppelte und irgendwas anderes an Bandbreite reservieren zu müssenWeinend

 

Grüße

spi


@Hubert Eder schrieb:

Einige Kunden berichten, sie können an den betroffenen Anschlüssen mit Routern anderer Hersteller ebenfalls zwei Verbindungen gleichzeitig aufbauen.


Hallo Hubert,

 

welche Router sind das? Interessant für viele, die eine Alternative zu FRITZ!Box und Speedport suchen!

Das würde hier wirklich weiterhelfen, denn die Telekom scheint die Lösung ihres Problems nur sehr, sehr langsam zu verfolgen.

 

Grüße

spi

 


@Twostroker schrieb:

Hier sind genug Boxen dabei, die per Telnet auf diese beiden Codecs limitiert worden sind.

Heist: Es gibt nur noch 711/722 in den Fritzboxen und nichts weiteres mehr an Codecs.

 

Und es läuft trotzdem nicht.


Ist das wirklich so, dass die Einschränkung der Codec-Liste an der IMS-Plattform nicht (mehr bzw. immer) greift?

 

Die Telekom kommt ja leider nicht zu Potte. Es wäre schön, nachdem der Workaround "TAS-Plattform" weggefallen ist, den aktuellen Status des Workarounds "Codec-Liste" festzustellen.

 

Grüße

spi

@spi

Zum Beispiel der Zyxel Speedlink 5501.

 

Gelöschter Nutzer

Ich bin zwar mehr in der Hybrid Ecke zu finden aber hier folgendes was ich in meiner Fritzbox angepasst habe.

 

use_audiocodecs = yes;
audiocodecs = "G722", "G711-HD", "PCMA", "PCMU";

 

Die Entscheidende Änderung war allerdings bei jeder Telekomnummer:

no_register_fetch = no;

auf

no_register_fetch = yes;

zu setzen vielleicht hilft es ja dem ein oder anderen.

Folgende Anleitung hat bei mir funktioniert:

 

Telnet mit dem Telefon aktivieren:

#96*7*

mit Putty per Telnet auf die FritzBox zugreifen und Konfiguration öffnen:

nvi /var/flash/voip.cfg

Fett markierte Werte ändern:

ua1 {
no_register_fetch = yes;
}
ua2 {
no_register_fetch = yes;
}
use_audiocodecs = yes;
audiocodecs = "G722", "PCMA";

Abspeichern:

:wq!

Änderungen übernehmen:

voipcfgchanged

 Telnet mit dem Telefon deaktivieren:

#96*8*

 

Zum einen wird die Codec-Liste damit auf G.711 und G.722 beschränkt, was zwei ausgehende Gespräche scheinbar relativ zuverlässig ermöglicht aber was soll sich mit no_register_fetch = yes zusätzlich ändern?

 

Übrigens habe ich gestern noch einmal das Problem aus dem inzwischen geschlossenen Parallelthread bestätigen können, dass es nicht ausreicht, nur die eigenen Codec-Liste zu verändern. Wenn man einen entsprechenden Anschluss hat (z.B. DSL 2000 RAM) und eine Leitung belegt ist und dann zusätzlich von einem Telekom-IP-Anschluss mit einer unmodifizierten Fritzbox angerufen wird, erhält dieser Anrufer auch ein Besetztzeichen. Hier scheint der gleiche Effekt in der anderen Richtung aufzutreten: Ein Kanal ist belegt und die zusätzlichen Codecs führen auf der IMS-Plattform zum Abweisen des zweiten Anrufs, da die Upload-Grenze für VoIP überschritten würde wie in einem vorherigen Beitrag erläutert:

 

""Die Fritzbox sendet an erster Stelle einen Sprach-Codec, der unserer Plattform nicht bekannt ist.
Es muss aber für jedes Gespräch eine Bandbreite reserviert werden, welche abhängig vom Codec ist.
Bei unbekannten Codecs wird eine Default-Bandbreite (125kbit/s) reserviert, anstatt 87kbit/s bei G.711/G.722.
Telekom-RAM-Anschlüsse lassen aber in Summe nur eine Bandbreite von exakt 196kbit/s für Sprache zu.
2 x 125kbit/s ist damit zu viel und ein 2. Gespräch ist nicht möglich."


@ilion schrieb:

Zum einen wird die Codec-Liste damit auf G.711 und G.722 beschränkt, was zwei ausgehende Gespräche scheinbar relativ zuverlässig ermöglicht aber was soll sich mit no_register_fetch = yes zusätzlich ändern?


Hallo ilion,

 

dieser Parameter ändert das Registrierungsverhalten der FRITZ!Box beim SIP-Proxy: Die FB führt dann nur noch Registrierungen und Reregistrierungen durch, aber keine zwischenzeitliche Abfragen mehr zur Registrierung.

Die Änderung hat sich als wesentlich für den Betrieb einer FB hinter einem Speedport Hybrid herausgestellt, da der im Speedport enthaltene rudimentäre Open-Source-SIP-Proxy diese Registrierungsabfrage nicht korrekt verarbeitet und für eine Deregistrierung hält.

 

Das ist zwar im Prinzip eine andere Baustelle, aber meinen derzeitigen Erkenntnissen nach verarbeitet und beantwortet auch die IMS-Plattform der Telekom diese Registrierungsabfragen nicht korrekt.

 

Grüße

spi

Hallo,

 

ich hab die für meinen Kommunikationskreis relevanten Fritzboxen mittlerweile auf die Codecs G.711 und G722 zurecht gestutzt und das funktioniert scheinbar relativ zuverlässig. Es wurde jedenfalls keine Klagen an mich weitergetragen.

 

@bankrobbery's Zusammenfassung scheint das Problem relativ gut zu beschreiben. Ich bezweifele aber, dass die Reihenfolge der Codecs etwas ausmacht und die fiktive Zahl von 125kBit/s wäre schön, weil die in Summe immer noch ausreichen würde für 2 Leitungen. Es scheint, dass das Reservieren der Bandbreite komplett aus dem Tritt kommt, wenn andere Codecs in der Liste stehen.

In den zitierten Telekom-Dokument steht aber in keinster Weise, dass man keine anderen Codecs in der Liste unterstützter Codecs haben darf. Es steht meines Erachtens drin, welchen man für Gespräche nutzen soll. Und verwendet werden auch von der Fritzbox immer die guten G.711/G.722.

 

@Helge aus H.oder @Johannes S.: Ich hoffe, dass die Aussage, dass der volle, fehlerfreie Funktionsumfang des Telekom IP-Anschluss NUR mit Speedports neuester Generation  garantiert werden kann, ist ein Versehen von Helge. Das widerspricht auch Helges Aussage, dass kein Mangel am Produkt vorliegt.... Könnten wir hierzu ein Richtigstellung seitens der Telekom erhalten? Oder vielleicht einen verbindlichen Zeithorizont, wann IMS an die hohen Qualitätsansprüche der Telekom wieder angepasst ist?

 

Zum Thema Geräte: Es wurden auch andere Geräte erfolgerich getestet - die waren aber allesamt Telekom-gebranded... Auch der Zyxel-Router ist es.

 

Und man kann nicht genug betonen, dass es nicht ausreicht, die eigene Fritzbox am vermeintlich langsamen Anschluss zu patchen, weil eingehende Gespräche von ungepatchten Firtboxen vom IMS abgelehnt werden...Zum Glück ist das kein Mangel am Produkt.

 

Grüße, Ivo

 

 

ich hab die für meinen Kommunikationskreis relevanten Fritzboxen mittlerweile auf die Codecs G.711 und G722 zurecht gestutzt und das funktioniert scheinbar relativ zuverlässig.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

Das hör ich gerne Fröhlich

Darf ich fragen ob mit oder ohne 

no_register_fetch = yes;

?

Moin,

 

heißt das, es dürfen nur diese beiden Codecs in der config bleiben. Alle anderen löschen?

 

Gruß

 

Friedrich

 

PS: Was allerdings sehr witzig ist.

 

Mein Nachbar hat auch die 7490, Anbieter Telekom und auch IP-basierten Anschluss. Und er kann auf beiden Leitungen raustelefonieren! Soeben probiert.


f-siefken schrieb:
Mein Nachbar hat auch die 7490, Anbieter Telekom und auch IP-basierten Anschluss. Und er kann auf beiden Leitungen raustelefonieren! Soeben probiert.

 


Es ist von der im Upstream zur Verfügung stehenden Bandbreite abhängig.

Upstream von 672 kbit/ s reicht nicht aus?


@etSoftware schrieb:

ich hab die für meinen Kommunikationskreis relevanten Fritzboxen mittlerweile auf die Codecs G.711 und G722 zurecht gestutzt und das funktioniert scheinbar relativ zuverlässig.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------

Das hör ich gerne Fröhlich

Darf ich fragen ob mit oder ohne 

no_register_fetch = yes;

?


Ohne no_register_fetch = yes;

Ich hab nur die Codecs frisiert.

 

@f-siefken: Es muss ein DSL2000 Annex J oder DSL6000 Annex P angerufen werden. Diese Anschlüsse erreicht man nicht auf deren zweiter Leitung, selbst wenn deren Fritzbox gepatcht ist - die des Anrufenden aber nicht.

 

Ivo


@f-siefken schrieb:
[...]
heißt das, es dürfen nur diese beiden Codecs in der config bleiben. Alle anderen löschen?
[...]

Hi Friedrich,

 

ich verwende grade:

 

use_audiocodecs = yes;
audiocodecs = "G722", "PCMA", "PCMU";

 

 

Damit man aber ganz konform zur Spezi 1TR114 V3.00 der Telekom ist (die von der Telekom hier im Thread mehrfach schon bemüht wurde), kann man den PCMU zusätzlich noch weglassen. Dort werden nur G.711a (PCMA) und G.722 erwähnt.

 

Ivo

 

Hi Ivo,

 

habe den String genauso geändert, wie Du diesen beschrieben hast, also mit den 3 Codecs.

 

Es funzt wunderbar!

 

Besten Dank und ein schönes Osterfest.

 

Gruß

 

Friedrich

Hat wohl mit dem Upstream nicht viel zu tun.

 

Ich habe die Konfiguration der Box lt. der Beschreibung von Ivo geändert, und siehe da: Es funktioniert!

 

 

Gelöschter Nutzer

Naja der eine Wert verhindert das du dort auf der VOIP Plattform teilweise gebannt wirst.

 

Die codecs sorgen dafür das Du eine feste Bandbreite nutzt. Wurrde aber glaube ich auch schon erklärt.

Mit den Standardeinstellungen kann es passieren das Du den "reservierten Bereich" schon mit 1 Nummer nutzt.

 

Aber schön zu lesen das es nun bei Dir auch klappt.

Übrigens die Erkenntnisse stammen aus den Hybriderfahrungen Fröhlich

Hallo Heiko,

 

auch Dir noch mal herzlichen Dank für Deine Tipps, die ich ja auch umgesetzt habe.

Wichtig ist, dass es jetzt endlich funzt, hoffentlich bleibt das so....

 

Ein schönes Osterfest wünsche ich Dir und den Deinigen.

 

Friedrich

Gelöschter Nutzer

Danke danke ich tüftel schon am nächsten Projekt....

möchte ja meine Nummern auch auf dem Handy überall nutzen Fröhlich

(dank weißenSpeedportDingsbumskeineahnungwasesistTEIL aktuell nichtmehr direkt möglich)

Mit der FRITZ ist ja vieles möglich.....

Hi Friedrich,

 

danke für die Blumen. Freut mich, dass es bei dir funzt.

Ich will mich nicht mit fremden Federn schmücken. @ilion hat's Ende Februar vorgeschlagen.

 

Grüße, Ivo

Jetzt wäre es nur noch schön, wenn AVM diese Änderungen offiziell mit in ihre Firmware einbringt, damit möglichst vielen Kunden geholfen ist.

Das Schlimme ist ja, das die Fritzbox nichts falsch macht. Es gibt dazu auch Knowledgebase-Artikel von AVM dazu.

Das Tischtuch zwischen AVM und der Telekom scheint mir zerschnitten oder zumindest stark angerissen zu sein, seit die Telekom lieber in China Hardware bestellt. In der guten, alten Zeit hätte AVM hier vielleicht schneller einen Workaround für ein - laut Telekom - Interop-Problem geliefert.

Es bleibt spannend, wann die Telekom einen Fix liefert. So lange wie das mittlerweile schon geht, glaube ich, dass AVM hier aus Prinzip nichts liefen will und wird. So schlecht es auch für die Kunden von AVM und Telekom ist.

 

Grüße, Ivo

Gelöschter Nutzer

@dennisfischer79 schrieb:

Jetzt wäre es nur noch schön, wenn AVM diese Änderungen offiziell mit in ihre Firmware einbringt, damit möglichst vielen Kunden geholfen ist.


Lese Dich mal in die Materie ein Fröhlich

dann kommt es nicht zu solchen Falschaussagen!