Exchange 2007 - Unified Messaging im Details

Die neue Rolle des E2007:Unified Messaging über VoIP macht natürlich neugierig die Hintergründe zu verstehen. mit dem E2K7 UMTestphone ist es sogar jedem möglich, diese neue Funktion ohne Anbindung an eine Telefonanlage zu testen. Ich habe daher den folgende Konfiguration genutzt, um mit einem Netzwerkmonitor etwas tiefer in die Methodik zu schauen:

uM Konfiguration 

Auf meinem Notebook wurde das E2K7 UMTestphone gestartet, welches auf dem Exchange 2007 Server als "Gateway" eingerichtet wurde. Auf der Seite E2K7 UMTestphone ist auch die Konfiguration beschrieben.

NETMON Capture

Um die Datenmenge nicht zu groß werden zu lassen, habe ich mit dem Testphone den Exchange Server angerufen und die Ansage nur ein paar Sekunden abspielen lassen. Dann habe ich ein paar Nummern gedrückt und wieder aufgelegt. Dies reicht aber, um die Signalisierung und Sprachübertragung zu analysieren. Die folgenden Bilder wurden mit dem Programm Packetyzer generiert. Interessant ist hier zuerst einmal die Verteilung der Pakete nach den Protokollen.

uM Testphone Paketverteilung

Zwar steht überall, dass Exchange 2007 nur "SIP over TCP" macht, aber schon an der Verteilung ist zu sehen, dass ein Großteil  der Daten über UDP übertragen wird. Nur die Signalisierung selbst erfolgt über TCP. Davon sind die beiden mittleren Verbindungen sogar noch überflüssig, weil Sie fehlgeschlagene Verbindungsversuche darstellen. die erste Verbindung hingegen enthält folgende Pakete

SIP Connection

Man sieht hier den Verbindungsaufbau (Paket4) vom UMTestphone zum Exchange 2007 Server, welcher nicht direkt angenommen wird, sondern eine Umleitung (Paket 7) provoziert. Erst im Paket 8 erfolgt die eigentliche Verbindung zum  Server an die "richtige" Nummer.

Hier das Paket 3, welches die "Einladung" enthält:

SIP INVITE

Mit der darauf folgenden "Moved temporarly" Meldung

SIP MOVE

Und dann die "richtige" Verbindung:

SIP Request

Sie sehen also, dass SIP bei weitem nicht so kryptisch oder gar verschlüsselt ist und dass ein Admin aber auch ein "interessierter Laie" sehr einfach zumindest die Verbindungen mitschneiden und analysieren kann. Mittlerweile gibt es sogar kostenfreie Programme, die genau diese Verbindungsdaten aus dem Netzwerkmitschnitt heraus fischen.

Und die Sprache?

Nun können in den neun Paketen natürlich keine Sprache enthalten sein. Diese Information wird über UDP übertragen. In diesen Paketen ist dann auch die "Tonwahl" enthalten, mit welcher der Anrufer die Funktionen steuert. Die Töne werden mit einem Codec entsprechend umgesetzt (aber nicht verschlüsselt). Nur "sehen" kann man hier natürlich nicht viel:

uDP Voice

Im wesentlichen sind das UDP-Pakete mit dem Protokoll "RTP" (Realtime Transport Protokoll), welches als Nutzdaten die codierte Sprache enthält. Man kann hier zumindest am "Payload Type" erkennen, welcher Code (Hier G.711) genutzt wird.

Sicher gibt es auch hier schon wieder Werkzeuge, die eben diese Nutzdaten "mitschneiden" und durch einen entsprechenden Codec auch decodieren, sprich "hörbar" machen. Insofern ist Sprache über TCP/UDP erst einmal nicht sicherer als eine Telefonleitung. Allerdings kann eine Firma mittels VLANs, Switches und andere Mechanismen dafür sorgen, dass diese Sprachnachrichten in einem eigenen virtuellen Netzwerk übertragen werden. Auch Funktionen wie QoS (Quality of Service) sind hier gefragt, um die Laufzeit zu garantieren.

Wenn aber mehr und mehr Personen über die Soundkarte ihres Computers telefonieren, dann ist auch diese Trennung nicht mehr möglich und die Frage stellt sich dann, ob die Daten nicht doch auch verschlüsselt werden sollten.

Diversion im Paket

Ich habe ja schon an mehreren Stellen beschrieben, dass ein Exchange Server etwas anders angebunden wird, als die meisten Faxserver und anderen Systeme, die Rufe annehmen. Exchange hat in der Regel nur genau eine Rufnummer und unterscheidet die gewünschte Zielmailbox über den zusätzlichen Parameter "Diversion".

Diversion

Dieses Packe zeigt einen eingehenden Ruf (Einladung) des Exchange Server. Die FROM-Zeile seigt, dass hier die Rufnummer "111" einen Anruf an die Nebenstelle "680" am Exchange Server auslöst, aber der Ruf von der Nebenstelle 613 umgeleitet wurde. Die Nebenstelle 111 hat also die 613 angerufen, welche aber wegen "Nicht Annahme" auf Exchange umgeleitet wurde.

Weitere Links