Kommentar: SIP

Standards sind nicht immer und überall gültig

20. Oktober 2014, 13:06 Uhr | Mathias Hein, freier Consultant in Neuburg an der Donau
Kolumnist: Mathias Hein
© funkschau

Das Problem mit Standards besteht darin, dass diese nicht immer passen. Denn diese sind selten immer und überall gültig. Es scheint, dass, egal welche Art von Technologie man nutzt, es immer irgendwelche Schwankungen gibt. Von daher muss man häufig innerhalb der Standards die Standards anpassen.

In Europa liefert eine Steckdose den Strom von 230 Volt bei einer Frequenz von 50 Herz. In Nordamerika verwenden sie 120 Volt bei 60 Herz. In Mexiko wurde der Strom bei 127 Volt und 60 Herz "standardisiert". Auch die Form der elektrischen Netzstecker variieren auf der ganzen Welt. Aus diesem Grund kann niemand erwarten, dass sein Handy-Ladegerät in alle Steckdosen der Welt passt. Für die Anpassung der Steckerbauformen sorgt ein Adapter.

Der Standard für digitale Telefonverbindungen heißt in Europa E1 und nutzt 30 Kanäle, während in den Vereinigten Staaten dieser Standard als T1 bezeichnet wird und 24 Kanäle bereitstellt. In Europa und Nordamerika fährt man mit dem Auto auf der rechten Straßenseite, während man in England, Indien, Australien und Südafrika auf der linken Seite fährt. Auch kann kein Zugreisender erwarten, dass er unterbrechungsfrei zwischen Brasilien und Bolivien sich fortbewegen kann. In der Realität gibt es acht verschiedene Spurweiten für die Eisenbahnstrecken dieser Welt. Hiervon werden in Südamerika fünf Spurweiten verwendet.

Warum sollte das SIP (Session-Initiation-Protocol) anders sein? Warum sollte man erwarten, dass das Cisco-SIP mit dem Microsoft-SIP, dem Avaya-SIP oder dem Unify-SIP problemlos interagiert? Was hilft? Wer einen Professor im Bekanntenkreis hat, der könnte ihn um Rat fragen; alle anderen sind auf Bücher angewiesen. Die Verlage halten dafür die Ratgeberliteratur vor, deren Bestseller die Seelenlage der Technologie spiegeln sollten, nicht wahr?

Noch ist die Welt jedoch nicht verloren. Das SIP-Protokoll wird von den Leuten entwickelt und spezifiziert, die sämtliche Internet-Protokolle entwickelt haben. Die SIP-Entwicklung wird von der Internet Engineering Task Force (IETF) gesteuert und die Hersteller beziehungsweise  Entwickler sind in den vergangenen 40 Jahren zum größten Teil den IETF-Dokumenten und -Empfehlungen gefolgt. Daher kann man darauf vertrauen, dass SIP-Dienste und SIP-Geräte von verschiedenen Herstellern zusammen arbeiten und in der Regel gut funktionieren werden.

Dennoch haben sich einige Hersteller ihre persönlichen SIP-Freiheiten genommen und ihre eigene SIP-Welt geschaffen.

Was tut man, wenn der Cisco-Call-Manager davon ausgeht, dass die Informationen in einen Diversion-Header umgeleitet wird und der Avaya-Communication-Manager darauf beharrt, diese Information in einem History-Info-Header zu verpacken? Ganz einfach: Man passt sich an die Situation an. Die Anpassung ist der Schlüssel zur SIP-Interoperabilität und sorgt dafür, dass SIP-Telefone, Call-Server, Anwendungen und Trunks von verschiedenen Anbietern miteinander kommunizieren können.

Die Anpassung ist auch ein Allheilmittel mit dessen Hilfe eine Reihe von Krankheiten geheilt werden können. Manchmal liegt das Problem in den SIP-Headern. Ein Hersteller erwartet in einem bestimmten Teil des Headers seine Daten, während ein anderer Hersteller die gleichen Daten in einem anderen Teil des Headers unterbringt. Darüber hinaus ist es auch möglich, dass ein Hersteller gewisse Daten abfragt, die ein anderer Hersteller – unabhängig vom Header-Typ – nicht übermitteln will. Die Ursache für ein Problem kann beispielsweise auch in der in einer SIP-Nachricht übermittelten Nachricht liegen. Zum Beispiel nutzt Nortel eine mehrteilige MIME-Information in dem Nachrichtenfeld einer INVITE-Anfrage. So weit so gut, aber nur eine CS1000-Komponente von Nortel kann diese Nachricht entziffern.

Darüber hinaus können eine Kombination aus SIP-Nachrichten und dem VoIP-Media-Stream zum Problem werden. Es gibt immer noch Produkte, die die SIP-INFO-Nachrichten verwenden, um DTMF-Töne übertragen zu können. Der Rest der Welt nutzt jedoch das im RFC 2833/4733 festgelegte Verfahren, welches die Töne in einem eigenen Media-Stream unterbringt.


  1. Standards sind nicht immer und überall gültig
  2. Anpassungswerkzeuge

Lesen Sie mehr zum Thema


Jetzt kostenfreie Newsletter bestellen!

Weitere Artikel zu connect professional

Matchmaker+