Cisco 8811 | SIP mit Telekom

Cisco 8811 Telefone lagen zuletzt im Schrott. Da meine TK-Anlage zickte dachte ich mir, dass es vielleicht möglich wäre, auf die Telefone eine Custom Firmware zu spielen, damit diese dann entweder mit der Telekom oder bspw. Asterisk sprechen kann.

Nach einer kurzen Recherche gibt es hierfür für dieses Modell zwei Möglichkeiten. Installiert war die "Enterprise Firmware" (CUCM), welche zur "Multiplatform Firmware" (kurz MPP, Produktkürzel 3PCC) geflasht werden kann, um an die Webex Cloud oder 3rd Party Telefonanlagen angebunden werden zu können. Alternativ gibt's noch die SIP Firmware mit stark eingeschränktem Funktionsumfrag, wodurch das Telefon an 3rd Party Telefonanlagen angebunden werden kann (ohne Lizenz, wie sich rausstellt).

Wechsel von Enterprise zu MPP

Wie sich rausstellte ist für die Migration von der Enterprise zur MPP Firmware eine Migration License notwendig. Diese kann bei diesem Modell kostenlos generiert werden, dazu muss das Telefon aber zuerst in der Webex Cloud registriert werden, wozu ein entsprechender Cisco Account notwendig ist (welchen ich nicht habe...). Da ein Arbeitskollege anbat, die Lizenzen zu generieren, letztlich aber nicht klar war, ob das so einfach ginge hatte ich nach dem Umflashen nun leider wieder ein (für mich) unbrauchbares Gerät rumliegen.

Ein anderer Arbeitskollege hatte schließlich auch nochmals recherchiert und meinte, die SIP Firmware sollte hier auch funktionieren und diese brauche auch keine Migration License.

Die SIP Firmware benötigt keine Lizenz und kann mit einem Cisco Account runtergeladen werden. So anfangs die Theorie, da ich trotz Account und Angabe der geforderten Daten weiterhin die Firmware nicht runterladen konnte. Nach ein paar Stunden funktionierte dies endlich - offenbar sind die Cisco Server nicht die schnellsten.

Wechsel von MPP ohne Lizenz zu SIP

Naiv dachte ich, ich flashe einfach wie von Enterprise zu MPP mittels XML zur SIP Firmware. TFTPD64 gestartet, XML und SIP Firmware ins Verzeichnis gepackt, Telefon gestartet. Telefon führt kein FW Update durch und die Dateinamen im TFTP Log stimmen nicht zu den üblichen Verdächtigen. Ich probierte noch einen Factory Reset mittels Tastenkombination und aus dem Menü, gleiches Verhalten.

WTF?

Nach etwas Recherche war ich immer noch nicht schlauer, konnte aber immerhin einen Artikel ([https://support.8x8.com/equipment-devices/phones/cisco/cisco-3pcc-how-to-provision-phone-for-8x8-service](How to Provision Cisco 3PCC Phones for VoIP Service)) finden, der beschrieb, wie man die 3PCC Telefone übers Webinterface provisioniert und Firmwareupdates hinterlegt.

Was solls, Passwort am Telefon festgelegt (sonst war der Login nicht möglich), als User angemeldet, auf Admin geswitched (direkter Login als Admin war nicht möglich -.-) und die Adresse vom TFTP Server mit Dateinamen hinterlegt (`tftp://IP-des-TFTP/sip88xx.14-2-1-0001-14.loads).

Telefon neugestartet, tatsächlich, das Update zieht und paar Minuten später hatte ich die SIP Firmware installiert.

Konfiguration

Der Haken der SIP Firmware ist, dass diese offenbar kaum Einstellungsmöglichkeiten bietet und trotz Aktivierung in der XML weder Webinterface noch SSH funktionieren.

Nachdem ich bei der Anleitung und Beispielkonfiguration die falsche Config erwischt hatte musste ich die Änderungen in den richtigen Configs erneut durchführen und die restlichen Parameter prüfen. Soweit, so gut.

Telefon vom Staging- ins Produktivnetz gehängt, gestartet und das Telefon hängt bei "Phone is registering".

Nun folgen Stunden Troubleshooting...

Da ich keine Möglichkeit hatte, zu prüfen, ob und wo SIP hängt blieb mir nur Wireshark. Mangels Throwing Star kramte ich einen alten Hub aus, den ich zuletzt genau für solche Zwecke vor der Verschrottung bewahrte. Dieser überraschte mich mit einer ungewöhnlichen Hohlbuchse und unüblichen 7,5 V Eingangsspannung... oh well... dazu in einem separaten Artikel mehr.

Anfangs passierte... nichts? Anscheinend braucht die SIP Firmware die aktuelle Config bei jedem Boot. Also gut, TFTP Server im Telefon konfiguriert, TFTP Server in einer VM wieder entsprechend hochgezogen.

Dann, ein paar DNS Abfragen, Stille, abholen der Config, DNS Abfragen, Stille, abholen der Config. Offenbar im Loop, da die DNS Abfrage für den A-Record von tel.t-online.de nicht erfolgreich war. Hier klingelten meine Alarmglocken, da ich zuletzt beim Troubleshooting meiner TK-Anlage noch feststellen durfte, dass die Telekom hier keine (zumindest für mich) übliche Lastverteilungstechniken einsetzt sondern mit SRV Records arbeitet.

In anderen Worten: ein normaler nslookup liefert nichts zurück. Stattdessen muss der SRV Record mit nslookup -q=SRV _sip._udp.tel.t-online.de abgefragt werden und lieferte:

Non-authoritative answer:
_sip._udp.tel.t-online.de	service = 20 0 5060 h2-epp-110.edns.t-ipnet.de.
_sip._udp.tel.t-online.de	service = 10 0 5060 k-epp-110.edns.t-ipnet.de.
_sip._udp.tel.t-online.de	service = 30 0 5060 d-epp-110.edns.t-ipnet.de.

In einem Riesenthread im Telekom Forum kotzen sich ebenso einige Leute darüber aus und suchen händeringend nach Lösungen. Den SRV Record zu nutzen scheint bei ältern Geräten schlichtweg zu fehlen, wie leider auch bei dem Cisco 8811 mit neuster Firmware. Jedenfalls konnte ich keine Möglichkeit in der SEPMAC.cnf.xmlfinden (https://usecallmanager.nz/sepmac-cnf-xml.html)

Kurzerhand habe ich als SIP Server einfach die erste Adresse vom SRV-Record eingetragen (h2-epp-110.edns.t-ipnet.de, wissentlich, dass es kaputt gehen kann).

Hey, es passiert endlich mehr! Oh, 403 Forbidden, verdammt.

Als erstes die Nummer "620" durch die tatsächliche Telefonnummer ausgetauscht, diese war in der Vorlage nicht als "zu ersetzen" markiert und mit der SEPMAC.cnf.xml hatte ich auch noch keine großen Berührungspunkte.

403 Forbidden.

Von der zuvor zickigen TK-Anlage konnte ich die SIP Logs mitschneiden, wovon ich nun die Einstellungen zu den tatsächlich übertragenen Daten und Antworten entsprechend beim Telefon übertragen bzw. vergleichen konnte. Nach diversen Versuchen hier die Werte richtig zu würfeln gab ich an einem Punkt auf, wo an sich die SIP Register Anforderung bis auf die From Adresse gut aussah. Diese konnte ich aber nicht verändern, da der Suffix abhängig vom SIP Server war, sprich als "From" Adresse wurde immer die +49xxxxxx@h2-epp-110.edns.t-ipnet.de gemeldet statt der +49xxxxxx@tel.t-online.de.

Der Versuch, das Telefon mit einem CNAME auszutricksen, indem ich tel.t-online.de auf h2-epp-110.edns.t-ipnet.de zeigen lies, ist leider gescheitert (vielleicht auch aus Ungeduld?).

Zum Laufen bekam ich das 8811 am Ende, indem ich einen A-Record für tel.t-online.de angelegt habe und diesen auf die aktuelle IP von h2-epp-110.edns.t-ipnet.de zeigen lies, sprich 217.0.29.33.

In der Config den SIP Server auf tel.t-online umgestellt, tadaaaaaa, es ist endlich registriert!

Haken

Leider ist das nur eine temporäre Lösung, da die DNS Einträge nicht aus Spaß bei der Arbeit bestehen sondern dafür sorgen, dass einzelne Server bei Wartungen oder Ausfall nicht mehr angeboten werden. Somit kann es jederzeit passieren, dass sobald der eingetragene Server nicht mehr erreichbar ist, das Telefon seine Registrierung verliert.

Hier wär ich dankbar, wenn vielleicht jemand eine Idee oder gar Lösung hat!

Andernfalls fallen mir momentan nur zwei Workarounds ein:

bestehen lassen mit dem Risiko, dass das Telefon ausfällt und der A-Record angepasst werden muss
Script entwickeln, welches im 5-10 Minuten Takt den SRV-Record bis runter zum A-Record abfrägt und die IP entsprechend im DNS Server im Telekom A-Record aktualisiert -> fehleranfällig, hässlich, zeitaufwändig

- Dom