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  

Mich wundert, dass das IMS der Telekom nicht, wie üblich, nach dem Handshake-Verfahren, das Protokoll vorgibt! Dieses einfache bisher immer eingesetzte internationale Verfahren sichert Benutzer vor der kompletten Inkompatibilität mit dem Service?

 

Wenn bei der Telekom die Bandbreiten bis DSL 6000 nicht ausreichen für 2 'Leitungen', dann ist nach meinem Verständnis der Vertrag mit dem Kunden ungültig, da VoIP nicht die Leistung eines ISDN-Vertrages bietet, der vom Kunden gefordert wurde!

 

Liebe Telekom, was möchtet Ihr; eine Sammelklage, da Vertragsgegenstände nicht bereitgestellt werden können oder eine Lösung?

 

Ich darf auch darauf hinweisen, das ein ungesicherter, bzw. unverschlüsselter VoIP-Telefonanschluß gegen das GG Artikel 10 verstößt, da dieser jederzeit durch eine leicht zugängliche Software von jeder Person mit Internetverbindung abgehört werden kann!

 

Mein aktueller Fall ist Telekomanschluß, der vor Ostern unproblematisch mit einer Fritzbox 7270v3 mit VoIP funktionierte, dummerweise hat der Kunde telefonisch einem Update auf VDSL zugestimmt, wobei der Telekom Mitarbeiter behauptete, dass das mit der Fb 7270 funktioniert. Danach ging kein DSL mit der aktuellsten Firmware. Diese Fritzbox kann aber auch VDSL!

 

Nach einem Widerruf wurde angeblich alles wieder hergestellt, aber es funktioniert nur die Internetverbindung und Anrufe von T-Com Kunden und Handys. Telefonieren nach außen funktioniert nicht mit dem Hinweis auf Fehler 488.

Es gibt also noch mehr Probleme, als nur eine Telefonverbindung! Wie Microsoft, interpretiert die Telekom die internationalen Vereinbarungen!

 

Ach ja, die Hotlinemitarbeiterin hat sich nach meinem halbstündigen Warten, dazu entschlossen, aufzulegen, als ich mitteilte IT-Systemtechniker zu sein.

 

Schöne Grüße

tom_k

Hallo,

bin neu hier, habe aber auch seit Monaten das gleiche Problem, was vor allem wg. callthrough sehr ärgerlich ist. Aussage vom Telekom-Service wie bei den anderen auch: die Leitung ist in Ordnung, mehr müssen sie nicht tun. Falls ich auf Annex-J / -B wechseln möchte, könne er mich mit dem Vertrieb verbinden...

Meine Frage in die Runde: wie sieht das mit Kürzung der Rechnungen an Telekom aus?! Ich bin 10/2014 von ISDN/DSL auf VoIP gewechselt und war davon ausgegangen, daß ich 2 Gespräche gleichzeitig führen kann. Gleichzeitig habe ich meinen Speedport eingemottet und gegen eine Fritzbox 7490 getauscht, die ich nicht mehr missen möchte. Vielleicht bewegt sich ja bei der Telekom mal was, wenn es ans Geld geht. Oder kann man vom Vertrag zurücktreten bzw. vorzeitig kündigen?!

Ich werde auch gleichzeitig bei AVM versuchen, Druck zu machen. Vielleicht hilft es ja was.

 

Hallo stromsholm,

 

ich zahle seit vier Monaten nur 10 €, habe vorher als Ankündigung ein Schreiben an Bonn geschickt und darauf hingewiesen. Haben gestern eine dicke Gutschrift erhalten und zzt ist unser Konto ausgeglichen, aber ob es hilft und der Fehler abgestellt wird bezweifel ich, es müssten mehre diesen Weg gehn, dann evtl....

gruss

ws

Hallo liebes "Telekom Hilft"-Team,

 

während in den vergangenen Wochen immer mal wieder recht optimistische Beiträge von Ihnen zu lesen waren, ist es nun verdächtig ruhig geworden. Das Thema selbst ist aber doch nicht gelöst, oder?

 

Klaus

Hallo ilion,

zu Deinem Beitrag Nr. 134:

Du bist der Beste - vielen Dank für Deine Hilfe - nach zusammengerechneten  2 vollen Tagen Quälerei hat mir Dein Tipp geholfen.

Kurz meine Geschichte dazu:

- Telefonverkäufer der Telekom bietet mir an auf IP-Telefonie umzusteigen; hat mir versprochen, daß ich mit der Fritzbox 7490 mit 2 Leitungen gleichzeitig telefonieren kann; hat auch meine Leitung dazu getestet - Geschwindigkeit ist mehr als ausreichend. - Ich stimme zu.

- Als mein Anschluss dann umgestellt wurde kam ich nur mit einem Gespräch raus. (Annex-J - 2300/543). Dann begann die Odysee über ca. 1 Woche. AVM war über die Hotline telefonisch nicht zu erreichen, aber per Email wurde zügig geantwortet - nur hat es nichts gebracht und die Verantwortung wurde der Telekom zugeschoben. Die Hotline der Telekom war hilfsbereit, aber oft auch widersprüchlich und weitergekommen bin ich auch nicht. Zwei Techniker waren inzwischen auch vor Ort  -  die Leitung war in Ordnung. Nach dem Durchlesen von etlichen Forumsbeiträgen und dem Ausprobieren von gefühlten 100 Variationen in Verbindung mit einem Speedport 723 bin ich auf diesen Beitrag gestossen und hätte, wenn dieser nicht geklappt hätte, aufgegeben.

Was mich außerordenlich nerft: Über ein viertel Jahr wissen die Netzwerktechniker von AVM und der Telekom an was es liegt und es wird nichts gemacht um den Leuten zu helfen. Das hätte es noch vor 10 Jahren weder bei der Telekom noch bei AVM gegeben - wo sind wir hingekommen.

Danke für Deine Zeit ilion,

Danke, danke, danke

Viele Grüße

 

Rückmeldung zu meinem Fall; Telefonanschluß VoIP (eine Leitung) funktioniert seit dem 23.4.2015 wieder.

 

Hatte zum Glück am nächsten Tag einen Hotline-Mitarbeiter, der mir zugehört hat.

 

In diesem Fall waren mehrere Leitungen falsch verschaltet, vor Ort kam DSL mit 1180 kbit/s an, also Internet funktionierte, aber Upload nur bei 160 kbit/s, also zu langsam für die IMS von Infinion, die wollen die volle Bandbreite von 250 kbit/s für VoIP (eine Leitung), wenn mehr als die zwei bekannten Protokolle übermittelt werden.

Kein Handshake, wie international üblich, also Problem der Siemenstochter Infinion!

 

Ich hätte jetzt als Großunternehmen meinem Lieferanten die Pistole auf die Brust gesetzt; Problem in angemessener Frist beheben, meinen zusätzlichen Aufwand in Rechnung stellen!

 

Ist halt doch immer noch ein Staatsunternehmen bei dem ich ausgebildet wurde, aber ich habe dazugelernt.

 

Gruß

tom_k

Hallo an alle:

das Problem ist gelöst: nachdem ich zunächst von der Hotline die Aussage bekam, ich müsse mich wg. Annex-J / Annex-B mit dem Vertrieb in der Verbindung setzen (was ich nicht getan habe), kam 2 Tage später eine Mitteilung per (richtiger) Post, daß mein Anschluß von DSL RAM 6000 in DSL RAM 6000 IP geändert würde (ich hatte aber seit Oktober 2014 schon VoIP - dachte ich). Dazu der Hinweis zu den ev. eingeschränkten Bandbreiten (... bis zu).

Nochmal ein oder 2 Tage später wurde tagsüber der Internetzugang kurz unterbrochen, seitdem steht als Bandbreite im download 8.191 kbit/s und im upload 2.576 kbit/s (!) zur Verfügung (ADSL 2+ (ITU G.992.5) Annex J.  Damit kann ich zwei Gespräche gleichzeitig führen; damit läuft dann auch der callthrough.

Auch wenn es etwas holperig war, möchte ich mich dennoch bei der Telekom bedanken - schlußendlich wurde das Problem vglw. einfach und schnell behoben. Man soll ja nicht immer nur schreiben, wenn etwas NICHT klappt. Ich hoffe, daß allen anderen Betroffenen ähnlich zügig geholfen wird.

Beste Grüße

stromsholm

Hallo stromsholm,

schön dass sich die Sache für dich erledigt hat. Das dürfte aber nur für dich gelten, weil deine nun höheren Leitungskapazitäten ein anderes Profil bei der Bandbreitenreservierung mit sich bringen.

Das eigentliche, hier diskutierte Problem ist m.E. noch nicht gelöst.

 

Gruß schusch

iuk-service schrieb:
Mich wundert, dass das IMS der Telekom nicht, wie üblich, nach dem Handshake-Verfahren, das Protokoll vorgibt! Dieses einfache bisher immer eingesetzte internationale Verfahren sichert Benutzer vor der kompletten Inkompatibilität mit dem Service?

Hast du dir mal genau angeschaut was auf der FritzBox im SIP gespielt wird? Offensichtlich nicht, sonst würdest du das nicht schreiben.


iuk-service schrieb:
Liebe Telekom, was möchtet Ihr; eine Sammelklage, da Vertragsgegenstände nicht bereitgestellt werden können oder eine Lösung?

Willst du auswandern? In den USA gibt es das.
http://de.wikipedia.org/wiki/Sammelklage


iuk-service schrieb:
Ich darf auch darauf hinweisen, das ein ungesicherter, bzw. unverschlüsselter VoIP-Telefonanschluß gegen das GG Artikel 10 verstößt, da dieser jederzeit durch eine leicht zugängliche Software von jeder Person mit Internetverbindung abgehört werden kann!

Bleibt nur zu hoffen, dass hier nicht die BNA mitliest, sonst haben wir morgen alle keinen Anbieter mehr.  Bin mal gespannt,  was da bundesweit an Anbietern übrig bleibt. Glaubst du wirklich dass die BNA nicht weiß wie Vodafone, Versatel, Telefonica, Telekom, etc. bei VoIP die Sprache übertragen?


iuk-service schrieb:
Mein aktueller Fall ist Telekomanschluß, der vor Ostern unproblematisch mit einer Fritzbox 7270v3 mit VoIP funktionierte, dummerweise hat der Kunde telefonisch einem Update auf VDSL zugestimmt, wobei der Telekom Mitarbeiter behauptete, dass das mit der Fb 7270 funktioniert. Danach ging kein DSL mit der aktuellsten Firmware. Diese Fritzbox kann aber auch VDSL!

Ja die 7270 kann aber auch so was von VSDL.... Wo hast du das her?
http://www.router-faq.de/index.php?id=fbinfo&hwf=fbfonwlan7270v3#fbfonwlan7270v3

Oder war das am Ende nur ironisch gemeint?


iuk-service schrieb:
Nach einem Widerruf wurde angeblich alles wieder hergestellt, aber es funktioniert nur die Internetverbindung und Anrufe von T-Com Kunden und Handys. Telefonieren nach außen funktioniert nicht mit dem Hinweis auf Fehler 488. Es gibt also noch mehr Probleme, als nur eine Telefonverbindung! Wie Microsoft, interpretiert die Telekom die internationalen Vereinbarungen!

Ach was?  Nicht jede 488 hat die gleiche Ursache. Was hat das mit Interpretation zu tun?


iuk-service schrieb:
Hatte zum Glück am nächsten Tag einen Hotline-Mitarbeiter, der mir zugehört hat.
In diesem Fall waren mehrere Leitungen falsch verschaltet, vor Ort kam DSL mit 1180 kbit/s an, also Internet funktionierte, aber Upload nur bei 160 kbit/s, also zu langsam für die IMS von Infinion, die wollen die volle Bandbreite von 250 kbit/s für VoIP (eine Leitung), wenn mehr als die zwei bekannten Protokolle übermittelt werden.
Kein Handshake, wie international üblich, also Problem der Siemenstochter Infinion!

Nur weil der DSLAM, den du in der FritzBox sehen kannst, von Infinion ist, trifft das noch lange nicht für die IMS zu.


iuk-service schrieb:
Ich hätte jetzt als Großunternehmen meinem Lieferanten die Pistole auf die Brust gesetzt; Problem in angemessener Frist beheben, meinen zusätzlichen Aufwand in Rechnung stellen!

Glaubst du allen Ernstes, dass irgend eine Firma auf der Welt von dir diesen Rat braucht? Du sitzt hier nicht an einem Stammtisch.


iuk-service schrieb:
- Ach ja, die Hotlinemitarbeiterin hat sich nach meinem halbstündigen Warten, dazu entschlossen, aufzulegen, als ich mitteilte IT-Systemtechniker zu sein.

- Ist halt doch immer noch ein Staatsunternehmen bei dem ich ausgebildet wurde, aber ich habe dazugelernt.

Was machen die jetzt nur ohne dich. Der Hotlinemitarbeiterin ist wohl nach einer halben Stunde Angst geworden sie müsse dir das alles nochmal erklären. Da hätte ich auch aufgelegt.

Würde mich interessieren was genau du dazugelernt hast. Wie VoIP und ein IP-Anschluss funktioniert war da sicher nicht dabei.

Gruß schusch



@iuk-service schrieb:
Ich darf auch darauf hinweisen, das ein ungesicherter, bzw. unverschlüsselter VoIP-Telefonanschluß gegen das GG Artikel 10 verstößt, da dieser jederzeit durch eine leicht zugängliche Software von jeder Person mit Internetverbindung abgehört werden kann!

Solche wahrheitswidrigen Zuspitzungen sollte man vermeiden. Sie gehen in der Regel nach hinten los.

 

Natürlich können unverschlüsselte SIP-Verbindungen relativ leicht abgehört werden, aber nicht von "jeder Person mit Internetverbindung". Im IP-Routing-Weg muss der/die Abhörende schon sein.


@Johannes S. schrieb:
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.

Unabhängig davon, ab man das als Bug oder als qualitätssichernde Maßnahme einstufen will, gibt es drei mögliche Lösungen:

  1. 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.
  2. 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.)
  3. 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.

Lieber Johannes S., wäre das machbar?

Tja, es sieht so aus, als wenn dieser Thread von Seiten der Telekom nicht mehr verfolgt wird. Während mehrfach von baldigen Lösungen die Rede war und über Wochen scheibchenweise technische Informationen zusammen mit den Kunden ermittelt worden sind, ist jetzt Funkstille.

 

Da ich optimistisch bin, gehe ich davon aus, dass AVM und die Telekom zusammen gerade die ultimative Lösung erarbeiten und diese in der kommenden Nacht auf dem Besen reitend aktiviert wird. Vielleicht müssen wir aber doch noch bis Pfingsten warten, damit der Heilige Geist die Einsicht bringt.

 

Mich wundert lediglich, dass die einschlägige Fachpresse wie Heise und Vogel das Thema noch nicht aufgegriffen haben. Es würde sich zumindest gut als Schlagzeile eignen gerade in Zusammenhang mit ihren Artikeln zur Umstellung auf IP-Telefonie und Optimierung von Fritzboxen.

 

So, nun muss ich aber den Besen abstauben gehen für den Tanz/Ritt in den Mai ....

 

Klaus


@Tilman Schmidt schrieb:

Unabhängig davon, ab man das als Bug oder als qualitätssichernde Maßnahme einstufen will, gibt es drei mögliche Lösungen:

  1. 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.
  2. 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.)
  3. 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.

Hallo Tilman,

zu 1.)

Nicht nur die FRITZ!Boxen von AVM sind davon betroffen, sondern alle anderen Geräte, deren Codec-Listen über G.711 und G.722 hinausgehen. Warum sollen Millionen von Kunden an ihren diversen Geräten/Soft Clients an Codeclisten herumkonfigurieren (wenn das überhaupt möglich ist), nur weil Verantwortliche bei der Telekom uneinsichtig und unkooperativ sind?

Außerdem: warum soll die eingeschränkte Codec-Unterstützung der Medien-Gateways der Telekom die Codecs von reinrassigen VoIP-Verbindungen einschränken?

 

zu 2.)

Sofortiges, temporäres Abschalten (Ericsson wird das sicherlich konfigurierbar gemacht haben) würde ausreichen. In Ruhe könnte Ericsson seine Implementierung nachbessern.

 

zu 3.)

Der Bandbreitenbedarf von dem Dutzend Codecs, das da vielleicht zusammenkommt, kann man einfach und schnell einbringen. Der Aufwand ist doch nicht der Rede wert.

 

 

@all:

Es sollte sich jeder mal die Frage stellen, warum die Telekom solche "qualitätsverbesssernden" Mechanismen/Maßnahmen für notwendig hält (insbesondere diejenigen, die hier und woanders gebetsmühlenartig preisen, dass VoIP Fortschritt gegenüber Circuit Switched bedeuten soll).

 

Grüße

spi

 

PS: die Software dieser Foren-/Social-Media-Plattform ist auch nur ein einziger Rückschritt!

Hallo spi,

wir sind uns ja im Prinzip einig.


@spi schrieb:

zu 2.) ["voip-technische Bandbreitenreservierung" komplett entfernen]

Sofortiges, temporäres Abschalten (Ericsson wird das sicherlich konfigurierbar gemacht haben) würde ausreichen. In Ruhe könnte Ericsson seine Implementierung nachbessern.


Ich bezweifle, dass das so einfach geht. Vor allem wird das die Telekom aber nicht wollen.


zu 3.) [fiktive Bandbreitenreservierung für unbekannte Codecs wie G.711]

Der Bandbreitenbedarf von dem Dutzend Codecs, das da vielleicht zusammenkommt, kann man einfach und schnell einbringen. Der Aufwand ist doch nicht der Rede wert.


Das ist für den Hersteller ein Fass ohne Boden. Morgen kann wieder ein neuer Codec dazukommen. Es wird immer einen "else-Zweig" für unbekannte Codecs geben müssen. Da das Dutzend Bandbreitenwerte durch Test und Qualitätssicherung müssen, ist der Aufwand auch nicht ganz so vernachlässigbar. Andererseits ist die von mir skizzierte Minimallösung ja völlig ausreichend.


PS: die Software dieser Foren-/Social-Media-Plattform ist auch nur ein einziger Rückschritt!


Ganz deiner Meinung.


@Tilman Schmidt schrieb:
[...]

zu 3.) [fiktive Bandbreitenreservierung für unbekannte Codecs wie G.711]

Der Bandbreitenbedarf von dem Dutzend Codecs, das da vielleicht zusammenkommt, kann man einfach und schnell einbringen. Der Aufwand ist doch nicht der Rede wert.


Das ist für den Hersteller ein Fass ohne Boden. Morgen kann wieder ein neuer Codec dazukommen. Es wird immer einen "else-Zweig" für unbekannte Codecs geben müssen. Da das Dutzend Bandbreitenwerte durch Test und Qualitätssicherung müssen, ist der Aufwand auch nicht ganz so vernachlässigbar. Andererseits ist die von mir skizzierte Minimallösung ja völlig ausreichend.


Der else Zweig scheint aber so schrottig oder nennen wir es mal "konservativ" eingestellt zu sein, dass es selbst bei vermeintlich ausreichendem Upload von 500k- zumindest für einen Außenstehenden - nicht nachvollziehbar ist, was sich die Qualitätsicherung hier zusammenrechnet oder für Grenzwerte anlegt.

 

Das Traurige ist ja, dass von diesem Mechanismus nichts dokumentiert ist. Und was die Telekom hier im Thread bisher dazu beigetragen hat, ist mehr als dürftig.

 

Und die lange Zeit ohne Lösung - es ist Mai - ist einfach nur beschämend. Ich will nicht wissen, wie hoch die Dunkelziffer der User ist, die denken, dass das alles normal ist, dass 2 Gespräche nicht gehen. Grade wenn man aus der Analogwelt kommt.

 


PS: die Software dieser Foren-/Social-Media-Plattform ist auch nur ein einziger Rückschritt!

Ganz deiner Meinung.


Ein Riesenklump ist die. Fröhlich

 

Grüße, Ivo

 

 

 

[edit: ein Halbsatz bei der Bandbreite hat gefehlt]


@ivo.matheis schrieb:

@Tilman Schmidt schrieb:

[zu 3. fiktive Bandbreitenreservierung für unbekannte Codecs wie G.711]

Es wird immer einen "else-Zweig" für unbekannte Codecs geben müssen. [...] Andererseits ist die von mir skizzierte Minimallösung ja völlig ausreichend.


Der else Zweig scheint aber so schrottig oder nennen wir es mal "konservativ" eingestellt zu sein, dass es selbst bei vermeintlich ausreichendem Upload von 500k- zumindest für einen Außenstehenden - nicht nachvollziehbar ist, was sich die Qualitätsicherung hier zusammenrechnet oder für Grenzwerte anlegt.


Das hat @Helge aus H. ja in seinem Beitrag vom 31.03.2015 10:03 schon für Telekom-Verhältnisse erstaunlich klar beschrieben, und @bankrobbery hat es am 02.04.2015 11:18 noch einmal schön zusammengefasst:

Wenn der Telekom-Server [IMS] irgendeinen der vom SIP-Client [Router] angebotenen Codecs nicht kennt, reserviert er für die Verbindung so viel Bandbreite, dass auch die datenhungrigsten offiziell spezifizierten Codec-Varianten damit auskommen würden.

Das ist ja genau der Ansatzpunkt der von mir favorisierten Lösung: diesen fiktiven Bandbreitenwert für unbekannte Codecs ("else-Zweig") von theoretisches Maximum auf Standardwert normaler Sprachverbindungen zu ändern.


@Tilman Schmidt schrieb:

Das hat @Helge aus H. ja in seinem Beitrag vom 31.03.2015 10:03 schon für Telekom-Verhältnisse erstaunlich klar beschrieben, und @bankrobbery hat es am 02.04.2015 11:18 noch einmal schön zusammengefasst:

Wenn der Telekom-Server [IMS] irgendeinen der vom SIP-Client [Router] angebotenen Codecs nicht kennt, reserviert er für die Verbindung so viel Bandbreite, dass auch die datenhungrigsten offiziell spezifizierten Codec-Varianten damit auskommen würden.

Das ist ja genau der Ansatzpunkt der von mir favorisierten Lösung: diesen fiktiven Bandbreitenwert für unbekannte Codecs ("else-Zweig") von theoretisches Maximum auf Standardwert normaler Sprachverbindungen zu ändern.


Was sind denn die "datenhungrigsten, offiziell spezifizierten Codecs"? Ich bin kein Codecexperte und lass mich da gerne aufklären, aber ich hab keinen Codec gefunden, der für eine Richtung mehr als 128kBit/s benötigt. Und 2*128kBit/s sind immer noch weit unter allem, was die Telekom beim IP-Anschluss an Upstream schaltet. Nehmen wir mal an, es seien, sehr tief gegriffen, 378kBit/s. Dann gibt's hier nichst zu begrenzen, weil es immer noch ausreicht. 

 

Ivo

 

Nach den Berichten hier, bei welchen Upload-Bandbreiten das Problem auftritt, scheint der Wert, den die Telekom da ansetzt, in der Gegend von 256 kBit/s zu liegen. Zu spekulieren, welcher Codec diese Bandbreite verlangen könnte, ist müßig. Selbst wenn wir einen finden sollten, bringt das die Diskussion nicht weiter. Die Entscheidung, für unbekannte Codecs diesen Wert in Ansatz zu bringen, ist so oder so willkürlich.

Hallo Tilman Schmidt,

 

und zunächst ein Sorry, dass ich nach 1. Mai und Walpurgisnacht erst heute zurückmelde (ich glaube, ilion habe ich auch irgendwo mit seinem Besen vorbeiflitzen gesehen ...)

 

Aus Ihren drei Lösungsansätzen spricht für mich der Wunsch, unsere Diskussion zu versachlichen, um zu einer baldigen Lösung zu kommen. Den Verzicht auf eine Bandbreitenreservierung (Punkt 2) schließe ich aus, da er für alle Gespräche gelten würde. Also nur nicht für den zweiten Anruf. Da hat bestimmt die Qualität Vorrang vor der Quantität. Der Punkt 1 richtet sich in erster Linie an den Hersteller, wobei es hier ja ohne weiteres möglich wäre, das Verhalten der FRITZ!Box an den IP-basierten Anschluss der Telekom anzupassen. Bleibt also Punkt 3: Was wir von unserer Seite tun können, werden wir bestimmt machen.

Die Frage ist natürlich, wie und wann es jetzt weitergeht. Ich kann sehr gut verstehen, dass Sie dies wissen wollen. Und das geht uns bestimmt genauso. @HELGE R. hatte in der vergangenen Woche nochmals intern angefragt, leider bislang ohne Antwort. Wir fassen deshalb nach und werden Sie hier informieren.

 

Viele Grüße
Johannes S.

Johannes schreibt:
Den Verzicht auf eine Bandbreitenreservierung (Punkt 2) schließe ich aus, da er für alle Gespräche gelten würde. Also nur nicht für den zweiten Anruf. Da hat bestimmt die Qualität Vorrang vor der Quantität.
---------------------------------------------------------------------------------------------------------------------------------------------------------

Das hab ich jetzt nicht verstanden. Quantität = Zwei ?

Die weiter gehenden Optionen:

  •  Rechnungsbetrag mindern - für diejenigen, die abwarten wollen, ob und wann noch etwas passiert,
  • vom Vertrag wegen Nichterfüllung zurücktreten und zu einem anderen Anbieter wechseln - für diejenigen, denen die Hutschnur platzt.
Grüße
spi

Hallo Johannes S.,

 

vielen Dank für die vielversprechende Antwort.

 

Zu Lösungsansatz 1 möchte ich das "ohne weiteres" etwas relativieren. Die generelle Entfernung der von der Telekom nicht unterstützten Codecs bedeutet ja aus Sicht der Hersteller eine funktionale Einschränkung ihrer Produkte beim Betrieb in Nicht-Telekom-Netzen, und die Alternative, diese Codecs nur beim Betrieb am Telekom-Netz in der Aushandlungsliste zu unterdrücken, wäre nicht ganz unaufwendig. "Schön ist anders."

 

Dass die Telekom Lösungsansatz 2 nicht favorisiert, war mir schon klar. Trotzdem würde mich die Antwort auf die bereits angedeutete Frage interessieren, in welchem Szenario diese Maßnahme eigentlich qualitätssichernd greift.

 

Hoffen wir, dass sich die maßgeblichen Stellen möglichst schnell mit Lösungsansatz 3 anfreunden.

 

Viele Grüße,

Tilman

Da die Telekom mit Infinion (Siemens), ein  Unternehmen unterstützt, dass ein Handshakeverfahren als unsinnig erklärt, und dann scheinen einseitig, die Beteiligten der Telekom dieses Problem zu begünstigen.

 

Bekannt ist, das Infinion nur ein IMS liefert, welches nicht die vereinbarten internationalen Profile im Handshake-Verfahren für VoIP ausgeliefert hat. Warum setzt die Telekom diese ein, und warum stellt sich die Telekom bei Problemen dazu auf 'stumm'?

 

In diesem Problem verlieren beide, weil Sie nicht verstehen, was Sie gerade machen!

 

Schöne Grüße

Tom_K

Hallo zusammen,

 

Ericsson ist der Telekom-Lieferant für die IMS-Plattform. Infineon ist ein Halbleiterhersteller, der 1999 von Siemens abgespalten wurde und an dem Siemens seit 2006 auch keine Anteile mehr hält.

 

Das von der Telekom verfolgte Interesse ist die Abschaffung der Netzneutralität; bezogen auf VoIP werden Telekom-VoIP-Verbindungen offenbar seit etwa einem halben Jahr priorisiert und mit reservierter Bandbreite im Telekom-Core-Netz transportiert, während für alle anderen VoIP-Verbindungen das Best-effort-Prinzip gilt.

 

Warum die Telekom für die "unerwünschten" Codecs eine höhere (den bisher hier beteiligten Telekom-Mitarbeitern unbekannte) Bandbreite reserviert und nicht stattdessen auf die Bandbreitenreservierung verzichtet und wie jahrzehntelang praktiziert auf Best-effort zurückfällt, bleibt für mich weiterhin eine offene Frage.

 

"Leider" haben sich die Strategen der Telekom einen eklatanten Fehler in der Leistungsbeschreibung zu ihren All-IP-Produkten geleistet: Unter Punkt 4.1 Telefonverbindungen werden 2 Sprachkanäle zugesichert. Die allseits bei der Telekom beliebte "bis zu" Einschränkung wurde vergessen. Das ist ein guter Ansatzpunkt für die betroffenen Kunden.

 

Grüße

spi

Hallo spi,

die Erklärung ist plausibel, aber im Sinne von Hanlon's Razor hoffe ich trotzdem, dass sie nicht zutrifft.Zwinkernd

Grüße, Tilman