Diversion

Der Aufbau einer Verbindung per Telefon erscheint einfach: ein Anrufer wählt eine Nummer, um sich mit dem gewünschten Ziel verbinden zu lassen. Im Hintergrund werkeln natürlich verschiedene Übermittlungsverfahren (z.B. bei ISDN die Meldungen auf dem D-Kanal oder VoIP die entsprechenden SIP-Meldungen. Gateways zwischen den beiden Welten setzen die Rufnummern entsprechend um.

Aber seit Exchange Unified Messaging ist zumindest eine Zusatzfunktion ins Rampenlicht gerückt, die sonst gerne vergessen wird. Microsoft hat nämlich für die direkte Erreichbarkeit von Mailboxen über die Exchange UM-Rolle nicht einen Rufnummernblock vorgesehen, sondern genau eine Rufnummer. Es liegt nahe, dass dies der Rufnummernknappheit in den uSA bzw. der üblichen Erreichbarkeit über "+1 (Regionalcode) Rufnummer EXT Durchwahl" geschuldet ist. Es ist gar nicht unüblich, dass eine Firma wenige Rufnummern hat und Sie über eine "Nachwahl" dann die eigentliche Durchwahl erreichen. Die Exchange UM-Rolle hat daher eine Rufnummer, welche per SIP erreichbar ist und erwartet die Information über die gewünschte Nebenstelle in einem eigenen Feld namens "Diversion".

Einfache Diversion

Um die Funktion des Felds und deren Erscheinen zu zeigen, ist eine telefonische Weiterleitung ein guter Startpunkt: Gegeben sind drei Teilnehmer, von denen Teilnehmer 1 gerade Teilnehmer 2 anruft, der sein Telefon aber auf Teilnehmer 3 weitergeleitet hat.

Teilnehmer 1 ruft Teilnehmer 2 direkt an. Die TK Anlage leitet den Ruf aber zu Teilnehmer 3 weiter. Teilnehmer 3 wird über seine direkte Rufnummer angerufen aber erhält ebenfalls die Information, dass der Ruf von Teilnehmer 1 kommt und 2 weiter geleitet wurde. Abhängig von der Konfiguration der Telefonanlage als auch des Endgeräts kann der Anwender an Telefon 3 nun unterschiedliche Informationen sehen, von dem der Ruf kommt:

  • Anruf von Rufnummer von TN1
    Dann hat die Anlage vermutlich die Rufnummer als "Originator"-Adresse mitgeliefert. Das funktioniert innerhalb der gleichen TK-Anlage noch recht gut, da hier das "Fälschen" von Rufnummern noch einfach ist. Wenn TN3 aber z.B.: ein Mobiltelefon ist und TN1 aus Firma1 und TN2 in Firma 2 arbeiten, dann wird es nicht immer funktionieren, dass Firma 2 einen Ruf zum Mobilfunk aufbaut und dabei die Rufnummer von Firma 1 vorgibt. (Stichwort: Clip no Screening)
  • Anruf von Rufnummer von TN2
    Ist ist meist der Fall, wenn die TK-Anlage entweder die Rufnummer des Anrufers nicht mit übergeben kann. (Stichwort: Clip no Screening)
  • Anruf für TN2
    Wenn das Telefon anzeigt, dass der Ruf für TN2 ist, dann sendet die Anlage korrekt diese Information als Diversion mit und das Telefon ist auch korrekt eingestellt, um dies so anzuzeigen.
  • Anruf für TN3
    In diesem Fall ist das Telefon nicht kompatible und zeigt den Ruf als Ruf an TN3 an oder die TK-Anlage sendet die Weiterleitung nicht korrekt.

Um diese Informationen zu übermitteln, gibt es im ISDN-Protokoll mehrere Felder, die Rufnummern enthalten können und natürlich gesetzt und auch vom Gateway umgesetzt werden müssen.

  • Called Party Number
  • Calling Party Number
  • Redirecting Number
  • Original Called Party Number

Diversion mit Exchange UM

Die Exchange Unified Messaging Rolle arbeitet intern natürlich per SIP und VoIP und auch hier gibt es natürlich entsprechende Felder, die eine Umleitung kennzeichnen. Ein typischer SIP-Verbindungsaufbau an eine Exchange 2007 Unified Messaging Rolle zeigt hier, dass die Nebenstelle 111 eigentlich die 613 erreichen wollte aber von dort aufgrund "reason=no-answer" auf die 680 weiter geleitet wurde.

Wenn Sie also Exchange Unified Messaging in einer Umgebung mit einer klassischen Telefonanlage einsetzen, dann muss die TK-Anlage diese Information im Feld "Redirecting Number" an das Gateway senden, welches dann diese Information entsprechend in das SIP-Protokoll umsetzt. Erst dann können sie ihr Tischtelefon auf ihre Exchange Mailbox umleiten.

Diversion mit OCS

Interessant wird diese Funktion mit OCS als Telefonanlage mit einem Gateway zur klassischen Telefonie. Da gibt es einmal die Funktion, dass ich von unterwegs entweder per Windows Mobile Handheld oder von jedem Browser per Communicator Web Access einfach einen Anruf anfordern kann. Der OCS-Server ruft dann zuerst bei mir (Mobil, im Hotel o.ä.) an und weist sich natürlich mit seiner normalen Rufnummer aus. Dann baut er eine zweite Verbindung vom Firmennetzwerk zum gewünschten Gesprächspartner aus, aber nutzt dabei natürlich meine "Firmenrufnummer". Der angerufene Teilnehmer sieht also nicht meine Mobilrufnummer. Hier muss OCS also "in meinem Namen und mit meiner Nummer" anrufen.

Das ist aber noch einfach im vergleich zum folgenden Problem. Hier ruft mich z.B.: ein Kunde auf meiner OCS-Rufnummer an. Ich habe auf meinem Communicator aber eingestellt, dass der Ruf auf mein Mobiltelefon weiter geleitet wird. OCS vermittelt also den Ruf. Wenn Diversion hier nicht funktioniert, dann sehe ich auf dem Mobiltelefon aber nur die Rufnummer des OCS-Servers.

Wünschenswert und möglich ist es, dass der OCS-Server mich zwar mobil anruft aber als Absenderkennung den eigentlichen Anrufer übermittelt. Ich würde auf meinem Mobiltelefon gerne einen Anruf von +49 69 4711 sehen, auch wenn der Ruf erst ������ber den OCS-Server weiter geleitet worden ist. Damit dies funktioniert, müssen allerdings mehrere Voraussetzungen erfüllt sein und der "richtige Weg" beschritten werden. Es gibt hier nämlich zwei Optionen:

  • ändern der Calling Party Number
    Es ist in Deutschland möglich, eine beliebige Rufnummer als Anrufer" an das TDM-Netz zu übergeben. Die Provider (Telekom etc.) nennen diese Funktion, die dazu aber frei geschaltet sein muss, "Clip no Screening COLP", siehe auch CLIP - Rufende Nummer. Dann kann ich aber "jede" Nummer als Anrufer übergeben. Natürlich ist Missbrauch möglich, aber es handelt sich dabei nur um die "User Supplied Number", während der Provider natürlich immer noch die "Network supplied Number" addiert. Es hängt dann vom angerufenen System an, welche der beiden Nummern angezeigt wird
  • Übermitteln der Redirect Number
    Anstatt die anrufende Nummer zu verändern, kann der Anrufer die Diversion/Redirect-Number an den angerufenen Teilnehmer übermitteln. Wenn diese Zusatzinformation nicht auf dem Web verloren geht (VoIP-Gateway und TK-Anlagen sind da oft Schuld), dann kommt diese Information bis zum gerufenen Teilnehmer an. Allerdings muss auch dessen Endgerät nun natürlich diese Nummer anzeigen.

Sie sehen schon, dass die Anzeige des richtigen Anrufers nicht immer einfach ist und vieles auch vom angerufenen Partner abhängt, ob er die entsprechenden Informationen auch korrekt übernimmt und anzeigt.

Diversion analysieren

Ich habe einmal mit einem Audiocodes Mediant 1000 einen Trace der SIP und ISDN- Kommunikation gezogen und die relevanten Zeilen hier dokumentiert. Es handelt sich um einen Anruf von +4952467xxxx auf meine OCS-Nummer +495251304713, welche aber auf mein Mobiltelefon (+491577785xxxx) weiter geleitet ist.

Sie sehen zuerst den INVITE, welcher mit einem OK quittiert wird. Die Weiterleitung wird gemeldet und bestätigt. Dann sehen Sie den zweiten INVITE, welcher die Verbindung nach draußen zum Mobiltelefon (Weiterleitungsziel) aufbaut.

INVITE sip:+495251304713@192.168.100.101;user=phone SIP/2.0 
	From: <sip:+4952467xxxx@m1000.netatwork.de>
	To: <sip:+495251304713@192.168.100.101;user=phone> 
SIP/2.0 200 OK 
	FROM: <sip:+4952467xxxx@m1000.netatwork.de>
	TO: <sip:+495251304713@192.168.100.101;user=phone>
SIP/2.0 181 Call Is Being Forwarded 
	FROM: <sip:+4952467xxxx@m1000.netatwork.de>;tag=1c735251208 
	TO: <sip:+495251304713@192.168.100.101;user=phone>
SIP/2.0 183 Session Progress 
	FROM: <sip:+4952467xxxx@m1000.netatwork.de>
	TO: <sip:+495251304713@192.168.100.101;user=phone>
INVITE sip:+491577785xxxx@192.168.100.107
	FROM: <sip:+4952467xxxx@netatwork.de;user=phone>
	TO: <sip:+491577785xxxx@192.168.100.107;user=phone>
SIP/2.0 100 Trying Via: 
	From: <sip:+4952467xxxx@netatwork.de;user=phone>
	To: <sip:+491577785xxxx@192.168.100.107;user=phone>
ISDN :SETUP (TO:+491577785xxxx, FROM:+4952467xxxx)

Wichtig sind hier die verwendeten Rufnummern. Sie sehen, dass der Mediation Server als abgehende Rufnummer "sip:+4952467xxxx@netatwork.de" verwendet. Die letzte Zeile zeigt dann den ISDN-Verbindungsaufbau. Hier sendet der Mediant also die "+4952467xxxx" als CallerID mit. Ab nun liegt es an der TK-Anlage oder dem TDM-Provider, ob diese die Rufnummer zulassen.

Empfehlung

Bislang habe ich recht gute Erfahrungen mit der Veränderung der nach extern gemeldeten Rufnummer (Siehe auch CLIP - Rufende Nummer) gemacht. Diese Technik ist "bewährt" weil sie schon lange in Gebrauch ist. Jede Telefonanlage mit Nebenstellen hat eine Stammnummer (bei Net at Work ist das die +49 5251 304 5), die von der Telekom immer dann eingesetzt wird, wenn wir eine komplett ungültige Rufnummer übermitteln sollten. Aber über diesen Weg können wir z.B.: die +49 5251 304 613 als TK-Anlage melden. In dem Fall scheint die Telekom meine Nummer auch als "Network provided number" zu übermitteln, da sie aus dem gleichen Anschlussbereich ist.

Möchte ich aber Rufe aus der externen Welt durch den OCS hindurch auf mein Mobiltelefon lenken, dann muss mit die Telekom auch erlaubten, dass ich andere Rufnummern als "rufende Stelle" an das TDM melde. Wenn ich dann das Feature CLIP nicht beantragt habe, dann sehen Sie die Stammnummer. Aber selbst wenn das Feature frei geschaltet ist, dann kann ihnen immer noch der angerufene Teilnehmer einen Strich durch die Rechnung machen. Oder ihre OCS-Installation oder ihr VoIP-Gateway.

Unterstützung durch Net at Work:
Sie sehen schon, dass die Fehlersuche in solchen Umgebungen nicht einfach ist. Dazu benötigt man z.B. die Möglichkeit einen SIP-Trace auf dem OCS-Server zu ziehen, die SIP-Kommunikation zwischen Gateway und Mediation Server mitzuschneiden und idealerweise auch die ISDN-Kommunikation zwischen Gateway und TK-Anlage oder TDM.

Weitere Links