FritzBox Fehler 488 bei Voip 2te Leitung

luwfde · ‎17.11.2014

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?

Helge aus H. · ‎18.05.2015

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

muc80337_2 · ‎14.05.2015

AVM hatte früher mal in der Firmware die Möglichkeit, Sprachcodecs auszuwählen. Diese Administrationsmöglichkeit ist irgendwann mal (mir unverständlicherweise) rausgeflogen. Vermutlich hat es zu viele Supportfälle eingebracht.

Andererseits sieht man ja hier im Thread, dass auch die Nicht-Administrierbarkeit Supportfälle auslösen kann.

Wenn ich das Problem hätte, dann würde ich vermutlich den telnet auf die Box aktivieren und probieren, ob ich die voip-Konfigurationsdatei nicht entsprechend anpassen kann. Allerdings muss man schon auch klar sagen, dass jemand ohne Erfahrung sich da die Box schnell zerschießen kann. Ich poste jetzt mal explizit keinen Link zur Anleitung, wo beschrieben ist, wie man so etwas macht. Und auch keinen Link zu einem Recover-Image von AVM, mit welchem man die Box möglicherweise wieder funktionsfähig herstellen kann, wenn man Mist gebaut hat mit den Sprachcodecs.

prodo_1 · ‎14.05.2015

Nein, das glauben wir ganz bestimmt nicht. An der Umsetzung unserer Sprach-Codecs kann es eigentlich nicht liegen. Wirklich neu ist der G.722 für die Telefonie in HD-Qualität (HD Voice) eigentlich nicht. Der zweite Codec, der G.711, ist noch wesentlich älter und seit der Digitalisierung der Telefonnetze vor über 20 Jahren der Sprach-Codec schlechthin.

Bei solchen Antworten muss man sich schon fragen, ob das Problem verstanden wurde. Die genannten Sprachcodecs sind für die Fritz doch offensichtlich kein Problem. Das Problem ist, dass die Fritz mehr Codecs kann als von der Telekom vorgesehen sind und deshalb seitens der Telekom einfach pauschal die maximal denkbare Bandbreite reserviert wird. Das Problem ist also die Bandbreitenreservierung im Glaskugelverfahren (nur weil die Codecs theoretisch verwendbar sind und nicht, weil sie zum Einsatz kommen).

Und das was in dem im Post über Agfeo geschrieben wurde, gilt leider im Gegenteil für die Telekom. Hier tut sich ja seit Monaten nichts. Überflüssig sind die anderen Codecs übrigens nur aus Telekomsicht.

spi · ‎14.05.2015

Ja, lieber Johannes S.,

eine Lobeshymne auf den Workaround von Agfeo, aber was haben Sie im Namen der Telekom nach über einem halben Jahr über den Stand der Lösung des Problems, das die Telekom verursacht und zu verantworten und zu korrigieren hat, zu berichten?

Grüße spi

Gelöschter Nutzer · ‎14.05.2015

Guten Morgen,

@prodo_1noch 20 bis zum Update?

(die Telekom möchte es halt nicht verstehen...)

etSoftware · ‎14.05.2015

"...Problems, das die Telekom verursacht..."

Die Telekom macht kein Problem, die 'Telekom ist...

prodo_1 · ‎14.05.2015

@HeikoHärtel schrieb:
Guten Morgen,
@prodo_1noch 20 bis zum Update?

Moin, ich fürchte das Update dauert länger.

ilion · ‎15.05.2015

@Johannes S. schrieb:
   Hallo Netzwerker_VoIP,

   ....
   Aus zwei Gründen möchte ich mich herzlich für Ihren Beitrag
   bedanken. Zunächst finde ich es super, dass Sie uns nicht
   nur das Problem schildern, sondern auch gleich eine schnelle
   Lösung. Die lösungsorientierte Reaktion des Herstellers Ihrer
   TK-Anlage halte ich für bemerkenswert.
   ...

Hallo Johannes S.,

was hier immer wieder übersehen wird, ist die Tatsache, dass es keine Lösung ist. Es ist lediglich eine Möglichkeit, ein zweites ausgehendes(!) Gespräch führen zu können. Wenn man einen betroffenen Anschluss (Upload unter 700 kbit/s ?) hat und während eines vorhandenen Anrufs von einem Teilnehmer angerufen wird, der einen VoIP-Anschluss der Telekom hat (das sollen ja in den nächsten Jahren alle werden) und einen Router einsetzt, der zusätzliche Codecs anbietet, wie es nicht nur AVM sondern auch eine ganze Reihe andere Hersteller machen, dann bekommt dieser Anrufer ein Besetztzeichen und man selbst keinerlei Info über den fehlgeschlagenen Anruf.

Das sollte ein Grund mehr sein, endlich von Seiten der Telekom diese unnötige und bislang an keiner Stelle nachvollziehbar begründete Bandbreitensteuerung zu korrigieren oder auf den Zustand vor Dezember zurück zu gehen.

Man kann sich des Gefühls nicht ganz erwehren, dass die Telekom hier im Forum ähnlich professionell und freundlich wie am Telefon auftritt aber leider auch keine echte(!) Lösung erarbeitet. Mir fehlt inzwischen vollständig das Verständnis dafür und hoffe, dass ich demnächst auf Hybrid umstellen kann. Der dann notwendige Speedport-Zwangsrouter sollte dann das Telefonieproblem lösen und dafür alle möglichen Funktionen der Fritzboxen nicht mehr haben

Schönes Wochenende

prodo_1 · ‎16.05.2015

Auch hinter dem SP-H betreiben viele Leute die Fritzbox, weil der Router nicht viele Funktionen bietet und die paar vorhandenen teilweise noch fehlerhaft sind. Aber das Update kommt ja irgendwann und behebt irgendwelche Fehler ... vielleicht.

Johannes S. · ‎16.05.2015

Hallo Bodo,

@Bodo-Hybrid schrieb:

Habe bzgl. Hybrid dann heute ein neues eröffnet. (lt. Hotline ist da noch ein Fehler, ich bin noch gar nicht komplett freigeschaltet???!)

haben wir die Beeinträchtigung inzwischen beheben können? Entschuldigen Sie bitte, dass ein zweites Ticket erforderlich war.

Sie hatten in Ihrem vorgehenden Beitrag Schwierigkeiten beim Mischbetrieb von Fritzbox und Speedport Hybrid geschildert. prodo_1 hat dazu in seinem Beitrag einige super Tipps gepostet. Bestimmt ist etwas für Sie dabei.

Viele Grüße

Johannes S.

schraton · ‎16.05.2015

Guten Morgen,

ich will wahrlich nicht ätzen...

aber ist es nicht abartig? WIR zahlen den vollen Betrag an ein Unternehmen das uns die volle Leistung damit verkauft, aber leistet nur einen ganz Gringen Teil davon, der Nutzer muss und soll hier selber aktiv werden und sein... siehe lt Johannes

Sie hatten in Ihrem vorgehenden Beitrag Schwierigkeiten beim Mischbetrieb von Fritzbox und Speedport Hybrid geschildert. prodo_1 hat dazu in seinem Beitrag einige super Tipps gepostet. Bestimmt ist etwas für Sie dabei.

wird bei solcher oder ähnlicher Aktion die Box zerschossen....naja...haste eben pech gehabt..... ODER ?

Wie lange noch?

WS

Bodo-Hybrid · ‎16.05.2015

Hallo Johannes,

bzgl. der Störung bei LTE: Ja scheint erledigt zu sein, hat ein Routertausch stattgefunden, seitdem läuft das Bonding anscheinend ohne Probleme.

Bzgl. des Mischbetriebes: Werde mir den Beitrag nochmals genau anschauen. Allerding gehe ich nicht per Telnet auf die Box!

Wobei ich nicht ganz verstehe: Ich denke das Problem liegt in der Bandbreitenbeschränkung? Genrell habe ich ja Telefoniefunktion in der Fritzbox, halt nur nicht auf 2 Leitungen gleichzeitig. Die sonstigen Störungen kann ich vielleicht mit den dort genannten Tipps ein wenig beschränken.

Test folgt dann noch.

Gruß Bodo

Gelöschter Nutzer · ‎16.05.2015

ohne Telnet wirst Du wohl nix werden^^

wenn Du darauf warten willst das die Telekom da etwas einsieht und ändert wirst Du warten bis Dir ein langer Bart wächst.

Wir lassen uns ja schon alle Bärte wachsen weil wir auf das Firmware Update für den Hybrid warten...

können dann zu Weihnachten auch alle Weihnachtsmann spielen

prodo_1 · ‎16.05.2015

@Bodo-Hybrid schrieb:
Wobei ich nicht ganz verstehe: Ich denke das Problem liegt in der Bandbreitenbeschränkung? Genrell habe ich ja Telefoniefunktion in der Fritzbox, halt nur nicht auf 2 Leitungen gleichzeitig. Die sonstigen Störungen kann ich vielleicht mit den dort genannten Tipps ein wenig beschränken.

Das sind zwei verschiedene Themen.

Das eine Thema ist das mit der Bandbreite. Um die unnötige Bandbreitenreservierung seitens der Telekom zu verhinden kann man die Codecunterstützung (hier geht es nicht mal um die Nutzung, sondern nur um die Option der Nutzung) in der Fritz kastrieren. Das löst aber nur das Problem bei ausgehenden Anrufen.

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.

Gelöschter Nutzer · ‎16.05.2015

Ohoh @prodo_1 gleich kommt magenta Bruno

und schimpft wieder über Deine Wortwahl bezüglich des kaputten SIP-ALG

Bodo-Hybrid · ‎16.05.2015

@prodo_1

Danke für deine Ausführungen, war mir nicht bewusst, habe aber nun nen bissel im Forum hin und hergeklickt, und glaube nun es einigermaßen verstanden zu haben.

Und auch Danke für deine Energie, das alles weiter einzukreisen!!

Ist glaube ich harter Tobak immer wieder vor irgend eine Wand zu rennen. Respekt!

Ich für meinen Teil habe zur Zeit eine Funktionale Notlösung laufen, 2 Telefonnummern auf 3 Apparten (2 parralel geschaltet aus Not) am SP-H, Fritzbox als Router hinter SP-H, LTE Bonding funzt, VPN Fritzbox funzt, Fax auf Fritzbox funzt, Firewall Fritzbox funzt. Von daher geht alles, bis auf Telefonie über Fritzbox. Die klammere ich zur Zeit aus, in der Hoffnung auf nen baldiges Update sowohl Firmware als auch Netzrichtlinien der Telekom. Hauptsache es werden dann nicht andere Sachen weggeschossen.

Liest hier eigentlich die R&D der Telekom mit? Zu wünschen wäre es, wird doch einiges hier im Forum aufgedeckt, dass denen als Steilvorlage dienen könnte.

In diesem Sinne, nochmals Danke,

Gruß Bodo

Helge aus H. · ‎18.05.2015

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.

etSoftware · ‎18.05.2015

Darf ich fragen wie denn nun die Lösungsschritte der Telekom aussehen, oder muss ich mich mit einem "es geht wieder" begnügen ?

prodo_1 · ‎18.05.2015

@Helge aus H. schrieb:
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.

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.

Das hört sich doch positiv an. Schnell finde ich allerdings anders.

Ich bin auch neugierig wie die Lösung aussieht.

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.
Ist verstanden aber das Problem besteht ja nur mit dem SIP-ALG und nicht ohne. Insofern ist es zwar nicht erwünscht aber immerhin möglich (an euren VOIP Servern liegt es somit ja wohl nicht).

Alternativ bitte die Spezifikation eindeutig gestalten. Ein frühzeitiger Hinweis an alternative Hardwarehersteller wäre dann toll (und damit ist nicht nur AVM gemeint).

Tilman Schmidt · ‎18.05.2015

Hallo Helge R.,

@Helge aus H. schrieb:
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.

Das ist ja außerordentlich erfreulich. Vielen Dank für diese Nachricht.

Nach der in großer technischer Detailtiefe geführten Diskussion hier würde mich nun allerdings brennend interessieren, welche Lösung jetzt schlussendlich umgesetzt wurde. Ist es die von mir am ‎2015.04.30 14:45 als Lösung 3 skizzierte?

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 . . .

Hier scheint mir der Hase im Pfeffer zu liegen: die IP-basierten Anschlüsse der Telekom erfordern spezielle Anpassungen der daran betriebenen Geräte. Kompatibilität zu den allgemeinen Internet-Standards genügt nicht.

spi · ‎18.05.2015

Hallo Helge,

ich schließe mich der Bitte meiner Vorposter an, ein wenig Hintergrundinformation über die realisierte Lösung zu erhalten.

Grüße

spi

spi · ‎18.05.2015

@prodo_1 schrieb:
@Helge aus H. schrieb:
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.
Ist verstanden aber das Problem besteht ja nur mit dem SIP-ALG und nicht ohne. Insofern ist es zwar nicht erwünscht aber immerhin möglich (an euren VOIP Servern liegt es somit ja wohl nicht).

Alternativ bitte die Spezifikation eindeutig gestalten. Ein frühzeitiger Hinweis an alternative Hardwarehersteller wäre dann toll (und damit ist nicht nur AVM gemeint).

Hallo prodo,

es ist nicht nur ein Problem des SIP-ALGs.

Die Telekom-IMS-Plattform beantwortet die REGISTER fetch bindings der Clients, aber führt - so sieht es für mich jedenfalls aus - zur Verringerung der Last keine Abfrage der Registrierungen in der Datenbank aus, sondern beantwortet die Anfrage zum schnellstmöglichen Zeitpunkt mit der Information: es liegt keine Registrierung vor.

Eine andere Möglichkeit ist, dass aufgrund der Anfrage alle Registrierungen gelöscht werden und es deshalb zur Antwort "keine Registrierungen" kommt. Ich halte diese Variante aber für unwahrscheinlicher.

Aber egal, dieses Verhalten der SIP-Plattform an sich ist schon mehr als unschön und beinhaltet gewisse Problematiken.

Die Problematik, die beim SIP-ALG im SP-H wahrscheinlich zum Tragen kommt, ist, dass das SIP-ALG aufgrund der falschen Antwort des Telekom-SIP-Proxys die interne Registrierungstabelle bearbeitet und es zu weiteren Folgeproblemen kommt.

Grüße

spi

ivo.matheis · ‎18.05.2015

Hallo,

ich hab schnell einen Test gemacht. Der deckt den Anwendungsfall "zweites eingehendes Gespräch an einem DSL2000 Annex J von einer Fritzbox an einem DSL16000 mit Standard-Codecliste (also NICHT frisiert)" ab.

Und was soll ich sagen: Der Anruf war erfolgreich.

Sonst wurde der zweite eingehende Anruf ja direkt mit besetzt abgelehnt, ohne dass der DSL2000er überhaupt etwas mitbekommen hatte.

Die Fritzbox am DSL2000 kann ich auf die Schnelle nicht umbiegen. Da aber der eingehende Test tut, würde ich das auch für die ausgehenden zweiten Gespräche annehmen. @schraton, kannst du das mal prüfen? Soweit ich weiß, hast du ja eisern die Finger vom Telnet gelassen.

@Helge aus H., danke für's fixen. Bitte ein bisschen mehr Kontext, was jetzt tatsächlich verändert wurde.

@spi, man könnte das Anklopfthema sich nochmal anschauen.

Grüße, Ivo

spi · ‎18.05.2015

Hallo Ivo,

die Bandbreitenreservierung steht meiner Meinung nach nicht in Verbindung zu dem von mir festgestellten Anklopfproblem. Ich hatte auch schon den Codec-Patch in der FB ausprobiert.

Habe aber motiviert durch die AWS-Probleme der letzten Woche eine Korrelation zu AWS bei besetzt festgestellt.

Viele Grüße

spi

Helge aus H. · ‎19.05.2015

Hallo in die Runde,

hallo Tilman Schmidt,

@Tilman Schmidt schrieb:
Nach der in großer technischer Detailtiefe geführten Diskussion hier würde mich [...] brennend interessieren, welche Lösung jetzt schlussendlich umgesetzt wurde. Ist es die von mir am ‎2015.04.30 14:45 als Lösung 3 skizzierte?

jaaa, statt eines seltenen „worst case” wird nun ein „ common case” zugrunde gelegt . . .

Hier nochmals die Gedanken von Tilman Schmidt zu denkbaren Lösungsansätzen, die er am 30. April hier im Thread beigesteuert hatte:

Tilman Schmidt schrieb am 30. April 2015:
Unabhängig davon, ab man das als Bug oder als qualitätssichernde Maßnahme einstufen will, gibt es drei mögliche Lösungen:
AVM reduziert die Liste der unterstützten Codecs auf die von der Telekom unterstützten.
Nachteil: Die aus der Liste entfernten Codecs stehen nicht mehr zur Verfügung.
Die Telekom entfernt den Mechanismus, der eine zweite Verbindung aufgrund "voip-technischer Bandbreitenreservierung" ablehnt, komplett.
Nachteil: Unter bestimmten Umständen mag es zu Einbußen der Gesprächsqualität bei Verbindungen mit den Standardcodecs kommen. (Auch wenn ich es trotz einigen Nachdenkens nicht geschafft habe, ein konkretes Szenario dafür aufzustellen.)
Die Telekom senkt die fiktive Bandbreitenreservierung für unbekannte Codecs auf denselben Wert wie bei G.711.
Nachteil: Unter bestimmten Umständen mag es zu Einbußen der Gesprächsqualität bei Verbindungen mit nicht unterstützten Codecs kommen, die eine höhere Bandbreite beanspruchen als die unterstützen Standard-Codecs.
Die Lösung 3 erscheint mir als die kundenfreundlichste und vernünftigste.
Sie ist mit minimalem Aufwand zu realisieren - es muss nur ein Parameterwert geändert werden, der ohnehin willkürlich war und außerhalb des hier diskutierten Szenarios keinerlei Auswirkungen hat.
Sie löst das Problem vollständig und mit minimalen Einschränkungen für den Kunden.
Sie erhält der Telekom ihre qualitätssichernde Maßnahme, solange bei den Verbindungen tatsächlich nur unterstützte Codecs eingesetzt werden. Für nicht unterstützte Codecs hat die Telekom natürlich keine Qualitätsverpflichtung, daher sollte dies kein Problem darstellen.

An dieser Stelle möchte ich allen Usern, die sich hier im Thread aktiv an der Diskussion der technischen Hintergründe beteiligt haben, nochmals für Ihre insgesamt sehr konstruktive Kritik und Ihre von großer Sachkenntnis geprägten Beiträge danken.

Beste Grüße

von

Helge R.

etSoftware · ‎19.05.2015

Wahnsinn

Ein halbes Jahr um einen unglücklich gewählten Parameter zu korrigieren.

FritzBox Fehler 488 bei Voip 2te Leitung

Social Media