Rufnummern und Routing

Beachten Sie in dem Zusammenhang auch die Seite Location profiles - Standortprofil

RCC und Normalisierung
Wenn Sie mit dem Communicator ihre Telefonanlage per "Remote Control" steuern, dann treffen diese Normalisierungsregeln NICHT zu !, d.h. hier muss die TK-Anlage oder die RCC-Gegenstelle die gewählte Nummer umsetzen, wie dies auch bei einer am Telefon selbst gewählten Nummer erfolgt.

Lync normalisiert keine Rufnummern, die mit einem "+" beginnen. Er geht davon aus, dass diese Nummern schon im E164-Format vorliegen. Die Normalisierung erfolgt durch den FrontendServer. Ein Mediation Server dazwischen addiert nur den Namen des Gateway als "phone-context=gatewayname", zudem natürlich ein Dialplan passen muss."

Nur Rufnummern im E164 werden bei der "Reverse Name Lookup" (RNL) berücksichtigt

Die Exchange UM Rolle und der Office Communications Server arbeiten zwar mit TCP/IP, nutzen SIP zur Signalisierung und haben nicht direkt etwas mit der klassischen Telefonanlage zu tun. Trotzdem dreht sich alles um "Nummern", und damit meine ich nicht IP-Adressen.

Rufnummern sind nun mal immer noch die Adressierung, mit der Personen lange Zeit Kommunikationspartner erreich haben und sicher auch noch erreichen werden, selbst wenn E-Mailadressen mittlerweile auch den Weg auf jede Visitenkarte gefunden haben und in ähnlicher Form auch als Instant Message und SIP-Adresse erscheinen.

E.164 bzw. RFC3966

Aber Rufnummern sind wie IP-Adressen eindeutige Adressen, die lange Zeit sogar geografisch klar zuzuordnen war. Und jeder kennt den Aufbau einer vollständigen Rufnummer, wie er auch in der Norm E.164 beschrieben ist:

+<country><local>

Der Area-Code besteht aus 1-3 Zeichen  (z.B. 1=USA, 49=Deutschland) und der lokale aus 12-14 Ziffern. Insgesamt darf die Nummer maximal 15 Stellen lang sein. Und genau solch eine Rufnummer ist ein eindeutiger primärer Schlüssel um Empfänger zu erreichen. Die Rufnummer ist natürlich auch der Schlüssel zur UM Mailbox und zum Mediation Server und Gateway zur Telefonanlage.

Da viele Anwender auch eine Telefonnummer in ihrem Disclaimer (Anhang ein jede Mail) verwenden, sollten Sie hier dann die richtige Schreibweise verwenden. hier ein par Beispiele, was ich so schon gesehen habe:

Rufnummer Richtig/Falsch Bemerkung

+495251304613

Ok

Das ist eine klassische einfache Nummer ohne Sonderzeichen. Zugegeben, sie ist für menschliche Augen nicht einfach zu lesen. Aber die meisten Programme haben kein Problem mit Leerzeichen, Klammern und Bindestrichen.

+49 (5251) 304 6153

Ok

Ebenfalls korrekt. Klammern (und viele andere Sonderzeichen) können die meisten Anwendungen sauber entfernen. Hier kann die Klammer

+49 (0) 5251 304 613

Falsch

Diese Schreibweise sehe ich seht häufig aber ist falsch. Die "0" ist keine Bereichskennzahl und nur Menschen verstehen, das die Klammer hier als "kann"-Bedingung steht. Ein Admin kann über reguläre Ausdrücke solche Fehler ausmerzen, aber meist geht es schief.

0049 (5251) 304 613

Falsch

Auf Festnetztelefonen können Sie kein "+49" eingeben und in Deutschland beginnt die internationale Vorwahl eben mit einem "00". Das ist aber in vielen anderen Ländern nicht der Fall. z.B. USA=011, Australien=0011, Russland, Litauen u.a. = 810 (Siehe auch http://de.wikipedia.org/wiki/Internationale_Telefonvorwahl)
Die +49 ist daher in der computergestützten Telefonie immer vorzuziehen und auch bei Mobiltelefonen immer erste Wahl.

05251 304 613

eingeschränkt

Diese Nummer funktioniert zumindest, wenn Sie selbst in Deutschland sind und damit keine Landesvorwahl bauchen. Aber wenn Sie so eine Nummer als Kontakt im Adressbuch haben und mit dem Mobiltelefon abgleiche, können Sie diesen Teilnehmer nicht mehr aus dem Ausland anrufen.

Kleiner Tipp: Wenn Sie ein "Tel:" für die Rufnummer schreiben, dann können viele CTI-Progamme diese Nummer direkt erkennen und per Klick sofort anrufen.

Rufnummern in Outlook

Wenn Sie in Outlook eine Rufnummer bei einem Kontakt über den Assistenten eingeben, dann sehen Sie folgendes Bild:

Aus den vier Bestandteilen Land, Ort, Anschluss und Durchwahl macht Outlook schon eine Nummer, die dem E164-Format sehr nahe kommt. Zur besseren Lesbarkeit fügt Outlook zwar Klammern und Bindestriche ein, aber die kann eine Software ganz einfach entfernen. Anders sieht es aus, wenn Sie hier z.B.: nur die interne Durchwahl eintragen würden. Damit kann fast keine Software sinnvoll etwas anfangen, es sei denn sie hinterlegen dort die fehlende Information. Dazu später mehr.

NPI und TON

Zwei weitere wichtige aber für IT-Personen meist unbekannte Felder sind NPI (Number Plan Indicator) und TON (Type of Number). Beider Signalisierung im klassischen Telefonnetz (z.B. ISDN DSS1 oder QSIG) wird nicht nur eine Nummer übertragen, sondern auch die Information, wie diese Nummer zu interpretieren ist. Es ist jede Kombination von NPI und TON möglich, aber in der Regel werden nur wenige Kombinationen verwendet. Das erinnert mich etwas an das "Dienstmerkmal" im ISDN. Wer hier z.B. FAX korrekt eingestellt hat, konnte mit einigen Gegenstellen gerade nicht FAX übermitteln.

Die Einstellungen für NPI und TON gelten sowohl für die CallingID als auch CallerID, d.h. die gerufene als auch die rufende Nummer:

NPI

TON Beschreibung

0 =Unknown

0 = unknown

Eine gültige Einstellung ohne weitere Details, wie die Nummer zu interpretieren ist.

1 = E.164 Public bzw. ISDN

0 = unknown

Eine öffentliche Nummer im E164 Format aber ohne weitere Deutungsinformationen. Sie müssen eine entsprechende Testreihe durchführen

1 = International

Eine internationale Nummer im E164 Format mit Ländercode
495251304613. Bei Amtsanschlüssen in der Regel genutzt, wenn Empfänger extern ist,

2 = National

Eine nationale Nummer im E164 Format ohne Ländercode
5251304613. Bei Amtsanschlüssen in der Regel genutzt, wenn Empfänger extern ist,

4 = Subscriber

Diese Kombination sehen Sie oft, wenn die Telekom einen Ruf an ihre TK-Technik über einen "Anlagenanschluss" übergibt.

2 = Generisch

Habe ich bislang nie im Einsatz gesehen

3 = X.121 Daten

Habe ich bislang nie im Einsatz gesehen

4 = F.69, Telex

Habe ich bislang nie im Einsatz gesehen

5 = E.210/E.211 (maritime mobile)

Habe ich bislang nie im Einsatz gesehen

6 = E.212 land mobile

Habe ich bislang nie im Einsatz gesehen, Also nicht mal Telekom, Vodafone, ePlus, O2 nutzen diese Kennung. Vermutlich ersetzen aber schon die Provider diesen Wert aus Kompatibilitätsgründen durch "1

7 = E.214, ISDN/mobile

Habe ich bislang nie im Einsatz gesehen

8 = ?

Habe ich bislang nie im Einsatz gesehen

9 = Privat

0 = unknown

Eine private Nummer ohne weitere Angaben zur Bedeutung

1 = Level 2 Regional

Privat

2 = Level 1 Regional

Eine private Nummer mit Ortsangabe

PISN specific

Privat

4 = Level 0 Regional

Eine private Durchwahl, vergleichbar mit einer MSN

Meist hatte ich bislang mit einem NPI=1 zu tun und TON-Werten von 1 und 2. Das muss aber nicht heißen, dass die anderen Werte nicht auch seitens ihrer TK-Anbindung gemeldet werden oder sie bei ausgehenden Rufen diese Werte nicht setzen müssen.

Sie können nicht einfach von der gleichen Schreibweise einer Nummer ausgehen.. Ich habe schon ISDN-Signalisierungen gesehen, die einfach nur die Nummer ohne "0"  übertragen haben. Wie wollen Sie dann wissen, ob "5251304600" nun eine Nummer in Deutschland ist oder eine sehr Kurze Rufnummer im Land "52"? Diese Felder gibt es aber so nicht in SIP, d.h. das Gateway, welches auf einer Seite per ISDN kommuniziert muss die Felder in die SIP-Rufnummer umsetzen.

Die Umsetzung ist je Gateway individuell.

  • Ferrari:
    Die beiden Begriffe erscheinen nicht "sichtbar" aber sind in der Konfiguration (erweiterte Konfiguration - Allgemein) einstellbar. Dies ist wichtig, wenn die Box direkt am Amt angeschlossen ist. Als unteranlage hinter einer PBX werden diese Einstellungen meist nicht verwendet.

    Die Texte hier werden addiert, wenn per ISDN die entsprechende Kennzeichnung kommt. Siehe auch http://forum.ferrari-electronic.de/showthread.php?t=882
  • Audiocodes Mediant 1000
    Hier sind die Einstellungen im Bereich "Configuration->Protocol Configuration->Routing Tables->Routing General Parameters " hinterlegt.

    Aktiviert man hier diese Einstellungen, dann werden die Werte für NPI/TON vor dir Rufnummer geschrieben und können so in der Routingtabelle mit einbezogen werden. Wundern sie sich dann also nicht, wenn vor der eingehenden Rufnummer z.B. eine 12 erscheint.

Auch andere Gateways haben in der ein oder anderen Form eine EinstellMöglichkeit, wie NPI/TON übernommen werden kann. Speziell wenn das Gateway direkt an einem Carrier betrieben wird, muss diese Funktion enthalten sein, da vom Amt in der Regel nur die komplette Rufnummer ohne führende 0, 00, oder + kommt und daher zumindest TON relevant ist.

Normalisierung erforderlich

Nur kann man von Anwendern nicht erwarten, dass Sie immer eine volle E.164 Nummer verwenden. Und Telefonanlagen signalisieren nicht immer alle Ziffern komplett. Wenn sie also intern einen Kollegen anrufen, wenn geben Sie natürlich die "kurze" interne Durchwahl an und wenn Sie selbst angerufen werden, dann zeigt ihnen ihr Telefon in der Regel auch nur die interne Rufnummer des Anrufers an (oder sogar den Namen). Es ist ihnen auch völlig klar, dass Sie z.B. eine "0" eine Vorwahl für die "Amtsholung" benötigen und vielleicht mit einer "9" ein Privatamt bekommen, so dass der Arbeitgeber private Telefonate abrechnen kann und die Rufnummernaufzeichnung underdrückt.

Egal was sie also im OCS-Client nun "wählen", der OCS-Server muss die Nummern in das E.164-Format umsetzen und bei eingehenden Rufen ebenfalls aus einer partiellen Nummer eine vollständige Adresse für die Suche im Active Directory machen. Zuerst sollten Sie sich also mal ein Schaubild der Rufnummern und Verbindungen anlegen:

Dieses Bild ist natürlich sehr vereinfacht. Wenn andere Länder und Standorte mit Querverbindungen und Least-Cost-Routing dazu kommen, dann kann das Bild sehr schnell unübersichtlich werden.

Wenn ich also in Paderborn einer dreistellige Nummer wähle, dann muss die Normierung ein +495251304 davor schreiben. Wenn ich aber eine 0 und weiter Nummern wähle, dann muss die Normierung die "0" abschneiden und ein "+495251" addieren, da es sich um eine Rufnummer in Paderborn handelt. Allerdings braucht ich keine "+495251xxx" an die Telekom zu senden. Die "versteht" das natürlich nicht. Hier muss ich dann wieder je nach Einrichtung mit 05251xxxx signalisieren.

Sie sehen also dass Rufnummernnormierung, Umsetzung und Routing ein wichtiger Teil einer Infrastruktur ist. Und damit sind wir beim Thema angekommen. Es gibt nämlich gleich mehrere Systeme, die Rufnummern "umbauen":

Normierungsstellen

  • Communicator (OCS Communicator)
    Zuerst hat der Communicator Client schon eine Menge von "Übersetzungsregeln" im Bauch, um z.B. eingehenden Anrufe so umzubauen, dass daraus eine vollständige E.164 Nummer wird, nach der der dann die Kontakte suchen kann. Allerdings entfernen diese Regeln nur Sonderzeichen, die in einer E.164-Nummer vorkommen.
  • OCS Server (Siehe auch Location profiles - Standortprofil)
    Der Server selbst ist die Stelle, an der ein Administrator am einfachsten Übersetzungsregeln einbinden kann (und muss), damit die Rufnummern normalisiert werden. Hier wird auch anhand der Rufnummer ein "Routing" gemacht, und beim Routing können erneut mit ähnlichen Regeln die Wege bestimmt werden
  • Mediation Server oder RCC Gateway
    Auf dem Mediation Server selbst findet  keine Umsetzungen bezüglich der SIP Signalisierung statt, sondern nur eine Codec-Umwandlung. (RTSP/SRTP zu G.711).
  • Oft wird auf einem Server ein RCC Gateway (z.B. Estos RCC Gateway) betrieben, welches zwischen OCS-Server und CSTA-Schnittstelle der Telefonanlage vermittelt. Hier sind auch entsprechende Regeln möglich.
  • Gateway (SIP/PBX)
    Für die Anbindung an eine Telefonanlage oder auch direkt an die Amtsleitung wird ein OCS Gateway benötigt, welches zuerst einmal die elektrische und logische Verbindung zwischen "Ethernet/TCPIP/SIP" zur Telefonanlage herstellt. Klar dass auch hier Übersetzungsregeln angewendet werden können. Wenn das Gateway direkt die Verbindung zur Telefon herstellt, muss dieses Gateway sowohl Ziel als auch Absenderrufnummern für den Telefonprovider entsprechend aufbereiten. E.164-Adressen kommen auf einem S0 oder S2M-Anschluss nicht gut an.
  • Telefonanlage
    Auch eine Telefonanlage normalisiert Rufnummern, die OCS Arbeit abnehmen oder die Konfiguration komplexer machen kann.

Die Kette vom Communicator zum klassischen Telefon ist schon etwas länger und an vielen Stellen kann man die Signalisierung anpassen. Man muss aber nicht alle Stellen ausschöpfen. Meist reicht es wirklich im OCS Server die Regeln in Abstimmung mit der Telefonanlage zu pflegen. Das ist aber oft auch das größte Problem: Wie verständigen sich Netzwerkadministratoren mit Telefonadministratoren. (Siehe auch OCS Adminkonzept)

Der zweite Baustein der Rufnummern ist die Bestimmung des Ziels, zu dem ein Verbindungswunsch weiter gegeben wird. Besonders in Verbindung mit dem Mediation Server ist hier eine korrekte Konfiguration gefragt, da sowohl eingehende als auch ausgehende Verbindungen über die signalisierte Rufnummer geroutet werden. Kommt z.B. ein Ruf über ein Gateway zum Mediation Server, dann steht in der SIP-Einladung hoffentlich ein "+4952513094613@sipgateway", worauf das Mediation Gateway im Active Directory den passenden Empfänger sucht. Ist dies ein OCS-Benutzer, dann wird der Anruf an OCS weiter gegeben. Gibt es den Benutzer aber nicht, dann wird der Anruf wieder weiter geleitet, notfalls sogar über das gleiche Gateway wieder nach draußen.

Auch für die Auflösung von Rufnummern zu Namen ist diese Auflösung einer Rufnummer zum Teilnehmer wichtig. Diese Daten werden im OCS-Client angezeigt oder auch von Exchange bei einer eingegangenen Sprachnachricht verwendet. (Siehe auch Reverse Name Lookup)

Gateway oder Lync/OCS

Auch Lync und OCS haben über den Dialplan die Möglichkeit, Rufnummern zu normalisieren. Aber ratsam ist das nicht.

Office Communications Server 2007 R2 Step 5. Deploy a Mediation Server
http://technet.microsoft.com/en-us/library/dd441327(office.13).aspx

Each gateway should be configured so that the E.164 numbers routed by Enterprise Voice to the gateway are normalized to a locally dialable format.

Each gateway should be configured to pass only E.164 numbers to the Mediation Server. Please see each gateway vendor's documentation für specific instructions on how to normalize source phone numbers to E.164.

Each gateway should be configured to convert the source number (the number presented as caller ID) to a normalized E.164 number. This ensures the caller ID can be matched to a Communicator contact, an Outlook contact, or a member of the corporate directory, thereby enabling Communicator to provide additional information about the caller. This number will also appear in e-mails notifying the user of missed calls and voice mail, allowing the user to click the phone number in order to quickly return a call. If the number has been normalized by the gateway, no further processing is required. If für some reason the number cannot be normalized by the gateway, the normalization rules defined by the location profile will be applied when returning a call. It might be necessary to add normalization rules to a location profile to handle numbers that cannot be normalized by the gateway. Please see each gateway vendor's documentation für specific instructions on how to normalize source phone numbers to E.164.

Das Gateway ist die Vermittlung zwischen Telefonwelt und IP-Welt und in der IP-Welt wird bevorzugt E.164 signalisiert, weil diese Nummern weltweit eindeutig sind. Allerdings nimmt die Anzahl der "SIP-Trunks zu und dann gibt es kein Gateway mehr zum ISDN.

Lync kann an zwei Stellen solche Übersetzungen vornehmen

  • Dialplan pro Gateway/PSTN
    Wenn Sie einen neuen "Pool-Dialplan" anlegen, dann können Sie auch die konfigurierten PBX-Gateways bzw. Trunks auswählen. Alle Rufe von diesen Geräten werden dann den hinterlegten Regeln unterworfen.
  • Trunkkonfiguration pro Gateway/PSTN
    An dieser Steller werden ausgehende Verbindungen normalisiert.

Hinweis: Ausgehend wird nur die "Gerufene" Nummer (CALLED Party Number) normalisiert.
Wer die rufende Nummer normalisieren will, muss das auf dem Gateway machen. für SIP-Trunks ist die Option hilfreich, wenigstens das "+" zu entfernen.

Ich persönlich bin ein Freund der Normalisierung auf dem Gateway, da dieses auch NPI/TON auswerten und setzen kann. Und SIP-Trunks sollten sowieso immer mit einer E.164-Nummer arbeiten. Das geht aber nicht mehr, wenn Lync direkt per SIP mit einer Gegenstelle verbunden ist.

Normalisierung mit Remote Call Control (RCC)

Leider wirken all die Einstellungen nur für Anwender mit "Enterprise Voice". Wenn Sie aber mit Lync gar nicht telefonieren sondern nur ihre "Telefonanlage" steuern, dann werden Sie schnell feststellen, dass die Rufnummern gar nicht anhand des Dialplans normalisiert werden. Und da die Anrufe auch nicht per SIP über den Mediation Server geroutet werden, können auch die Normalisierungen des Trunks nicht greifen. Wenn in dieser Konstellation eine Rufnummer normalisiert werden soll, dann ist dies eine Aufgabe des RCC-Gateways. In den meisten Fällen ist das RCC-Gateway aber sowieso hier gefordert um Namen und IP-Adressen mit Endgeräten zu "matchen".

Allerdings kann der Client durchaus eine beschränkte Normalisierung durchführen, indem er die Adressbuchregeln des Lync Adressbuch nutzt. Diese Funktion ist dann immer noch aktiv. Der Client lädt die Datei mit herunter und wendet sie auch.

Lync clients download phone number normalization rules as part of the Address Book Service (ABS) file download. In remote call control scenarios, Address Book Service phone number normalization rules are applied to both incoming and outgoing remote call control calls
http://technet.microsoft.com/en-us/library/gg558630.aspx

Leider gibt es hierbei genau eine Datei für die komplette Lync Umgebung. Abweichende Normalisierungen nach Standorten sind nicht möglich.

Daten erfassen

Ehe Sie nun schnell an die Planung einer Rufnummernnormalisierung gehen, müssen Sie erst einmal umfangreich die verwendeten Rufnummern und Anschlüsse erfassen. Das wird um so aufwändiger, je mehr Standorte und Querverbindungen dazu kommen. Daher sollten Sie zuerst eine Liste aller Standorte mit folgenden Daten erstellen:/p>

  • TK-Anlage
    Wenn es noch eine TK-Anlage vor Ort gibt, wovon auszugehen ist, dann sollten Sie den Typ, die Ausbaustufe und die Versionen möglichst genau erfassen
  • Landeskennzahl (+49) + Ortsnetzkennzahl (05251)
    Diese beiden Werte sind sicher noch einfach zu erheben, da Anlagen in der Regel in einem Ortsnetz angeschlossen sind
  • Anschlussnummer (304)
    Die "Trunknummer" ist einfach, wenn es genau einen Übergabepunkt gibt. Ich habe aber schon Kunden betreut, die mehrere Standorte im gleichen Ort hatten und mehrere Anlagen unter verschiedenen externen Rufnummern erreichbar waren. für OCS sind das dann doch besser eigene "Standorte", auch wenn es aus AD-Sicht keinen Sinn machen muss
  • Rufnummernblock (5, 600-699, 700-799)
    Über die Liste der vom TDM-Provider zugewiesenen Rufnummern erhält man sowohl die Länge als auch ausgeschlossene Blöcke o.ä.
  • Amtsholung (meist 0 in DE  oder 011 in den uSA)
    Viele Firmen nutzen eine "0" als Amtsholung. Ich habe aber auch schon gesehen, dass dreistellige Nummern als "intern" gelten und alles andere ein "automatisches Amt" bekommt. Auch gibt es Firmen, bei denen das Amt nicht durch eine "0" erreicht wird oder besondere Vorwahlen z.B.: ein "Privat-Amt schalten, was dann später gesondert abgerechnet wird (Thema Privatgespräch). All das muss bei der Rufnummernnormalisierung beachtet werden.
  • Sonderrufnummern (Notruf, Kurzwahlen, Querverbindungen etc.)
    Dann gibt es immer noch eine Menge von "Sonderrufnummern" oder vielleicht zentral eingerichtete Kurzwahlen, die in einem OCS Rufnummernplan mit berücksichtigt werden müssen.
  • Anbindung der TK-Anlage
    Zuletzt ist es auch interessant, welche technische Anbindung vorliegt, d.h. wird OCS als "Unteranlage" an eine bestehende PBX angeschlossen oder sitzt das Gateway zwischen Amtsanschluss und alter TK-Anlage oder kommt gar ein SIP-Trunk zum Einsatz

Je mehr und je vollständiger die Liste ist, desto weniger Nacharbeiten haben Sie hinterher. Ein Stück weit kann man so eine Rufnummernlandkarte mit der Aufstellung eines IP-Adressen-Konzepts vergleichen.

Globale VoIP Einstellungen: Location Profiles

Beachten Sie in dem Zusammenhang auch die Seite Location profiles - Standortprofil

Hier sehen Sie mal ein paar Muster, die auf dem OCS-Server eingestellt werden könnten. Natürlich müssen Sie ihre Regeln an die lokalen Gegebenheiten der Telefonanlage anpassen.

In dieser globalen Einstellung müssen Sie dafür sorgen, dass von Anwender später gewählte Rufnummern "Normalisiert" werden. Normalisiert heißt, dass diese der internationalen E.164 Konvention entsprechen. Hier ein Beispiel anhand des Standorts Paderborn, anhand dem Sie gut erkennen können, wie Sie per Regular Expressions aus gegebenen Rufnummern die vollständigen Nummern erstellen.

OCS Location Profiles

Die Regeln in Kürze noch einmal extrahiert für Standorte, in denen die Anwender gewöhnlich eine "0" zur Amtsholung wählen:

Regelname Suchpattern Ersetzen

Notruf 110

^110$

+495251110

E164 mit +

keine Regel möglich. Lync normalisiert keine Nummern, die mit "+" beginntn

entfällt

Sonderfall (0xxx)xx
Sonderfall (0)xx

^\(0(\d*)\)\D*(\d*)\D*(\d*)\D*(\d*)\D*(\d*)

+49$1$2$3$4$5

E164 normalisiert min 8 Stellen

^\+(\d{8,})

+$1

Welt 000

^000(\d+)

+$1

Deutschland ^00

^00(\d+)

+49$1

ONKZ0-5251

^0(\d+)

+495251$1

Intern3

(^\d{3})$

+495251304$1

Jochen Kunert hat auf seinem Blog auch ein Muster für Köln beschrieben:

Diese Regeln sollten Sie natürlich gegen eine ganze Menge von Nummernbeispielen testen, damit immer die richtige Regel zum tragen kommt. Die Reihenfolge ist hier ausschlaggebend, da die erste passende Regel angewendet wird. Das ist nicht immer einfach und etwas Übung mit regulären Ausdrücken ist schon vonnöten. Meine Testmuster zum Üben:

Gewählte Nummer Erwünschtes/Erwartetes Ziel Angewendete Regel Ergebnis

613

Interner Teilnehmer

Intern

+495251304613

01234

01234

Lokal PB

+4952511234

00401234

anderes Ortsnetz in Deutschland

Deutschland

+49401234

0001808867123

Rufnummer in den uSA

Welt

+1808867123

+495251304600

+495251304600

Keine. Lync normalisiert keine
Nummer mit führendem "+"

+495251304600

+49 (0) 5251304600

+495251304600 (trifft aber nicht zu

Keine. Lync normalisiert keine
Nummer mit führendem "+"

+4905251304600

Interessant werden solche Regeln natürlich nun, wenn es mehrere Standorte gibt und z.B. Querverbindungen zwischen Telefonanlagen zu berücksichtigen sind. Auch "Sparvorwahlen" (Call by call) oder besonders Zugangsrufnummern für Faxserver, Voicemail etc. sind gesondert in allen Schreibweisen zu berücksichtigen. Auch kann es ja sein, dass ein Anwender wirklich ein "+" in der Rufnummer verwendet. auch solche Dinge sollten abgefangen werden. Auch, dass Anwender z.B. "Leerzeichen", Klammern, Minus-Zeichen verwenden. In den uSA werden Telefonnummern gerne in der Form "+1 [123] 123-4567)" gespeichert. Und natürlich gibt es Ausnahmen wie z.B. Notrufe (110, 112 oder 911 (USA)) und andere Mehrwertdienste wie 0137, 0180, 0900, 0800, die alle bedacht sein wollen. Interessant ist hier auch die Option, den Ruf nach außen über die Preselection Testnummern zur Ansage des Providers zu prüfen

  • 031-0 Preselection Provider für Fernverbindungen ansagen
  • 031-1 Preselection Provider für Ortsverbindungen ansagen

Sie sollten zumindest ein Location Profil anlegen, um später bei der Mediation Server Konfiguration die Angaben auswählen zu können. 

Normalisierung in den uSA

Andere Länder, andere Sitten heißt es so schön und tatsächlich sind die Rufnummern und Normalisierungen in den uSA anders aber vor allem einfacher, denn die Rufnummern sind nach einem einfachen Schema aufgebaut:

+1<3DigitAreaCode><7DigitLocalNum>

Im Gegensatz zu Deutschland gibt es also keine unterschiedlich Lange Ortsvorwahlen und Anschlussnummern, sondern jede Nummer ist immer genau 7 oder 10 Stellen lang. Die Amerikaner denken nämlich erst "lokal" und so kommt es dann auch, dass ein Internationaler Call mit einer "011" beginnen muss. Trotzdem gibt es noch besondere "AreasCodes" wie z.B. 800 und 888 für kostenfreie Rufnummern oder 900 für die Schmuddelnummern. Die ersteren Will man später zulassen während die letzteren gerne gesperrt werden sollen. Dann gibt es noch einige wenige "dreistellige" Nummern wie 911 für den Notruf, die natürlich nicht als "Areacode" auftauchen können. Man darf also im Zuge einer Sperre der teuren 900er Nummern nicht irrtümlich ein 9* sperren. Mobilfunknummern sind in dem Zuge auch nicht an ihrer "Vorwahl" zu erkennen sondern sind ganz normale Nummern in der jeweiligen Gruppe, die vom Provider dann umgeleitet werden. Daher mag es auch herrühren, dass ein Anruf ins Mobilfunknetz den Anrufer nur den normalen Preis kostet und der angerufene Teilnehmer die Zusatzkosten trägt.

Wer also das erste Gateway in den uSA aufbaut, muss zum einen bei der Normalisierung für das Standortprofil die "Nummerneingabe" der Mitarbeiter verstehen um diese in E164 zu verwandeln und dann beim Gateway auch die richtige Nummer an den Telko-Provider zu senden und eingehende Nummern korrekt zu normalisieren.

Normalisierung mit Cisco

Es ist durchaus möglich Lync/OCS mit Cisco Call Manager zu verbinden. Allerdings scheint Cisco intern nur die Extension zu nutzen und hat wohl auch das ein oder andere Probleme mit dem "+" in den SIP-Nummern beim Trunk. Aus einer anderen Diskussion habe ich folgenden pragmatischen Vorschlag:

  • Rufe von Cisco -> Lync
    Cisco wird so eingestellt, dass es einfach die E164-nummer "ohne +" sendet, also etwa 495251304613 oder mit vielen "nullen" davor, z.B. 000495251304613. Über die Normalisierungsregeln von Lync wird daraus dann eine E164-Nummer (+495251304613) die von Lync auf die LineURI eines Benutzers umgesetzt werden kann.
  • Rufe von Lync->Cisco
    Hier scheint es mit dem "+" Probleme zu geben. Dennoch sollten in Lync intern nur komplette E164-Nummern verwendet werden. Aber auch dem SIP-Trunk Richtung Cisco kann man per PowerShell eintragen, dass das führende "+" entfernt wird, so dass bei Cisco dann wieder eine normale (meist 11-stellige) Nummer ankommen.

Set-CSTrunkConfiguration <trunkname> -RemovePlusFromURI $True

  • Cisco Translation
    Da Cisco intern den Benutzern aber auch nur "Extensions" zuweist und keine E164-Nummer, muss man hier noch mal mit Translations Patterns arbeiten, die aus der langen Rufnummer dann eine kurze Extension machen, z,B,
    "Translation Pattern: 495251304XXX / Called Party Transform Mask: XXX"
    Dies können Sie in der "CM Administration Console" unte"Call Routing > Translation Patterns" einstellen.

Ist ist also beileibe nicht nur eine Frage bei einer Verbindung von SIP und klassischer TK-Technik, sondern auch zwischen SIP-Systemen gibt es durchaus unterschiede in der Behandlung der Rufnummern.

OCS Globale VoIP Einstellungen: Routes

ähnlich wie bei IP-Leitwegen oder SMTP-Routingadressen von Exchange muss man auch dem OCS-Server sagen, welche angewählte Rufnummern an welches Gateway mit welcher Nummer weitergegeben werden sollen. Mit nur einem Gateway sieht die Konfiguration recht übersichtlich aus. Wenn man aber z.B. eigene Gateways in anderen Ländern betreibt, kann man auch hier ein Least Cost Routing betreiben, indem man die Daten über das eigene LAN an das entfernte Gateway sendet. Allerdings muss man dann auch wieder eventuell die Rufnummer umschreiben, um aus einem +495251304613 dann die passende "lokale Rufnummer" zu machen. Wenn das Gateway in Paderborn steht, dann brauche ich für einen lokalen Teilnehmer natürlich keine Vorwahl mit zu senden. Das folgende Bild zeigt eine unvollständige Routingkonfiguration

OCS ausgehendes Routing

Und dann kommt noch dazu, dass das Gateway die Rufnummer ja an die Telefonanlage überträgt. Sowohl auf dem Gateway als auch bei der Telefonanlage sind ähnliche Konfigurationen möglich. Sehr viele Telefonanlagen machen auch eine "Rufnummernnormalisierung" und ändern die Nummer abhängig von Regeln ebenfalls ab, so dass Sie sich hier natürlich abstimmen sollten, in welcher Form OCS die Rufnummern an das Gateway übergibt, welches dann der TK-Anlage Bescheid sagt.

Communicator Normalisierungsregeln

Auch der Office Communicator selbst hat lokal eine Liste von Normalisierungsregeln, die in der Registrierung sichtbar sind:

Communicator Normalisierungsregeln

Die Regeln sind ein langer String, der mit einigen Zeitenumbrüchen erkennen lässt, welche Nummern wie normalisiert werden.

E164 null

\++(\d+)([\s()\-\./]+(\d+))?([\s()\-\./]+(\d+))?([\s()\-\./]+(\d+))?([\s()\-\./]+(\d+))?([\s()\-\./]+(\d+))?([\s()\-\./]+(\d+))?([\s()\-\./]+(\d+))?([\s()\-\./]+(\d+))?([\s()\-\./]+(\d+))?([\s()\-\./]+(\d+))?\s*[Xx]+(\d{1,15})[\s]*

+$1$3$5$7$9$11$13$15$17$19$21;ext=$22


\++(\d+)([\s()\-\./]+(\d+))?([\s()\-\./]+(\d+))?([\s()\-\./]+(\d+))?([\s()\-\./]+(\d+))?([\s()\-\./]+(\d+))?([\s()\-\./]+(\d+))?([\s()\-\./]+(\d+))?([\s()\-\./]+(\d+))?([\s()\-\./]+(\d+))?([\s()\-\./]+(\d+))?[\s]*

+$1$3$5$7$9$11$13$15$17$19$21

Na ja, ein paar Kenntnisse in Regulären Ausdrücken sind schon erforderlich, um diesen Zeichensalat zu decodieren. Nach dem "E164 null" kommt ein Ausdruck der auf >nummern mit einem "X" als Abtrennung der Extension passt und dahinter die Ersetzungsregel. Der nächste Ausdruck teilt die anderen Nummern, um Sie wieder zusammen zu setzen.

E.164 mit Gateways und Mediation

Es gibt noch weitere Hinweise und Vorgaben von Microsoft, die eine korrekte und strikte Verwendung von E.164-Schreibweisen erfordert. Hier ein paar Zitate:

Each gateway must also be configured to pass only E.164 numbers to the Mediation Server. für details about how to normalize source phone numbers to E.164, see each gateway vendor’s documentation.

Each gateway should be configured to convert the source number (the number presented as caller ID) to a normalized E.164 number. This ensures the caller ID can be matched to an Office Communicator contact, a Microsoft Office Outlook contact, or a member of the corporate directory, thereby enabling Office Communicator to provide additional information about the caller.

Microsoft Office Communications Server 2007 R2 - Enterprise Voice Deployment Requirements
http://technet.microsoft.com/en-us/library/dd441140(office.13).aspx

Once a primäry number is chosen, it must be: - Normalized to E.164 format, wherever possible

If your organization maintains all telephone numbers in Active Directory in a single format, but that format is not E.164, then your script should define an appropriate normalization rule to convert primäry Telephone Numbers from their existing format to E.164 before writing them to the msRTCSIP-line attribute.

If your organization does not enforce a standard format für telephone numbers in Active Directory, then your script should define appropriate normalization rules to convert primäry Phone Numbers from their various formats to E.164 compliance before writing the primäry Telephone Numbers to the msRTCSIP-line attribute

http://technet.microsoft.com/en-us/library/bb803644.aspx
Planning to Move users to Enterprise Voice in Office Communications Server

As required by Microsoft, all AD numbers must be in E.164 format. All incoming call DID
numbers must be formatted für E.164; otherwise, the query fails
AudioCodes White Paper

Normalisierungsregeln sind daher nicht nur auf dem Client und OSA-Adressbuchserver sondern auch auf dem Gateway erforderlich.

Normalisierung überprüfen

Die einfachste Funktionsprüfung besteht natürlich darin, zu telefonieren. vier Dinge müssen in allen Kombinationen korrekt sein:

  • Ausgehend: Zielrufnummer
  • Ausgehend: Übermittelte Absender-Rufnummer
  • Eingehend: Erreichbarkeit der eigenen Nebenstelle
  • Eingehend: Übermittelte Rufnummer des Anrufers
Verbindung Ausgehend Eingehend
Zielnummer Angezeigte eigene Rufnummer Erreichbarkeit Anzeige des Anrufers

Intern

 

 

 

 

Gleiches Ortsnetz

 

 

 

 

National (Anderes Ortsnetz)

 

 

 

 

International

 

 

 

 

Mobilfunk

 

 

 

 

Sonderrufnummern

 

 

 

 

Querwahl zu anderen Standorten

 

 

 

 

Für diese und weitere Testfälle müssen die Rufnummern korrekt umgesetzt werden.

TEL-Uri beim Anwender

Die Rufnummer wird natürlich auch für die Anwender interessant. Bei der "Anschluss-URI" wird z.B.: beim Einsatz mit "Enterprise Voice" die Rufnummer hinterlegt. Hier sehen Sie auch die Warnung, wenn die E164 zu lange ist. Mit der Landeskennung darf die E.164 Nummer nicht länger sein als

Das ist insbesondere zu prüfen, wenn Sie intern als "Untervermittlung hinter einer großen TK-Anlage hängen und mit einer Ausscheidungsziffer angebunden sind.

Wichtig: Diese Nummer muss "eindeutig" sein, ähnlich wie eine SMTP-Adresse. Office 365 meldet z.B. solche Inkonsistenzen als Fehler

  • 2741233 You see validation errors für users in the Office 365 portal or in the Microsoft Online Services Module für Windows PowerShell

Weitere Links