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.
- Wikipedia: E.164
http://en.wikipedia.org/wiki/E.164 - RFC3966 The tel URI für Telephone Numbers
http://tools.ietf.org/html/rfc3966 - E.123
http://de.wikipedia.org/wiki/E.123 - Wikipedia: Liste der Landesvorwahlen
http://en.wikipedia.org/wiki/List_of_country_calling_codes - Communicator and OCS Tech Tip #4: updating your Outlook Contacts
http://blogs.technet.com/brettjo/archive/2008/08/07/communicator-and-ocs-tech-tip-4-updating-your-outlook-contacts.aspx - Kommerzielles Tool zum Konvertieren der Rufnummern
http://www.outlook-stuff.com/lang-de/produkte/kontakte/228-formatnumbers.html
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) |
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 |
|
2 = National |
Eine nationale Nummer im E164 Format
ohne Ländercode |
|
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":
- 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)
- Dial Plans and Normalization
Rules
http://technet.microsoft.com/en-us/library/gg413082.aspx - Lync Inbound Normalization
Rules
http://voipnorm.blogspot.com/2010/12/lync-inbound-normalization-rules.html - More on Lync Inbound
Normalization
http://voipnorm.blogspot.com/2011/01/more-on-lync-inbound-normalization.html
Sehr schöne Bilder zur Normalisierung aber leider nicht gemäß der Empfehlung, dass das Gateway normalisieren soll - OCS / Lync Server
Normalization Rule primär
https://portal.t2mdev.com/jonmck/Lists/Posts/Post.aspx?ID=6 - The New Translation Rule
Dialog
http://blogs.technet.com/b/csps/p/uimap59.aspx
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.
- Lync Enterprise Voice Best
Practices - Normalization
http://ucken.blogspot.com/2011/01/enterprise-voice-best-practices-in-lync.html - Normalizing Outlook Contact
Phone Numbers to E.164 Format
http://ucken.blogspot.com/2010/08/normalizing-outlook-contact-phone.html - Dialing Rule Optimizer
http://www.lyncoptimizer.com/
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.
- Remote Call Control Features
Not Working
http://technet.microsoft.com/en-us/library/gg195713.aspx - Configuring Normalization
Rule für RCC (Remote Call Control)
http://demagnum.wordpress.com/2012/07/18/configuring-normalization-rule-for-rcc-remote-call-control/ - Lync Normalization Rules,
RCC and You
http://ucken.blogspot.de/2011/10/lync-normalization-rules-rcc-and-you.html
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.
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 |
^\(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:
- OCS 2007 German dialplan example
http://blogs.technet.com/jkunert/archive/2008/08/27/ocs-2007-german-dialplan-example.aspx - Phone Number Normalization Rule Regular Expressions
http://office.microsoft.com/en-us/help/phone-number-normalization-rule-regular-expressions-HP010290159.aspx - Adding Extensibility to the Office Communicator 2007
PE "Quick Dial" Feature
http://communicatorteam.com/archive/2008/06/02/263.aspx
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 |
+495251304600 |
+49 (0) 5251304600 |
+495251304600 (trifft aber nicht zu |
Keine. Lync normalisiert keine |
+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.
- http://en.wikipedia.org/wiki/North_American_Numbering_Plan
- Dialing Rule Optimizer
https://lync.buchanan.com/LyncOptimizer/
Funktioniert aber nur im amerikanischen Raum
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
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:
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
- Regular Expressions
- Enterprise Voice Route Helper
- OCS Adressbuch
- OCS Felder
- Location profiles - Standortprofil
- Reverse Name Lookup
- Exchange 2007 understanding Unified Messaging Dial Plans
http://technet.microsoft.com/en-us/library/bb125151.aspx - Computer Supported Telecommunications Applications (CSTA)
http://www.ecma-international.org/activities/Communications/TG11/cstaIII.htm - Work Number displays as '+' on Phone Edition and fails on
attempted dial
http://blogs.technet.com/toml/archive/2008/06/02/work-number-displays-as-on-phone-edition-and-fails-on-attempted-dial.aspx - 913092 A custom telephone number normalization rule is not applied by the Live Communications Server 2005 SP1 version of the Address Book Service (AbServer.exe)
- 925052 Telephone number normalization rules do not work as expected in Communicator 2005
- Reverse number lookup in Office Communicator
http://www.robichaux.net/blog/2006/09/reverse_number_lookup_in_office_communic.php - Enabling Custom Phone Number Normalization with the Address Book Service
http://blogs.pointbridge.com/Blogs/schertz_jeff/Pages/Post.aspx?_ID=17 - More on OCS Phone Number Normalization
http://blogs.pointbridge.com/Blogs/schertz_jeff/Pages/Post.aspx?_ID=26 - SER and Microsoft OCS
http://www.voip-info.org/wiki/view/SER+and+Microsoft+OCS - Exchange 2007 How to Add, Remove, or Modify Extension Numbers für a UM-Enabled User
http://technet.microsoft.com/en-us/library/bb232208.aspx - How to Add, Remove, or Modify a SIP Address für a UM-Enabled User
http://technet.microsoft.com/en-us/library/bb691029.aspx - How to Add, Remove, or Modify an E.164 Address für a UM-Enabled User
http://technet.microsoft.com/en-us/library/bb676579.aspx - Exchange 2007 understanding Unified Messaging Dial Plans
http://technet.microsoft.com/en-us/library/bb125151.aspx - Communicator and OCS Tech Tip #4: updating your Outlook Contacts
http://blogs.technet.com/brettjo/archive/2008/08/07/communicator-and-ocs-tech-tip-4-updating-your-outlook-contacts.aspx - Kommerzielles Tool zum Konvertieren der Rufnummern
http://www.outlook-stuff.com/lang-de/produkte/kontakte/228-formatnumbers.html - OCS R2 now supports Caller ID (with caller's name)
http://cytraxtech.blogspot.com/2009/08/ocs-r2-now-supports-caller-id-with.html - ISDN Fehlermeldungcodes
http://www.zytrax.com/tech/protocols/isdn/cause.htm - NPI
http://en.wikipedia.org/wiki/Numbering_Plan_Indicator - Company Wide Speed Dial in OCS
http://ocsguy.com/2010/07/05/company-wide-speed-dial-in-ocs/ - Phone Numbers and Dial Plans in Office Communications Server
http://blogs.technet.com/b/dougl/archive/2009/06/25/phone-numbers-in-ocs.aspx - Dialing Rule Optimizer
https://lync.buchanan.com/LyncOptimizer/
Funktioniert aber nur im amerikanischen Raum - Nummerierungskonzept nach § 2 der Telekommunikations-Nummerierungsverordnung
(TNV)
https://www.bundesnetzagentur.de/DE/Sachgebiete/Telekommunikation/Unternehmen_Institutionen/
Nummerierung/Nummerierungskonzept/nummerierungskonzept_node.html