Asterisk und Telekom ALL-IP Anschluss – das Problem mit alaw

Es ist wieder einmal so eine Erfahrung in der praktischen Informatik, die man eigentlich nicht hätte machen brauchen. Bei einem Telekomanschluss (ALL-IP über sip.t-online.de) kann man z. B. beim Anrufen der Rufnummer 06206 1808-130 (das ist Fax-Rufnummer des Amtsgerichts Lampertheim) plötzlich vor dem Problem stehen, daß der Telekom-Server brüsk die Meinung

SIP/2.0 500 Server Internal Error

vertritt. Das macht im ersten Moment erst einmal sprachlos. Die SIP-Registrierung des Anschlusses bei der Telekom zuvor klappte ohne Probleme. Das Anwählen von vielen anderen Rufnummern macht auch keine Probleme.

Eine Störungsmeldung, mehrere Telefonate mit der Hotline und vier Tage später kann man dann die Information erhalten, daß es sich hierbei um ein Codec-Präferenzproblem handelt. Konkret ist derzeit die oben genannte Rufnummer vom Carrier “Versatel” betrieben. Lt. Aussage der Technik kommt es offenbar zu einer vorzeitigen “BYE”-Antwort, falls der Codec von der Telekom aus nicht mit den Präferenzen von Versatel in Einklang zu bringen ist. Zur Lösung des Problems möge man doch bitte pcmu (a.k.a. ulaw) präferieren (was sich nachher als den falschen Ansatz herausstellen wird). Anders herum betrachtet, kann man daraus schließen, daß das Telekom-Netzwerk wiederum offenbar auf einen solchen Codec-Fehler nicht vorbereitet ist und deshalb die nichtssagende Fehlermeldung “500 Server internal error” antwortet — was den geneigten Konsumenten rätselnd zurückläßt (eine konsumentenorientierte Fehlerbehandlung ist etwas anderes).

Einige Spielereien bringen dann interessante Erkenntnisse ans Tageslicht:

  • Bei der Selektion “disallow=all”, “allow=alaw”, “allow=ulaw” und “allow=g726” (man beachte jeweils auch immer die Reihenfolge), wählt Telekom “alaw” aus. Es kommt aber immer noch zum 500er Fehler.
  • Bei der Selektion “disallow=all”, “disallow=alaw”, “allow=ulaw” und “allow=g726” wählt Telekom “g726” aus (was für Fax-Verbindungen besonders nachteilig ist). Auch hier wird der Verbindungsaufbau mit dem 500er Fehler quittiert.
  • Bei der Selektion “disallow=all”, “disallow=alaw”, “disallow=g726” und “allow=ulaw” wählt Telekom wohl offenbar notgedrungen “ulaw” aus. Auch hier wird der Verbindungsaufbau mit dem 500er Fehler quittiert.
  • Wählt man allerdings “disallow=all”, “disallow=ulaw”, “disallow=g726” und “allow=alaw” aus, dann muss die Telekom auch wieder notgedrungen “alaw” auswählen. Zur großen Überraschung kommt jetzt aber mit der Rufnummer beim Carrier Versatel eine stabile Verbindung zustande!

Es wirkt daher so, als ob die Telekom zwar “ulaw” nicht mag (und sich für ihren eigenen Arm sehr schnell für “alaw” entscheidet), die Präferenzenliste des Anrufers allerdings nach wie vor zum Carrier weiterleitet. Letzterer scheint aber “ulaw” zu präferieren und selektiert diesen. Das Netzwerk scheint aber auf den Fall “Telekom will alaw, der andere Carrier aber ulaw” nicht richtig vorbereitet zu sein (es sei darauf hingewiesen, daß eine just-in-time-Übersetzung zwischen diesen beiden Codecs verlustfrei möglich ist; zu Performanceaspekten siehe auch diesen Beitrag). Durch das Erzwingen einer Codec-Liste, die ulaw komplett ausschließt und auch sonst keine Alternativen mehr für den Carrier anbietet, etwas anderes zu verwenden, müssen sich sowohl Telekom als auch Versatel auf den “alaw”-Codec einigen — was dann zum überraschenden Erfolg führt. Warum “nur ulaw” allerdings nicht zum Erfolg führt (alaw und ulaw unterscheiden sich nur marginal – insbesondere jedoch nicht in der verwendeten Übertrags- und Netzwerkbandbreite), bleibt für den geneigten Konsumenten ein Rätsel.

Noch eine kleine Anekdote zum Abschluß: Der Anruf zum gleichen Zielanschluss funktioniert bei einem anderen VOIP-Provider (DUS.NET) mit aktiviertem T.38 (Achtung! Auch bei diesem Protokoll kommt zunächst immer erst einmal eine normale Audio-Trägerverbindung mit Codec zustande!) mit allen “alaw”- oder “ulaw”-Codecpräferenzen. Honni soit qui mal y pense.

Referenzen:

VN:F [1.9.22_1171]
Rating: 0.0/5 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Leave a Reply

Your email address will not be published. Required fields are marked *

*