Office Communications Server

Wie Remoteanrufsteuerung OCS 2007 R2 leistungsfähiger macht

Rajesh Ramanathan

Auf einen Blick:

• Was die Remoteanrufsteuerung kann
• Funktionsweise von RCC
• Allgemeine OCS-Szenarios für das Implementieren von RCC

Inhalt

Der CSTA-Standard
Bootstrapping des RCC-Kanals
Der grundlegende MakeCall-Fluss
Der grundlegende Fluss der Anrufbeantwortung
Integration von RCC und Anwesenheit
RCC und Konferenzen
RCC in Enterprise-VoIP mit PBX
Die Beschränkungen von RCC

Dieser Artikel ist eine Fortsetzung der Reihe, in der untersucht wird, wie Office Communications Server (OCS) 2007 ein einheitliches Kommunikationssystem, Voice over IP (VoIP) und Konferenzfeatures bietet. Im Folgenden wird besprochen, wie Office Communications Server das Feature der Remoteanrufsteuerung (Remote Call Control, RCC) mit Legacy-Nebenstellenanlagen (Private Branch Exchange, PBX) bereitstellt und wie verschiedene anrufbezogene Szenarios durch die RCC unterstützt werden können. Außerdem wird kurz auf die Dual Forking-Konfiguration eingegangen sowie darauf, wie RCC in dieser Konfiguration verwendet werden kann, um dem Benutzer eine flexible Option zu bieten und Anrufe entweder von Office Communicator oder dem PBX-Telefon aus zu tätigen und zu empfangen.

In meinem Artikel Wie Anwesenheit OCS 2007 leistungsfähiger macht habe ich einen Überblick über die OCS 2007-Lösung gegeben und das Zusammenwirken der verschiedenen Teile erläutert. Außerdem wurde erklärt, inwiefern die Anwesenheitsfunktionalität eine wichtige Rolle im einheitlichen Kommunikationssystem spielt und wie sie effektiv für das Weiterleiten von Sprachanrufen verwendet werden kann. Im Artikel Wie die Sprache OCS 2007 steuert habe ich erläutert, wie OCS VoIP-Funktionen bietet. Zudem habe ich kurz die verschiedenen Konfigurationsoptionen für einen Benutzer betrachtet, mit Schwerpunkt auf der Enterprise-VoIP-Konfiguration.

Eine andere Konfiguration, die kurz behandelt wurde, war RCC, das in Live Communication Server 2005 und Office Communicator 2005 enthalten ist, um Anrufe vom PBX-Telefon zu steuern. Bei OCS 2007 ist dieses Feature immer noch als alternative Konfiguration verfügbar, wenn es eine bereits vorhandene PBX-Bereitstellung gibt. Es gibt außerdem eine Option, RCC mit Enterprise-VoIP zu ermöglichen, sodass die Benutzer sowohl das PBX-Telefon als auch Office Communicator verwenden können, um ihre Anrufe zu verwalten.

RCC ist die Möglichkeit, Anrufe auf einem anderen Gerät als dem Computer zu senden oder zu empfangen. Für OCS bedeutet dies Folgendes:

• Wenn das PBX-Telefon klingelt, wird in Communicator eine Benachrichtigung angezeigt, die Ihnen ermöglicht, den Anruf zu beantworten.
• Wenn in Communicator auf die Telefonnummer einer Person geklickt wird, wird das PBX-Telefon in den Sprechmodus geschaltet und wählt die Nummer.
• Die Anrufweiterleitung kann auf dem PBX-Telefon festgelegt werden.
• Eingehende Anrufe können zu anderen Telefonnummern umgeleitet werden.
• Steuerungsereignisse mitten in einem Anruf, wie z. B. Single Step Transfer und Consultative Transfer, können für einen Anruf auf dem PBX-Telefon durchgeführt werden. DTMF-Signale können mithilfe der die Benutzeroberfläche in Communicator vom PBX-Telefon gesendet werden.

Abbildung 1 Die RCC-Konfiguration

Einer der großen Unterschiede zwischen der RCC- und der Enterprise-VoIP-Konfiguration besteht darin, dass in der RCC-Konfiguration Office Communicator-Clients einfach Signalsteuerungen bei der Nebenstellenanlage eingerichtet haben – es wird kein VoIP-Anruf an die Office Communicator-Clients gesendet. Anders gesagt, wird Office Communicator in diesen Konfigurationen nicht als Softphone verwendet.

In der einfachsten Konfiguration kann RCC bereitgestellt werden, indem ein SIP/CSTA-Gateway zwischen der Nebenstellenanlage und OCS eingerichtet wird. Das SIP/CSTA-Gateway bietet zur OCS-Seite hin eine Schnittstelle für das Session Initiation-Protokoll (SIP) und verwendet CSTA-Signalisierungsnachrichten (Computer-Supported Telecommunications Application), die sich innerhalb von SIP-Nachrichten befinden, um mit Office Communicator-Clients zu kommunizieren.

Zur PBX-Seite hin verwendet das SIP/CSTA-Gateway proprietäre anbieterspezifische PBX-Signalisierungsschnittstellen. Wie Sie in Abbildung 1 sehen können, nutzen RCC-Bereitstellungen die PSTN-Konnektivität, die von der Nebenstellenanlage bereitgestellt wird, um Anrufe in die PSTN-Welt zu tätigen. Solche Bereitstellungen nutzen auch das Voicemailsystem, das an die Nebenstellenanlage angeschlossen ist.

Abbildung 2 zeigt in einem logischen Diagramm, wie Sprache in einem RCC-System eingebunden ist. Wie Sie sehen können, erstellt der Office Communicator-Client eine Signalisierungssitzung, bei der Anrufsteuerungsnachrichten, die auf dem CSTA-Protokoll basieren, zwischen dem Office Communicator-Client und dem SIP/CSTA-Gateway fließen. Der eigentliche Anruf erfolgt zwischen dem PBX-Schreibtischtelefon und dem Remoteendpunkt, der ein anderes PBX-Schreibtischtelefon oder ein PSTN-Endpunkt sein kann – oder sogar ein anderer Enterprise-VoIP-fähiger Benutzer an einem OCS-Telefon.

Abbildung 2 Anrufe in einer RCC-Konfiguration

Der CSTA-Standard

Die RCC-Implementierung in Office Communicator basiert auf dem Technical Report-87 (TR-87) der ECMA (European Computer Manufacturers Association). Dies ist eine SIP-Implementierung des CSTA-Modells, das ebenfalls von der ECMA vorgeschlagen wird. Ein anderer Standard, ECMA 323, bietet das ausführliche Schema der XML-Nachrichten, die im SIP-Kanal gesendet werden, für eine CSTA-Implementierung. Office Communicator bietet eine Teilmenge der Funktionen und Methoden in TR-87. Eine ausführlichere Dokumentation zur Unterstützung des CSTA-Standards in Communicator ist über das Microsoft Connect-Programm verfügbar. Beachten Sie, dass sich CSTA im übrigen Teil des Artikels auf das generische Protokoll bezieht, das zwischen Office Communicator-Clients und der Nebenstellenanlage verwendet wird.

Bootstrapping des RCC-Kanals

Im Artikel „Wie Anwesenheit OCS 2007 leistungsfähiger macht“ wurde erläutert, inwiefern der SIP-URI (Uniform Resource Identifier) ein wichtiger Teil des OCS-Systems ist und wie jedem Benutzer ein SIP-URI zugewiesen wird, der das Weiterleiten von Anrufen an den Benutzer ermöglicht. Wenn Office Communicator-Clients mit einem SIP/CSTA-Gateway kommunizieren, müssen sie feststellen, welches Telefon Office Communicator steuern muss. Diese Telefonnummer ist als Anschluss-URI festgelegt, der im Grunde eine Telefonnummer im RFC 3966-Format ist. Diese Anschluss-URI-Eigenschaft ist in Active Directory im Datensatz des Benutzers gespeichert und wird für Office Communicator als Teil der bandinternen Bereitstellung verfügbar gemacht.

Während des Starts müssen Office Communicator-Clients auch mit dem SIP/CSTA-Gateway eine Verbindung herstellen (das entsprechend der Definition durch den Server-URI in der Benutzerkonfiguration in OCS behandelt wird), um einen beständigen INVITE-Kanal einzurichten. Communicator weiß, dass die RCC-Funktion und der Server-URI die bandinterne Bereitstellungsmethode verwenden (ebenfalls im Artikel „Wie Anwesenheit OCS 2007 leistungsfähiger macht“ erläutert).

Das RCC-System folgt dem Befehl/Antwort-Modell. Jede Nachricht, die Office Communicator dem SIP/CSTA-Gateway sendet, enthält einen Befehl, der als XML (ECMA 323)-Nutzlast codiert ist. Jede Antwort oder Benachrichtigung des SIP/CSTA-Gateways enthält auch eine XML (ECMA 323)-Nutzlast. Das erste SIP INVITE erstellt die Sitzung und enthält eine RequestSystemStatus-CSTA-Nachricht. Das SIP/CSTA-Gateway akzeptiert die Anforderung und antwortet mit einem RequestSystemStatusResponse im 200 OK (siehe Abbildung 3).

Abbildung 3 Invite-Modell mit SIP/CSTA-Gateway

Beachten Sie, dass es kein BYE gibt, das dem INVITE entspricht. Das liegt daran, dass das INVITE als dauerhafte Sitzung eingerichtet ist, auf der nachfolgende Befehle von Office Communicator gesendet oder Benachrichtigungen vom SIP/CSTA-Gateway empfangen werden können.

Nachdem die INVITE/200 OK-Sequenz abgeschlossen ist, fragt Office Communicator die Funktionen des SIP/CSTA-Gateways ab (das sich auf Funktionen der Nebenstellenanlage bezieht), um die unterstützten Features zu erkennen. Dann initiiert es die Überwachung der Telefonleitung.

Das Abfragen der Funktionen der Nebenstellenanlage ist ein wichtiger Schritt beim Bootstrapping. Je nach dem, welche Features auf der Nebenstellenanlage bzw. dem CSTA-Gateway unterstützt werden, sind verschiedene Benutzeroberflächenelemente in Office Communicator möglicherweise deaktiviert oder überhaupt nicht verfügbar. Wenn z. B. das Single Step Transfer-Feature für das SIP/CSTA-Gateway nicht unterstützt wird, zeigt Office Communicator in den Anrufsteuerungen die Übertragungsschaltfläche für einen Anruf nicht an.

Folglich erfordert eine RCC-Konfiguration zwei Parameter, die von Office Communicator-Clients genutzt werden. Zum einen den Server-URI, der ein SIP-URI ist, der die Adresse des SIP/CSTA-Gateways enthält und den Office Communicator-Clients ermöglicht, durch Übergabe eines SIP INVITE an den URI eine Verbindung zum Server herzustellen. (Dieser URI hat in der Regel die Form gateway@contoso.com.)

Zum anderen der Anschluss-URI, der ein TEL-URI ist, der die Telefonnummer im PBX-System eindeutig identifiziert. Dieser URI folgt dem RFC 3966-Format (z. B. TEL:+14255551212 oder TEL:4255551212;ext=1212).

Sobald das anfängliche Bootstrapping abgeschlossen ist, erhält Office Communicator von der Nebenstellenanlage Ereignisse, wenn bei der überwachten Telefonleitung, die durch eine Telefonnummer festgelegt ist, eine Statusänderung auftritt. Wenn Office Communicator einen Anruf zuführen oder beantworten muss, sendet es dem SIP/CSTA-Gateway eine INFO-Nachricht, die CSTA XML-Nachrichten enthält. Ereignisse, die vom SIP/CSTA-Gateway empfangen werden, enthalten CSTA XML-Nachrichten, die innerhalb der SIP-INFO-Nachrichten eingebettet wurden (siehe Beispiel in Abbildung 4).

Abbildung 4 INFO-Nachricht und 200 OK-Antwort

INFO sip:gateway@contoso.com SIP/2.0
From: <sip:alice@ocs.contoso.com>;tag=31424bf782;epid=77e47b4782
To: <sip:gateway@ocs.contoso.com>;tag=1fbe74b0
Call-ID: 52c4a528322d4457a486283ccf78b696
User-Agent: UCCP/2.0.6362.0 OC/2.0.6362.0 (Microsoft Office Communicator)
Content-Disposition: signal;handling=required
Content-Type: application/csta+xml
Content-Length: 277
<?xml version="1.0"?>
<MakeCall xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
  <callingDevice>tel:+14255551212;ext=1212</callingDevice>
  <calledDirectoryNumber>tel:+14258828080;ext=5555</calledDirectoryNumber>
  <autoOriginate>doNotPrompt</autoOriginate>
</MakeCall>

SIP/2.0 200 OK
From: <sip:alice@ocs.contoso.com>;tag=31424bf782;epid=77e47b4782
To: <sip:gateway@ocs.contoso.com>;tag=1fbe74b0
Call-ID: 52c4a528322d4457a486283ccf78b696
Content-Disposition: signal;handling=required
Supported: 100rel,replaces,timer
User-Agent: Example Gateway Release 1.0 version 4.2.3
Contact: <sip:gateway@ocs.contoso.com>
Content-Type: application/csta+xml
Content-Length: 247
<?xml version="1.0" encoding="UTF-8"?>
<MakeCallResponse xmlns="http://www.ecma-international.org/standards/ecma-323/csta/ed3">
  <callingDevice>
    <callID>17772</callID>
    <deviceID> tel:+14255551212;ext=1212</deviceID>
  </callingDevice>
</MakeCallResponse>

Beachten Sie, dass OCS in diesem Szenario als SIP-Proxy dient. Eine Signalisierungsnachricht zwischen Office Communicator-Clients und dem SIP/CSTA-Gateway wird durch den OCS-Server transparent weitergeleitet. Um sicherzustellen, dass das SIP/CSTA-Gateway ausgeführt wird und der signalisierende Link verfügbar ist, aktualisiert Office Communicator das INVITE-Dialogfeld alle 10 Minuten durch Senden eines Re-INVITE mit dem RequestSystemStatus-Befehl.

Der grundlegende MakeCall-Fluss

Die Sequenz für das Tätigen eines Anrufs ist in Abbildung 5 dargestellt. Der Benutzer kann durch Eingeben der Telefonnummer im Office Communicator-Suchfeld oder durch Auswählen der Telefonnummer in der Anrufen-per-Mausklick-Liste einen Anruf tätigen. Wenn der Benutzer sich entscheidet, eine Nummer zu wählen, sendet Office Communicator dem SIP/CSTA-Gateway einen MakeCall-Befehl, der die Telefonnummer enthält, die für den Anruf ausgewählt wurde. Die RCC-Schnittstelle ermöglicht nur, dass Benutzer Anrufe an die Telefonnummern tätigen. Wenn der Benutzer die Communicator Call-Option auswählt, um jemanden aufzurufen, führt Office Communicator einen VoIP-Anruf zum SIP-URI des Remotebenutzers zu.

Abbildung 5 Tätigen eines Anrufs

Die Nachrichtensequenz in Abbildung 5 zeigt, wie das SIP/CSTA-Gateway einen MakeCall-Befehl in proprietäre PBX-Nachrichten übersetzt. Das PBX-Telefon wird ausgeschaltet und platziert einen Anruf an die ausgewählte Telefonnummer.

Beachten Sie, dass die Schnittstelle zum SIP/CSTA-Gateway ausgefeilte Methoden bietet, um verschiedene Telefonzustände anzuzeigen. In diesem Beispiel können Sie sehen, dass mehrere Ereignisse von Office Communicator empfangen werden, die die Aktivität auf dem PBX-Telefon anzeigen. Diese beginnen mit dem OriginatedEvent (das anzeigt, dass das PBX-Telefon einen ausgehenden Anruf zuführt) zum DeliveredEvent (das einen Klingelstatus anzeigt). Wenn ein DeliveredEvent empfangen wird, ist es möglich, dass bereits ein Medienpfad zur Wiedergabe von Rückrufklängen zwischen dem Telefon und dem Remotebenutzer eingerichtet wurde.

Wenn der Anruf schließlich beantwortet wird, sendet die Nebenstellenanlage dem SIP/CSTA-Gateway die entsprechenden Signale, und ein EstablishedEvent wird an Office Communicator gesendet, um anzuzeigen, dass der Anruf beantwortet wurde (siehe Abbildung 6).

Abbildung 6 Der Anruf wurde beantwortet

Der grundlegende Fluss der Anrufbeantwortung

Wenn ein Anruf im PBX-System eingeht, informiert die Nebenstellenanlage das SIP/CSTA-Gateway, das wiederum eine DeliveredEvent-CSTA-Benachrichtigung erzeugt, die an Office Communicator gesendet wird (siehe Abbildung 7). Nachdem Office Communicator die DeliveredEvent-Benachrichtigung erhalten hat, wird die Benachrichtigung über den eingehenden Anruf dem Benutzer angezeigt.

Abbildung 7 Beantworten eines Anrufs

Office Communicator führt außerdem ein Reverse Name Lookup (RNL) anhand der Adressbuchdienst- und Microsoft Office Outlook-Kontakte des Benutzers durch, um einen Anzeigenamen für den entsprechenden Anrufer anzuzeigen. Der Benutzer kann jetzt den Anruf aus der Benachrichtigung beantworten, was einen AnswerCall-CSTA-Befehl an das SIP/CSTA-Gateway bewirkt. Nun konvertiert das SIP/CSTA-Gateway den AnswerCall in eine geeignete PBX-spezifische Antwortnachricht, und der bidirektionale Medienkanal zwischen dem Anrufer und dem PBX-Telefon wird eingerichtet.

Integration von RCC und Anwesenheit

Mit der RCC-Integration ist der Telefonstatus eines Benutzers nun in die Anwesenheitsfunktionalität integriert. Wann immer sich der Benutzer z. B. in einem Anruf in der Nebenstellenanlage befindet, ändert Office Communicator den Status des Benutzers in „Im Gespräch“. Dieser Status kann auf den Office Communicator-Clients anderer Benutzer angezeigt werden. Außerdem können Benutzer ihre persönlichen Telefonnummern über die Anwesenheitsfunktionalität veröffentlichen, damit sie von anderen Personen auf ihrem privaten oder geschäftlichen Telefon über Office Communicator angerufen werden können.

Beachten Sie jedoch Folgendes: Wenn die Office Communicator 2007-Anwesenheit auf „Nicht stören“ eingestellt ist, wird die Nicht-stören-Funktionalität des PBX-Systems nicht ausgelöst. Ein Benutzer muss den Status „Nicht stören“ auf dem PBX-System manuell verwalten.

RCC und Konferenzen

Office Communicator 2007 ermöglicht dem Benutzer in einem RCC-Anruf nicht, dem Anruf mithilfe von Office Communicator einen anderen Benutzer hinzuzufügen. Benutzer können aber immer noch eine Konferenz auf dem PBX-Telefon mithilfe der Konferenzfunktion des PBX-Telefons erstellen. Wenn dies geschieht, zeigt Office Communicator den Anruf weiterhin als Peer-to-Peer-Anruf und nicht als Konferenzanruf an.

Ähnlich wie bei der Ausweitung auf das Drei-Parteien-Szenario werden eingehende Konferenzanrufe auf dem PBX-Telefon als Peer-to-Peer-Anrufe in Office Communicator angezeigt und können als Peer-to-Peer-Anrufe in Office Communicator beantwortet werden.

RCC in Enterprise-VoIP mit PBX

RCC kann im Enterprise-VoIP-Szenario mit PBX-Integration (auch als Dual Forking bekannt) verwendet werden. In einem Enterprise-VoIP-Szenario mit PBX-Integration werden Anrufe sowohl an das PBX- als auch an das OCS-System geleitet, um dem Benutzer zu ermöglichen, für die Anrufbeantwortung sowohl das PBX-Telefon als auch das Office Communicator-Softphone zu verwenden. Diese Option ermöglicht Benutzern, alle Vorteile von Enterprise-VoIP zu nutzen.

Das Enterprise-VoIP-Szenario mit PBX-Integration und RCC-Anschluss bietet eine besondere Funktionalität: Benutzer können einen eingehenden Anruf am Telefon oder in Office Communicator von einer einzigen Benachrichtigung über einen eingehenden Anruf aus in Office Communicator beantworten (siehe Abbildung 8).

Abbildung 8 Auswählen eines Endpunkts zur Beantwortung eines eingehenden Anrufs

Außerdem können Benutzer mit Notebookcomputern Office Communicator als Softphone verwenden, um Anrufe außerhalb des Unternehmens zu tätigen. Benutzer haben sogar die Möglichkeit, Konferenzanrufe von Office Communicator aus zu erzeugen, indem sie die von den Office Communication Server-A/V-MCUs (Multipoint Control Units) bereitgestellten Konferenzfunktionen nutzen.

Die Beschränkungen von RCC

RCC bietet eine einfache Möglichkeit, um die Integration in eine vorhandene PBX-Bereitstellung zu implementieren. Die Funktionen eines RCC-fähigen Benutzers werden dadurch eingeschränkt, was das PBX-Telefon kann. Zum Beispiel kann ein Enterprise-VoIP-Benutzer die systemeigene OCS-Unterstützung für Outside Voice-Funktionen nutzen und VoIP-Anrufe sowohl innerhalb als auch außerhalb der Organisation tätigen und empfangen.

Das Enterprise-VoIP-Szenario ermöglicht außerdem mehrere Anwesenheitsfeatures, die OCS bietet (z. B. Anwesenheitszugriffsebenen für das Team, wodurch dringende Unterbrechungen während das Status „Nicht stören“ ermöglicht werden). Ein auf RCC beschränkter Benutzer hat keinen Zugriff auf diese Features. Darüber hinaus werden andere Features, wie z. B. das Erweitern einer Zwei-Parteien-Konferenz auf eine Mehrparteienkonferenz, ebenfalls nur für Enterprise-VoIP-Benutzer unterstützt.

In einem RCC-System ist die Nebenstellenanlage verantwortlich für die Anrufbearbeitungsregeln. Deshalb werden alle Einstellungen oder Regeln, die Anrufe automatisch weiterleiten oder an eine gemeinsam verwendete Leitung senden, tatsächlich von der Nebenstellenanlage gesteuert. Neue Features, die für Enterprise-VoIP-Benutzer verfügbar sind und in OCS 2007 R2 eingeführt wurden (wie z. B. das gleichzeitige Klingeln und das Delegierungsfeature), sind für einen auf RCC beschränkten Benutzer nicht verfügbar.

RCC-Konfigurationen sind so entworfen, dass sie auf eine an einem einzigen Standort bereitgestellte Nebenstellenanlage beschränkt sind. Deshalb werden mehrere standortspezifische Wählregeln für die RCC-Topologie nicht unterstützt. Im Gegensatz dazu ermöglicht eine Enterprise-VoIP-Konfiguration das Angeben mehrerer Standorte, und Benutzer an bestimmten Standorten erhalten Regeln für die Rufnummernnormalisierung, die für ihre Standorte spezifisch sind.

Dennoch bietet RCC eine praktische Möglichkeit, in bestimmten Szenarios Telefoniefeatures mit OCS zu bieten. Während es im Vergleich zu Enterprise-VoIP eine begrenzte Zahl von Features bietet, wenn es innerhalb einer Enterprise-VoIP-Konfiguration (für Dual Forking) verwendet wird, kann RCC Benutzern einen umfangreichen Satz an OCS-Features bieten, samt der Flexibilität, Anrufe sowohl von einem Schreibtischtelefon als auch von Office Communicator aus zu tätigen und zu empfangen.

Rajesh Ramanathan arbeitet derzeit als leitender Programmmanager im Office Communicator-Team. Er beschäftigt sich seit 14 Jahren mit Kommunikationstechnologie und hat Sprachprotokolle, Benutzerfunktionen sowie Sprach- und Konferenzfeatures für Office Communicator 2007 R2 entworfen. Sie erreichen Rajesh Ramanathan unter rajeshra@microsoft.com.