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  

ich verfolge alle Beiträge in diesem Forum und auch im geschlossenen Forum habe ich alle Beiträge gelesen.

Mein IP Anschluss ist ein DSL  RAM 6000 und ich kann auch keine 2. Verbindung mit der Fritzbox 7490 gleichzeitig aufbauen. Da ich aber von dieser Technik sehr wenig verstehe und ich aber zwei gleichzeitige Leitungen öfter gebrauche, habe ich folgende Frage wenn ich nun  einen Anschluss mit 16 000 bekommen kann, es könnte vielleicht im Sommer sein, würde dann der Aufbau der zweiten Leitung kein Problem mehr sein ?

Denn die Fritzbox  zu programmieren mit G711 (a) oder G722 oder ???, dazu fehlen mir einige Grundlagen, die ich in den Beschreibungen nicht für mich entnehmen kann. Oder ich muss warten bis die Telekom diese Einschränkung behoben hat.

Mit dem 16MB-Anschluß kommen die Probleme nicht vor.

Es geht hier nur um RAM-Anschlüsse mit 2 und 6 MB. RAM bedeutet in dem Zusammenhang, das die Bandbreite nicht auf einen festen Wert eingestellt ist sondern sich auf den bestmöglichen Wert, den die Leitung hergibt. Das können zB 3,5MB sein oder auch 5,2MB, je nachdem, wie lang die Leitung ist.

 

Bei früheren Anschlüssen wurden die Anschlüsse nur in Stufen eingestellt und diejenigen, die nun zB mit 5MB unterwegs sind hätten früher nur 2MB bekommen, weil es zwischen 2 und 6MB keine Zwischenstufen gab.

 

16MB zählt zwar auch als RAM, hat aber im Upstream eine genügend große Bandbreite um das Problem der Abweisung eines zweiten Gesprächs zu umgehen.

Danke, habe ich auch schon vermutet, es läßt hoffen, denn ich habe ja einen Call & Surf Comfort IP (5 )      ( von Mai 2014- Mai 2016). bis 16 000 und im Sommer sollen dann ja 16 000 möglich sein, dann brauche ich ja nicht einen neuen Tarif oder einen anderan Anbieter..  Die Telekom hat es ja in den vergangenen Monaten nicht geschafft, diese Einschränkungen bei den 2000 und 6000 Anschlüssen zu beheben.

Hallo Helge R.

  Helge schrieb:

 

Wie bei SIP üblich bieten wir beim Verbindungsaufbau die auf FRITZ!Box Seite zur Verfügung stehenden Codec mit einer von uns definierten Priorisierung an. Dort sind unter anderem natürlich auch der Codecs g.711a und g.722 enthalten. Welche Codecs für das Gespräch dann letztendlich zur Verwendung kommen, kann der SIP-Registrar dann doch maßgeblich beim Verbindungsaufbau bestimmen.

Wenn ich die Aussage richtig deute gibt die Telekom dann hier vor, dass bei SIP-Aushandlung nur Codec g.711a und g.722 verwendet werden darf. Das widerspricht doch aber grundlegend dem Prinzip der Codec-Aushandlung mit SIP, bei welcher beide Seiten jeweils der Gegenseite alle zur Verfügung stehenden Codec innerhalb einer Priorisierungsliste kundtun und sich dann auf den ersten gemeinsam verwendbaren Codec geeinigt wird.

 

Ich habe von AVM zu diesen Fehler folgende Antwort erhalten: 

 

Wie bei SIP üblich bieten wir beim Verbindungsaufbau die auf FRITZ!Box Seite zur Verfügung stehenden Codec mit einer von uns definierten Priorisierung an. Dort sind unter anderem natürlich auch der Codecs g.711a und g.722 enthalten. Welche Codecs für das Gespräch dann letztendlich zur Verwendung kommen, kann der SIP-Registrar dann doch maßgeblich beim Verbindungsaufbau bestimmen.

Wenn ich die Aussage richtig deute gibt die Telekom dann hier vor, dass bei SIP-Aushandlung nur Codec g.711a und g.722 verwendet werden darf. Das widerspricht doch aber grundlegend dem Prinzip der Codec-Aushandlung mit SIP, bei welcher beide Seiten jeweils der Gegenseite alle zur Verfügung stehenden Codec innerhalb einer Priorisierungsliste kundtun und sich dann auf den ersten gemeinsam verwendbaren Codec geeinigt wird.

 

Meine Fragen:

   Ist es richtig, dass ich bei meinem DSL 6000 RAM Anschluss nur zwei Gespräche gleichzeitig führen kann, wenn mein Router nur g 711a und g722 verwendet ? Und entspricht diese Vorgabe dem Prinzip der Codec-Aushandlung mit SIP? 

Wann ist diese Enschränkung endlich behoben?

Hallo, das würde mich auch interessieren. Bin in der gleichen Situation und auch mit der gleichen Anschlussvarriante DSL6000Ram und IP. Habe das gleiche Telefonieproblem und es wurde, selbst nachdem ein Techniker vor Ort war und das selbst nachvollziehen konnte (mit der Aussage das Problem liegt in der Vermittelungsstelle), am Ende wieder nur auf ein Problem der Fritzbox verwiesen wird. Das Problem ist aber anscheinend die geringe Bandbreite im Upload und der weiterhin bestehende Annex B Anschluss, es wurde bei mir nicht auf Annex J umgeschaltet, so das dass freigewordene Frequenzband der vorherigen ISDN Leitung nicht genutzt wird. Bei einem Test mit Speedport 724v vom Nachbarn besteht nämlich weiterhin das gleiche Problem bei mir, so das dass FB Geschwafel der Telekom hinfällig ist und das es mit dem eigenen Gerät funktioniert. Nur das interessiert dort keinen und ich stehe da mit dem Problem, das die frühere ISDN Funktionalität nicht mehr zur Verfügung steht, auf die ich aber beruflich angewiesen bin (Homeoffice).

Helge R.

 

entschuldige!

Helge schrieb Nicht: Wie bei SIP üblich ...

 

Helge schrieb:

     Für die Interaktionen mit der SIP-Schnittstelle der Telekom muss das Endgerät einen der Codecs G.711a oder G.722 beherrschen. Grundsätzlich nimmt unsere SIP-Schnittstelle auch andere definierte Audio-Codecs (z. B. G.726-4 oder iLBC) entgegen und leitet sie getreulich („transparent”) zum Gesprächspartner durch, aber für ein solches Gespräch reserviert die Qualitätssicherung derzeit prophylaktisch einen festen Anteil des SIP-Kontingents im DSL-Durchsatz (und zwar mehr als bei G.722). Beides zusammen führt zu den Einschränkungen, deren Ursache und Behebung wir hier diskutieren.

Nur das die Fritzbox bei mir beim Gesprächsaufbau immer nur G722 nutzt und es geht trotzdem nicht.


@Mac67 schrieb:

Nur das die Fritzbox bei mir beim Gesprächsaufbau immer nur G722 nutzt und es geht trotzdem nicht.


Ja, eben, das ist der Widerspruch, den ich auch nicht kapiere. In der Spezi, die Helge heranzieht, steht meines Erachtens mit keiner Silbe drin, dass in der Codec-Vorschlagsliste nicht "andere" Codecs (ungleich G.711a oder G.722) enthalten sein dürfen. Für das tatsächliche Encoding eines Gesprächs schlägt die Telekom tatsächlich G.711a oder G.722 vor, was auch legitim ist.

Aber Fakt ist weiterhin, dass die Fritzbox bei Tests immer G.711a oder G.722 nutzt (also alles richtig macht laut Spezi), aber scheinbar nur das bloße _Vorhandensein_ von anderen Codecs in der Vorschlagsliste bei der Telekom ein Problem verursacht....

@Hanseat19, danke für dieses Ticket mit entsprechender AVM-Antwort!

 

Ivo

hallo die Runde, wollte mich nicht mehr dazu äußern aber das Geschwafel der Telekom bringt mich zur Weißglut, hier zum X-tenmale die Aussage von AVM Fehlermeldung "Not Acceptable Here (488)" bei Aufbau eines zweiten Gespräches am Telekom-Anschluss Wenn bereits ein Gespräch über eine Internetrufnummer der Telekom geführt wird, kann kein zweites Gespräch über eine Telekom-Rufnummer aufgebaut werden. Dadurch sind auch keine Rufumleitungen oder Callthrough-Verbindungen möglich. In den Ereignissen der FRITZ!Box wird nach dem Fehlerfall die Fehlermeldung "Internettelefonie mit [Rufnummer@tel.t-online.de] über [tel.t-online.de] war nicht erfolgreich. Ursache: Not Acceptable Here (488)" ausgegeben. Kein Fehler der FRITZ!Box Die Ursache ist eine Fehlbehandlung bei der Bandbreitenbestimmung auf Seiten der Telekom. Von diesem Fehler sind aktuell einige der IP-basierten Telekom-Anschlüsse mit Datenraten von maximal 6 Mbit/s betroffen. Die Telekom ist von AVM informiert worden und wird - nach unserer Kenntnis - den Fehler auf ihrer Seite beheben. gruss und viel Glück beim Versuchen ws

Hallo an die Runde,

und mein Respekt für die vielen spannenden Beiträge, die in den vergangenen Tagen eingegangen sind.

Meine persönliche Zusammenfassung ist diese:
Die Fritzbox bietet beim VOIP-Verbindungsaufbau Sprach-Codecs an, die von unserer Telefonie-Plattform IMS (IP Multimedia Subsystem) nicht unterstützt werden. IMS reserviert für die nach unserer Spezifikation 1TR114 nicht unterstützten Codecs die voip-technisch größtmögliche Bandbreite. Diese reicht bei DSL 2000 RAM oder DSL 6000 RAM maximal ein Gespräch. Ein zweites gleichzeitiges Gespräch wird, gleich ob kommend oder gehend, mit dem Hinweis auf die unzureichende Ressource abgewiesen. In diesem Fall entscheidet sich unser System für die Sprachqualität, anstatt ein zweites Gespräch mit vermutlich einer schlechteren Gesprächsqualität (nach dem Best-Effort-Prinzip) zuzulassen.

 

User bankrobbery hat die technische Seite in seinem Beitrag super zusammengefasst - da wiederhole ich mich gerne noch einmal.

 

Bemerkenswert ist nach meiner Meinung die Anleitung von redgolem, die sich nur an den Experten richten kann. Ich bin echt verblüfft, wie wenige Veränderungen in den Konfigurationsdateien der Fritzbox erforderlich sind, um ein zweites Gespräch bei DSL 2000 RAM oder DSL 6000 RAM zu ermöglichen. Ganze vier Einstellungsänderungen sind hier ausreichend. Allerdings sind wir uns sicherlich auch einig, dass diese "Hacks" im Linux-Terminal ausschließlich für erfahrene User in Frage kommen. Für die überwiegende Mehrzahl der Betroffenen ist dies sicherlich keine Lösung, zumal sich meines Erachtens auch die Frage nach der Gewährleistung stellt.


@ivo.matheis schrieb:

In der guten, alten Zeit hätte AVM hier vielleicht schneller einen Workaround für ein - laut Telekom - Interop-Problem geliefert.

Ich denke, es geht nicht um persönliche Befindlichkeiten, sondern darum, im Sinne unserer Kunden eine rasche Lösung für dieses  Interoperabilitäts-Thema zu finden. Wie Helge schon unterstrich, sind wir besten Willens, dies zu erreichen.

 

Viele Grüße

Johannes S.

 

 

 

 

Diese reicht bei DSL 2000 RAM oder DSL 6000 RAM maximal ein Gespräch. Ein zweites gleichzeitiges Gespräch wird, gleich ob kommend oder gehend, mit dem Hinweis auf die unzureichende Ressource abgewiesen. In diesem Fall entscheidet sich unser System für die Sprachqualität, anstatt ein zweites Gespräch mit vermutlich einer schlechteren Gesprächsqualität (nach dem Best-Effort-Prinzip) zuzulassen.

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

 

Die zur Verfügung stehende Bandbreite würde sogar für noch viel mehr reichen, als nur für zwei Gespräche in Super-Qualität. Die Entscheidung ein zweites Gespräch abzulehnen aus falschen Vermutungen heraus möchte ich bitte nicht. Bevor Sie auf IMS umgestellt haben gings doch auch in mir völlig ausreichender Sprachqualität. Also stellen Sie das bitte wieder ab.

 

Danke Fröhlich

So sieht es aus, nach Umstellung auf IP, mit der vorhandenen Hardware,  hat alles 3 Monate einwandfrei funktioniert.

Im Dezember dann Umstellung in der Vermittlungsstelle auf Infineon Server und damit das aus in der Telefonie bei mir.

Seitdem 488 Problem und Schuld ist nur der Kunde oder dessen Hardware.

 

Danke Telekom, ihr wisst gar nicht welche Probleme daraus für Kunden im realen Leben entstehen.

 

 

Hallo Mac67,

 

exakt so isses, aber es interrsiert bei der Telekom keinen. Da es wenig bis keine Ausweichmöglichkeiten gibt ist es so und wird solange so bleiben bis die Telekom er ändert, aber warum soll sie? Keiner von uns hat hier die Macht die grosse Telekom zum Handeln zu bringen geschweige zu zwingen, wie auch?

also, WARTEN ! HOFFEN !?

Ich hoffe inständig einmal in eine Position zu kommen das mir diese Behandlung wieder einfällt...

 

ws

Sodele, hab heute morgen die Codec-Liste auf G722 und PCMA eingeschränkt und es gehen nun 2 Leitungen gleichzeitig raus Fröhlich

Aber eben kam der Anruf, dass das am S0-Bus angeschlossene EC-Cash Terminal keine Verbindung mehr zu Stande bringt.  Traurig

Hängt das zusammen ? Wenn ja, kann mir da jemand helfen ?


@Johannes S. schrieb:

[...]

IMS reserviert für die nach unserer Spezifikation 1TR114 nicht unterstützten Codecs die voip-technisch größtmögliche Bandbreite. Diese reicht bei DSL 2000 RAM oder DSL 6000 RAM maximal ein Gespräch. Ein zweites gleichzeitiges Gespräch wird, gleich ob kommend oder gehend, mit dem Hinweis auf die unzureichende Ressource abgewiesen. In diesem Fall entscheidet sich unser System für die Sprachqualität, anstatt ein zweites Gespräch mit vermutlich einer schlechteren Gesprächsqualität (nach dem Best-Effort-Prinzip) zuzulassen.

[...]

 

 

> Was wird denn als "voip-technisch größtmögliche" Bandbreite angenommen? Entweder ist diese Annahme sehr/viel zu hoch oder als maximaler Bandbreitenwert wird gar nicht der wirklich zur Verfügung stehene Upload verwendet, sondern irgendein kleinerer, fiktiver Wert. Bei einem Upload von etwa 500kBit/s (wie bei mir z.B.) wüsste ich nicht, welcher Codec hier nicht für zwei Gespräche reichen soll.

 



 


@ivo.matheis schrieb:

In der guten, alten Zeit hätte AVM hier vielleicht schneller einen Workaround für ein - laut Telekom - Interop-Problem geliefert.

@Johannes S. schrieb:

 

Ich denke, es geht nicht um persönliche Befindlichkeiten, sondern darum, im Sinne unserer Kunden eine rasche Lösung für dieses  Interoperabilitäts-Thema zu finden. Wie Helge schon unterstrich, sind wir besten Willens, dies zu erreichen.

 

 


Ich habe obenstehende Äußerung lediglich auf die Frage eines Users und vor dem Hintergrund getätigt, als dass AVM das Problem erstens bekannt ist und zweitens vermutlich relativ einfach umgangen werden könnte, wenn man sich die Hackerlösung anschaut.

Das ist aber de facto bisher (und die Angelegenheit zieht sich ja schon seit Anfang des Jahres) nicht geschehen. AVMs Antwort im Ticket von @Hanseat19 passt hier ins Bild. Welche Gründe AVM bewegen, hier keinen Workaround für ein Interoperabilitätsproblem mit der Telekom im Sinne der Kunden zu liefern, kann man nur vermuten.

 

Jetzt zur Frage aller Fragen, auf deren Antwort die Gemeinde sehnlichst wartet:

Können Sie, @Johannes S., oder sonst jemand bei der Telekom einen  konkreten Zeithorizont nennen, wann dieses Interoperabilitätsproblem im Sinne der Kunden gelöst sein wird? Auf diese Frage wurde bisher bedauerlicherweise immer nur ausweichend geantwortet.

 

Ihr Kollege Helge hatte neulich einen Durchbruch angekündigt, damit aber leider nicht die Problemlösung, sondern vermutlich die interne Analyse gemeint.

 

Grüße, Ivo

Hallo in die Runde,


dass Sie als unmittelbar Betroffene Widerspruch zu meinem Beitrag anmelden, verstehe ich. Und dass Sie als Kunde "telefonmäßig" eingeschränkt und unzufrieden sind, ist per se ganz und gar nicht gut. Wie bereits mehrfach erwähnt, handelt es sich um ein klassisches Interoperabiltäts-Thema und da sind alle Beteiligten gefordert.

@eSoftware schrieb:
Die zur Verfügung stehende Bandbreite würde sogar für noch viel mehr reichen, als nur für zwei Gespräche in Super-Qualität.

Ich hatte meine Aussage auf die "voip-technisch" reservierte Bandbreite bezogen, die als qualitätssichernde Maßnahme bei nicht unterstützten Sprach-Codecs vorgehalten wird. Da kommt es bei den schmalbandigeren DSL-Anschlussen in Verbindung mit der Fritzbox zu den hier diskutierten Einschränkungen.

@ivo.matheis schrieb:
Können Sie, @Johannes S., oder sonst jemand bei der Telekom einen  konkreten Zeithorizont nennen, wann dieses Interoperabilitätsproblem im Sinne der Kunden gelöst sein wird? Auf diese Frage wurde bisher bedauerlicherweise immer nur ausweichend geantwortet.

Wir können Ihnen leider noch keinen konkreten Zeitpunkt nennen. Sobald wir neue Informationen haben, informieren wir Sie hier. 
Viele Grüße
Johannes S.

 

Johannes:

Ich hatte meine Aussage auf die "voip-technisch" reservierte Bandbreite bezogen, die als qualitätssichernde Maßnahme bei nicht unterstützten Sprach-Codecs vorgehalten wird. Da kommt es bei den schmalbandigeren DSL-Anschlussen in Verbindung mit der Fritzbox zu den hier diskutierten Einschränkungen.

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

 

Eine "qualitätssichernde Maßnahme", die mir die 2. Leitung verweigert, möchte ich nicht.

 

Vor ihrer Umstellung auf IMS gings doch wunderbar in guter Qualität auf zwei Leitungen zu telefonieren.

Und das hätte ich natürlich auch gerne weiterhin. Ist doch ganz einfach, oder ?

 

Das sehe ich genauso!

@Johannes S. schrieb:
[...]
 Wie bereits mehrfach erwähnt, handelt es sich um ein klassisches Interoperabiltäts-Thema und da sind alle Beteiligten gefordert.
[...]

Besonders die Kunden sind gefordert in ihrer Leidenfähigkeit. Traurig
Wenn Sie hier von "alle Beteiligten gefordert" sprechen: Arbeiten hier AVM und Telekom zusammen an einer Lösung?
Dass man kein Datum nennen kann, macht mir ehrlich gesagt etwas Sorgen....Grüße, Ivo

Hallo Johannes S.,

 

es handelt sich eben nicht um ein klassisches Interoperabiltäts-Thema, sondern die Schuld liegt allein bei der Telekom.

Der Bandbreitenreservierungsmechanismus der Telekom ist nirgendwo dokumentiert und auch die hier gegebenen Informationen sind mehr als dürftig.

 

Wieso - bitte schön - wird die Bandbreitenreservierung, wenn die auf einmal so dringend erforderlich sein soll - nicht mit einem genormten Protokoll unter Einbezug der SIP-User-Agents durchgeführt? Das Bottle Neck ist doch schließlich der Upstream des DSL-Anschlusses, oder doch nicht und das Telekom-IP-Backbone läuft jetzt schon am Limit und die Qualität von VoIP-Gesprächen kann sonst nicht mehr garantiert werden?

Die Telekom kann und darf keinem SIP-User-Agent auf der Welt verbieten, andere Codecs außer G.711 und G.722 zu benutzen. Wo kommen wir da hin? 

Die Telekom verbiegt weltweite Standardprotokolle nach Lust und Laune für ihre Zwecke und betreibt Finger Pointing auf Hersteller, die sich an die Standardprotokolle gehalten haben, um ihre Produkte weltweit vermarkten zu können.

 

Die Telekom-Implementierung Bandbreitenreservierung ist mindestens in dem Punkt proprietär, dass sie versucht, Bandbreite unter Umgehung der Endpunkte, die den Codec und damit die Bandbreite aushandeln, bevormundend festzulegen. Das ist schlicht und einfach eine Frickellösung. Abschalten.

 

Grüße

spi

Nachdem der Fehler "Nur ein Sprachkanal an dsl bis 6000 mit AVM Routern" seit Dezember 2014 auftritt gibt es wohl bis heute keine Lösung. Nach wie vor schiebt Telekom den Fehler zu AVM obwohl es bis Dezember funktionierte und dann plötzlichauch nicht mit einer älteren Firmware. AVM schiebt den Fehler auf Telekom was ja sehr naheliegend ist denn AVM hat sich ja nicht in alle Router eingewählt um Telekom zu ärgern.
Wann wird dieses Problem denn nun endlich gelöst?

Das Problem liese sich von beiden Seiten aus lösen.

 

Die Telekom könnte ihre Plattform so konfigurieren, dass diese dem Endgerät mitteilt, dass nur G.711a oder G.722 möglich ist. Dann gäbe es aber sicher wieder kritische Stimmen, wenn andere Codec nicht neutral durchgeleitet werden.

 

AVM hingegen könnte die Boxen so updaten, dass bei Telekom-Rufnummern nur G.711a und G.722 als mögliche Codec angefragt werden. Bei meiner C430 IP Basis kann ich z. B. problemlos für jede IP-Nummer einstellen, welcher Codec überhaupt in Betracht kommt und die gewünschte Priorität festlegen - bei AVM geht das nur umständlich über die Telnet-Geschichte.

 

Die Reservierung der Bandbreite seitens der Telekom könnte natürlich auch deaktiviert werden - jedoch sehe ich auch ein, dass darauf wert gelegt wird, die Telefonie im Netz mit oberster Priorität zu behandeln, damit es störungsfrei läuft. Sonst gäbe es auch Meckerei.

 

Am einfachsten dürfte es sein, AVM brächte ein Update heraus, welches festlegt, das G.722 oder G7.11a bei registrierten Telekom-Rufnummern als einzig zulässige Codec verwendet werden. Auch wenn zwischen AVM und der Telekom Spannungen bestehen, sollten die Berliner alleine im Hinblick auf die Kunden bemüht sein, das Problem zu lösen.

Warum nicht einfach die Bandbreitenreservierung ein bischen anpassen, sodass das nicht knapp danaben läuft, sondern grade noch so passt Zwinkernd

Weil Bandbreite ist ja eigentlich genug da.

Hallo,

 da es so einfach ist, hier noch einmal die LÖSUNG (ja, es hat 10 min gedauert und das Problem ist weg). Dies ist der Beitrag von REDGOLEM  https://telekomhilft.telekom.de/t5/Telefonie/FritzBox-Fehler-488-bei-Voip-2te-Leitung/m-p/1336282#M3... für Nicht-Linuxer wie mich.

 

Ich gehe davon aus, daß man vor einem "ganz normalen" Windows-PC sitzt, der im selben (Heim-)Netz wie die Fritzbox hängt.

 

1) Telnet vom IP-Telefon aus aktivieren:

http://thomasheinz.net/telnet-bei-der-fritzbox-z-b-7270-ohne-telefon-und-mod-aktivieren-und-verbindu...

 

2) Putty downloaden http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html und mit Doppelklick starten (muß nicht installiert werden).

 

3) Im Putty-Fenster die IP-Adresse der Fritzbox eintragen (Port belassen), in der Zeile darunter auf "Telnet" stellen (Port ändert sich in der Zeile darüber auf 23), unten auf "Open".

 

4) Wenn das sich öffnende Fenster nach dem Passwort fragt, hat man gewonnen. Passwort der Fritzbox blind eintragen und mit Enter bestätigen.

 

5) Jetzt den Editor aufrufen wie von redgolem beschrieben:

nvi /var/flash/voip.cfg

 

6) Mit der Pfeiltaste nach unten scrollen und im Abschnitt ua1 die Zeile suchen

no_register_fetch = "no";

 

7) Mit den Pfeiltasten auf das "n" von "no" navigieren, zweimal die x-Taste drücken (löscht das "no").

 

😎 Mit "i" den "insert"-Modus aktiveren, dann yes schreiben, mit der Escape-Taste den insert-Modus beenden.

 

9) Jetzt analog weitermachen wie im Beitrag von redgolem beschrieben: Suchen, mit x die falschen Buchstaben löschen, mit i den Insert-Modus aktivieren, schreiben, Escape.

 

10) Das Speichern etc. geht dann ohne weitere Verrenkungen genau wie von redgolem beschrieben. Wenn man fertig ist, macht man einfach das Fenster zu UND MAN KANN PLÖTZLICH WIEDER MIT ZWEI LEITUNGEN TELEFONIEREN!

 

Christoph

 

 

 

Leider löst auch das einseitige Ändern der voip.cfg-Datei das Problem nicht vollständig. Wenn man einen entsprechenden Anschluss hat, kann man zwar nach der Änderung zwei ausgehende Telefonate führen aber ein zweiter eingehender Anruf von einem Anschluss Telekom IP-Anschluss mit Fritzbox (der selbst keine Probleme hat, da er z.B. 2 Mbit/s Upload hat) führt beim Anrufer zum Besetztzeichen, während der angerufene Teilnehmer keinerlei Info erhält.

Die wirkliche Abhilfe besteht also in einer Anpassung/Korrektur der Bandbreitenlogik auf Seiten der Telekom und/oder Änderung sämtlicher Fritzboxen (und ggf. anderer Router wie älterer Speedports) mit Beschränkung auf G.722 und G.711 bei Telekom-IP.

 

Mal schauen, wie lange dieses Theater noch weiter geht ....