Das Dilemma mit dem Standard

Heute bin ich wieder den 2 Seiten der Telekommunikation begegnet. Die eine Seite ist die Seite der Standards, die Seite, die Consulter und Kunden gerne hätten. Die andere Seite ist die Seite der Hersteller, proprietär, was in einer homogenen Lösung aber nicht auffällt und damit auch nicht per se schlecht ist.

Gefordert wurde in einer Ausschreibung eine UC-Lösung, deren Elemente ausschließlich über SIP kommunizieren. Der Sinn, ganz klar, die Elemente sind austauschbar, der Kunde kann best of breed und kostengünstig auswählen. Was aber leider immer wieder verschwiegen wird ist, dass in diesem Fall jede Menge Komfort, meist gewohnter Komfort, entfällt. Komfort wird von alteingesessenen TK-Herstellern immer mit der Leistungsmerkmaldiskussion beantwortet. 500, 600, 700 Leistungsmerkmale einer Kommunikationsanlage müssen es schon sein, ob man sie nutzt oder eben auch nicht.

SIP selbst bietet nun mal im Standard immer noch nicht allzuviele Merkmale. Es gibt immer wieder Anforderungen, die selbst bei breiter Auslegung, nicht durch eine reine Standard-SIP-Lösung realisiert werden können. Dann schlägt die Stunde der proprietären SIP-Erweiterungen oder eben Herstellerprotokollen. Interessant, und das ist mir dann heute passiert, ist dann der Zusammenprall der Welten. In einer Lösung sollen proprietäre Protokolle und Standardprotokolle parallel, für unterschiedliche Anwendungsfälle, betrieben werden.

Zunächst einmal ist dies prinzipiell möglich. Allerdings, wie so oft, steckt der Teufel im Detail. In meinem Fall nun kommt es zu einer Kopplung zweier Netzwerke über einen Session-Border-Controller (SBC), der zwar mit SIP bzw. SIPS umgehen kann, jedoch das Herstellerprotokoll nur transparent durchleitet. Gleichzeitig aber wird das Ganze noch durch ein ausgeklügeltes Securitykonzept überlagert, welches den Accessbereich über den SBC von dem Serverbereich trennt. Auch dies, bei der Verwendung des Standards, für den SBC eine seiner ureigensten Aufgaben. Doch auch hier scheitert dann das Herstellerprotokoll, da eine Kontrolle über den SBC nur teilweise möglich ist.

In den nächsten Tagen werden daher intensive Designaufgaben anstehen, um hier eine Lösung zu finden, die dann zwar nicht vollständig den ursprünglichen Anforderungen entspricht, aber denen doch möglichst nah kommt.

Hinterlasse einen Kommentar

Eingeordnet unter Telekommunikation

Schreibe einen Kommentar

Bitte logge dich mit einer dieser Methoden ein, um deinen Kommentar zu veröffentlichen:

WordPress.com-Logo

Du kommentierst mit Deinem WordPress.com-Konto. Abmelden / Ändern )

Twitter-Bild

Du kommentierst mit Deinem Twitter-Konto. Abmelden / Ändern )

Facebook-Foto

Du kommentierst mit Deinem Facebook-Konto. Abmelden / Ändern )

Google+ Foto

Du kommentierst mit Deinem Google+-Konto. Abmelden / Ändern )

Verbinde mit %s