Reverse Name Lookup (RNL)

Bei eingehenden Anrufen übermitteln viele Gegenstellen ihre Rufnummer. Sowohl der Office Communicator als auch Exchange UM besitzen die Möglichkeit, diese Rufnummer zu suchen und mit einem entsprechenden Kontaktnamen zu ersetzen. Sowohl Exchange UM als auch der Communicator Client suchen an folgenden drei Stellen:

  1. UM-aktivierte Benutzer im gleichen UM Dialplan.
    Exchange 2007 UM prüft hier zuerst nach "passenden" Benutzern um damit z.B.: interne Anrufer sehr schnell und eindeutig zu identifizieren
  2. Outlook Kontakte
    Exchange UM als auch der Communicator prüfen die Outlook Kontakte.
  3. Active Directory anhand msRTCSIP-Line (Ab SP1)
    Sowohl Exchange UM als auch OCS nutzen das Feld "msRTCSIP-Line", um dann noch nicht aufgelöste Rufnummern über das Active Directory zu finden.

Zudem bekommt er noch einen Namen von...

  • Caller Name im SIP
    Mit einem Hotfix kann OCS nun auch die Namen von Anrufern im SIP-Paket anzeigen. Dazu muss z.B. die interne Telefonanlage auch den Namen z.B. per ISDN an das Gateway übertragen, welches dieses dann per SIP an den Mediation Server sendet.

Damit eine Rufnummer natürlich "gefunden" wird, muss sie auch der gängigen Namenskonvention entsprechen. Bei SIP hat es sich eingebürgert, die E.164-Schreibweise zu verwenden (also z.B. +495251304613) und beim Übergang in und von anderen Systemen die Nummern entsprechend zu normalisieren oder abzuwandeln.

Auf der Seite OCS Felder habe ich die Bedeutung von "msRTCSIP-Line" und warum dieses Feld zum Einsatz kommt, schon genauer beschrieben. Fakt ist, dass es nicht nur für Installationen mit vorhandenem OCS interessant ist, sondern auch für Exchange UM und dass das Feld keineswegs nur bei OCS-aktivierten Personen gesetzt sein sollte, sondern bei allen Objekten, die eine Telefonnummer besitzen und rückwärts auflösbar sein sollen.

Schade nur, dass Sie dies nicht über die GUI selbst setzen können, da dieses Feld nur bei OCS-aktivierten Benutzern mit dem OCS-SnapIn über die GUI erreichbar ist.

Info für Exchange 2007 UM Only
Wenn in ihrem Active Directory kein OCS installiert ist, dann fehlt auch die Schemaerweiterung und damit auch das Feld "msRTCSIP-Line". In diesem Fall können Sie diese Funktion zur Auflösung der Nummern nicht nutzen. Es ist aber denkbar, nur die OCS-Schemaerweiterung durchzuführen, um diese Funktion auch für Exchange 2007 bereit zu stellen.

Das Feld "msRTCSIP-Line" ist leider nur ein "Unicode-String" und nicht mehrwertig. Insofern können Sie pro Benutzer immer nur genau eine Rufnummer hinterlegen.

Namen über ISDN/SIP

Viele Telefonanlagen übermitteln per ISDN nicht nur die gerufene Nummer und anrufende Nummer, sondern auch den Anrufer-Namen, wenn dieser der Anlage bekannt ist. Das ist primär natürlich eine Funktion innerhalb von Firmen, wenn OCS als "Unteranlage" hinter einer Hausanlage angeschlossen ist. Dann kann die Telefonanlage die Namen der anderen klassischen internen Nebenstellen an das Gateway senden und über SIP durch den Mediation Server zum Anwender.

Damit der OCS Mediation Server diese Daten aber weiter sendet, benötigen Sie einen Fix und einen Eintrag in der Datei "MediationServerSvc.exe.config"

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
	<appSettings> 
		<key="forwardDisplayName" value="True">
	</appSettings>
</configuration>

Ob überhaupt Namen übertragen werden, können Sie natürlich mit einem ISDN-Trace auf dem Gateway (sofern das Gateway dieses anbietet) nachschauen. Auch ein Blick mit NETMON auf die SIP-Seiten zwischen Mediation Server zum Gateway kann ihnen zeigen, ob das Gateway den Namen auch zum Mediation Server sendet. Zumindest wenn sie auf dieser Seite kein TLS verwenden.

Nicht alle TK-Anlagen oder Amtsanschlüsse vertragen übrigen einen "Namen im ISDN". Bei einem Kunden in den uSA ist genau das passiert und letztlich hat es dann geholfen, auf dem Mediant die Weitergabe der Namen zu unterbinden

Configuration->Protocol Configuration->Digital Gateway->Digital Gateway Parameters
  Web/EMS: Remove Calling Name [RemoveCallingName] = Enable

Lync Mediation Server

Der Lync Mediation Server sendet per Default auch einen Namen im SIP-Paket an das Gateway.

Namen über QSIG

Oft wird Lync mit TK-Anlagen über QSIG angesprochen. Eigentlich ist das "auch" nur ISDN nur eben mit einem erweiterten Befehlssatz, damit man z.B. Anlagen miteinander koppeln kann. Im Endkundenbereich kommt QSIG in der Regel nicht vor. Aber gerade hier ist es mit Lync natürlich auch interessant, die Namen zu übertragen.

ISO-QSIG verwendet von Hause aus ISO 8859-1 für die Übertragung von Sonderzeichen. Dieser Characterset ist für westeuropäischen Länder natürlich perfekt geeignet um alle Sonderzeichen der lateinischen Schrift darzustellen. Der OCS Mediation Server verwendet aber UTF-8 als Zeichensatz. Diese ist für das normale Alphabet Identisch bei ISO oder ANSI. Sonderzeichen werden aber dann als 16-Bit Codierung übertragen. Hier muss ein Gateway aufpassen und umkonvertieren, damit Sonderzeichen auch in der jeweils anderen Welt ankommen.

Leider liefert Lync bei einem eingehenden Ruf aus der TK-Welf mit der Rückantwort keine Displaynamen des Lync Teilnehmers beim "SIP-RINGING" zurück. Damit kann das Gateway auch keinen Namen in der ISDN ALERT an die TK-Anlage senden. Eine Anzeige des Namens des angerufenen Teilnehmers ist somit nicht möglich.

Skript1: Fill-msRTCSIP-Line

In einem Active Directory Forest gibt es oft sowohl OCS-aktivierte Benutzer als auch Benutzer ohne OCS-Felder, die z.B. ein klassisches Telefon verwenden. Ohne Anpassungen werden aber die "Telefonbenutzer" nicht im OCS über den Namen aufgelöst. Da sie nun um die Bedeutung von "msRTCSIP-Line" wissen, ist die Lösung einfach.

Beim Lync 2013-Server habe ich im Diagnoselog des ABServer gesehen, dass er auch Objekte in das Adressbuch addiert, die nur das Feld "TelephoneNumber" und "mobile" haben. Das Feld msRTCSIPLine muss scheinbar nicht mehr gefüllt sein.

Ein Skript kann einfach alle Benutzer suchen und die hoffentlich korrekt gepflegte Telefonnummer (Siehe Rufnummern) im Active Directory in das OCS-Feld übertragen.

Der folgende Code macht das "nur" für AD-Kontakte in einer vorgegebenen OU.

set objOU =GetObject("LDAP://cn=users,dc=msxfaq,dc=dc") für each objContact in objOU
	strTelephoneNumber=objContact.Get("telephoneNumber")
	If trTelephoneNumber <> ""Then
		strMsRTCSIPLine="tel:" & strTelephoneNumber
		objContact.Put "msRTCSIP-Line",strMsRTCSIPLine
		objContact.SetInfo
	End If
Next

Ein leistungsfähigeres Skript könnte natürlich alle Objekte bearbeiten und die Objekte selektieren, bei denen das Feld noch leer ist. Auch wäre eine etwas leistungsfähigere Normalisierung in E.164-Schreibweise wünschenswert.

PowerShell

Mit Hilfe der Quest Active Directory AddOns können Sie auch sehr einfach auf das Feld "msRTCSIP-Line" zugreifen.

Get-QADUser 
   -DontUseDefaultIncludedProperties 
   -IncludedProperties ‘msRTCSIP-Line’,name 
   -ObjectAttributes @{’msRTCSIP-Line’='*’} 
| format-table name,’msRTCSIP-Line’

Das Ergebnis ist eine Liste der Benutzer mit einer entsprechenden Adresse. Wenn Sie aber alle Kontakte mit einer msRTCSIP-Line versehen, dann sollten Sie vielleicht noch auf die "msRTCSIP-OptionFlags" schauen, um nur die OCS-Benutzer aufzulisten.

Skript2: FixOutlookTel

Der Communicator Client nutzt auch das lokale Outlook, um Nummern zu Namen aufzulösen. Auch hier ist es natürlich erforderlich, dass die Rufnummern "auffindbar" sind. Kaum jemand pflegt aber die Rufnummern im E.164 Format. Es sind sehr verschiedene Schreibweisen zu finden. Dieses VBA-Makro hilft bei der korrekten Speicherung der Outlook Kontakte.

Dieses VBA-Makro kann der Anwender selbst ausführen, um die Telefonnummern in dem ausgewählten Kontaktordner zu "normieren". Das Skript geht davon aus, dass der Anwender in Deutschland (+49-Prefix) ist und Rufnummern unter 6 Stellen intern sind.

Dazu muss er aber seine eigenen Standortdaten (Landeskennzahl +49 und Ortsnetz (OKNZ) angeben, damit das Skript die Rufnummern möglichst fehlerfrei normieren kann. Das Skript muss vom Benutzer selbst aufgeführt werden und bearbeitet alle Kontakte in dem ausgewählten Ordner.

Dieses Skript nutzt ich aktuell nur in Kundenprojekte, um die Normalisierung weiter zu überprüfen. Sie glauben gar nicht, welche "Sonderfälle" so alles abzufangen sind. Es gibt noch kein Skript, welches durch alle Kontakte aller Postfächer durchläuft.

Weitere Links