Bei ein paar Kunden gab es Schwierigkeiten, das diese nicht jeden Anrufen konnten. Die Kunden selbst konnten immer erreicht werden. Seltsam war dabei, des dies erst seit ca. drei Wochen der Fall war.

Auffällig war zudem, das alle betroffenen Kunden bei der Telekom sind, VoIP-Anschlüsse haben und die nicht erreichbaren Ziele bei anderen Provider liegen (aktuell bekannt ist Vodafone, Ecotel und NTTCable). Am Router sollte es nicht liegen, da zum einen unterschiedliche Modelle (z.B. FritzBox, pfSense, Securepoint, …) um Einsatz kommen und die Telefonanlagen sich direkt beim Provider registrieren (die Router machen nur die Interneteinwahl).

Kurios war zudem, das es bei einem Kunden nicht immer die gleichen Ziele waren, bei einem anderem wiederum hundertprozentig reproduzierbar immer die Gleichen, beim nächsten sogar nur wenn ein ISDN-Anschluss angerufen wurde.

“Eigentlich” sollte es solche Codec-Schwierigkeiten wohl nur zwischen VoIP-Endgeräten geben, meinte mal ein Telekom-Techniker, am Beispiel des ISDN-Ziels ist’s dann aber wohl doch eine Provider-Angelegenheit. Jetzt kann man vermutlich Haarspalterei betreiben, das schließlich der Übergabepunkt (media gateway) der VoIP auf ISDN wandelt dann quasi das Endgerät darstellt. Sei’s drum.

Jedenfalls wurde weder bei unseren Kunden noch bei den Angerufenen die letzte Zeit irgendetwas geändert. Die Suche nach der Ursache gestaltete sich zudem etwas schwierig, da in den Protokollen nichts vermerkt war und die Telekom-Technik (wir haben da im Laufe der vergangenen Tage mehrere Leute mit beschäftigt) jenseits der üblichen eigenen Tests kaum was getan hat. Eine Hotlinerin meinte sogar zu mir “wie soll man das nur finden”. Wenigstens hatte mich der letzte Hotliner auf die Codecs und mögliche Aushandlungsprobleme aufmerksam gemacht.

Einen SIP- und Network-Trace später hatte man folgendes sozusagen in der Hand:

SIP-Trace:
<--- SIP read from UDP:Ö-IP:5060 --->
SIP/2.0 500 Internal Server Error
Via: SIP/2.0/UDP 192.168.96.5:5060;received=Ö-IP;rport=5060;branch=z9hG4bK48dcd1e1
To: <sip:ZIELRUFNUMMER@tel.t-online.de>;tag=h7g4Esbg_p65543t1507200306m243398c1467152066s1_1792797809-1923613878
From: "QUELLRUFNUMMER" <sip:+49QUELLRUFNUMMER@tel.t-online.de>;tag=as0b893270
Call-ID: 06e56b9908bc690f1116f8561cc3b382@tel.t-online.de
CSeq: 103 INVITE
Contact: <sip:sgc_c@217.0.23.100;transport=udp>
Reason: Q.850;cause=111;text="5"
upported: timer
Content-Length: 0

Network-Trace:
Session Initiation Protocol (500)
 Status-Line: SIP/2.0 500 Internal Server Error
 Message Header
 Via: SIP/2.0/UDP 192.168.96.5:5060;received=Ö-IP;rport=5060;branch=z9hG4bK3aece4f3
 To: <sip:ZIELRUFNUMMER@tel.t-online.de>;tag=h7g4Esbg_p65543t1507662901m951489c1517655816s1_532037588-1736118698
 From: "QUELLRUFNUMMER" <sip:+49QUELLRUFNUMMER@tel.t-online.de>;tag=as1309e071
 Call-ID: 2530625568be80105b2098c105ffcb15@tel.t-online.de
 CSeq: 103 INVITE
 Contact: <sip:sgc_c@217.0.23.100;transport=udp>
 Reason: Q.850;cause=111;text="5"
 Reason protocols: Q.850
 Cause: Protocol error, unspecified (111)
 Text: 5
 Supported: timer
 Content-Length: 0

Der SIP-Fehler “500 Internal Server Error” ist erstmal relativ nichts sagend. Interessanter ist dann darunter

Reason: Q.850;cause=111;text="5"
Reason protocols: Q.850
Cause: Protocol error, unspecified (111)

Im SIP-Trace habe ich das irgendwie übersehen, erst im Wireshark fiel mir das so richtig auf. Danach im Netz gesucht stolpert man sofort über Schwierigkeiten beim Verbindungsaufbau, wenn die Aushandlung des Codecs scheitert.

Daraufhin die Reihenfolge der Codecs im Provider- als auch in den Geräte-Konten in der Askozia geändert (ein Telefonneustart ist übrigens nicht notwendig) und siehe da, es geht. Ob die Änderung weitere/andere Auswirkungen hat und ob alle Schwierigkeiten damit behoben sind, muss man noch sehen.

Die voreingestellte Reihenfolge bei Askozia ist:

G.711 u-law
G.711 A-law
GSM

u- und A-law tauschen und speichern.

An manchen Stellen im Netz liest man zudem das “G.711 u-law” komplett raus soll (unabhängig von Askozia, bezieht z.B. auf Asterisk im Allgemeinen oder auch Digitalisierungsboxen der Telekom und andere Telefonanlagen).

Nachfolgend ein paar (hoffentlich) hilfreiche Links:

Askozia Wiki – Help for integrators/de – SSH-Zugriff auf AskoziaPBX

Askozia Wiki – Help for integrators/de – Netzwerk-Tracing mit AskoziaPBX (weiter unten ist dann im Anschluss SIP-Trace beschrieben)

Askozia Wiki – Help for integrators – Audio Codecs

Telekom hilft Community – VOIP SIP 606 Fehler

Wikipedia – SIP-Status-Codes

Update 25.10.2017

Verspätet kam gestern noch eine Antwort vom Askozia-Support, man könne “u-law” auch ganz entfernen.

Andy

Verheiratet, Vater von zwei Kindern, eines an der Hand, eines im Herzen. Schon immer Technik-Freund, seit 2001 in der IT tätig und seit über 10 Jahren begeisterter Blogger. Mit meiner Firma IT-Service Weber kümmern wir uns um alle IT-Belange von gewerblichen Kunden und unterstützen zusätzlich sowohl Partner als auch Kollegen.