How Remote Call Control Powers OCS 2007 R2

[LEFT]Office Communications Server
How Remote Call Control Powers OCS 2007 R2
Rajesh Ramanathan

At a Glance:

[LIST][*]What Remote Call Control can do[*]How RCC works[*]Common OCS scenarios for implementing RCC[/LIST]

[IMG]http://i.msdn.microsoft.com/Global/Images/clear.gif[/IMG] Contents
[B]The CSTA Standard
Bootstrapping the RCC Channel
The Basic MakeCall Flow
The Basic Answer Call Flow
RCC and Presence Integration
RCC and Conferencing
RCC in Enterprise Voice with PBX
The Limitations of RCC
[/B]


This article is a continuation of the series covering how Office Communications Server (OCS) 2007 provides unified communication, Voice over IP (VoIP), and conferencing features. Here I'll discuss how Office Communications Server provides the Remote Call Control (RCC) feature with legacy PBXs and how various call-related scenarios can be supported using RCC. I also touch briefly on the dual forking configuration and how RCC can be used in that configuration to provide a flexible option for the user to make and receive calls from either Office Communicator or the PBX phone.
In my article "[URL="http://technet.microsoft.com/magazine/cc194409"]How Presence Powers OCS 2007[/URL]," I gave an overview of the OCS 2007 solution, explaining how various pieces fit together. I also explained how presence plays a key role in the unified communication and how it is used for effectively routing voice calls. In "[URL="http://technet.microsoft.com/magazine/cc645016"]How Voice Powers OCS 2007[/URL]," I discussed how OCS provides VoIP capabilities. I also took a brief look at various configuration options for a user, focusing on Enterprise Voice configuration.
Another configuration I briefly touched upon was RCC, which shipped with Live Communication Server 2005 and allows Office Communicator 2005 to control calls from the PBX phone. With OCS 2007, this feature is still available as an alternate configuration when there is an existing PBX deployment. There is also an option to enable RCC with Enterprise Voice, where users can use both the PBX phone as well as Office Communicator to manage their calls.
RCC is the ability to send or receive calls on a device other than your computer. For OCS, this means the following:

[LIST][*]When the PBX phone rings, an alert appears in Communicator that allows you to answer the call.[*]When someone's phone number is clicked on Communicator, the PBX phone goes off-hook in speakerphone mode and dials the number.[*]Call forwarding can be set on the PBX phone.[*]Incoming calls to the number can be deflected to other phone numbers.[*]Mid-call control events, such as Single Step Transfer and Consultative Transfer, can be performed on a call on the PBX phone. DTMF signals can be sent from the PBX phone using UI in Communicator.[/LIST]

[IMG]http://i.technet.microsoft.com/dd440963.fig01_new_a%28en-us%29.gif[/IMG] Figure 1 [B]The RCC configuration [/B]

One of the big differences between RCC and Enterprise Voice configuration is that in the RCC configuration, Office Communicator clients just have signaling controls set up with the PBX—there is no VoIP call sent to the Office Communicator clients. In other words, Office Communicator is not being used as a softphone in these configurations.
In the simplest configuration, RCC can be deployed by setting up a SIP/CSTA Gateway between the PBX and OCS. The SIP/CSTA Gateway provides a Session Initiation Protocol (SIP) interface toward the OCS side and uses Computer-Supported Telecommunications Application (CSTA) signaling messages wrapped inside of SIP messages to communicate with Office Communicator clients.
Toward the PBX side, the SIP/CSTA gateway uses proprietary PBX vendor-specific signaling interfaces. As you can see in [B]Figure 1[/B], RCC deployments leverage the public switched telephone network (PSTN) connectivity that is provided by the PBX to make calls out to the PSTN world. Such deployments also leverage the voicemail system that is attached to the PBX.
[B]Figure 2[/B] shows the logical diagram of how voice calls fit into an RCC system. As you can see, the Office Communicator client creates a signaling session where call control messages that are based on the CSTA protocol flow between the Office Communicator client and the SIP/CSTA gateway. The actual call itself is between the PBX desk phone and the remote endpoint, which can be another PBX desk phone or a PSTN endpoint—or even another Enterprise Voice-enabled user on an OCS phone.
[IMG]http://i.technet.microsoft.com/dd440963.fig02_new%28en-us%29.gif[/IMG] Figure 2 [B]Calls in an RCC configuration [/B]


The CSTA Standard
RCC implementation in Office Communicator is based on the European Computer Manufacturers Association (ECMA) Technical Report-87 (TR-87). This is a SIP implementation of the CSTA model also proposed by ECMA. Another standard, ECMA 323, provides the detailed schema of the XML messages that are sent in the SIP channel for a CSTA implementation. Office Communicator follows a subset of the capabilities and methods in TR-87. More detailed documentation about support for the CSTA standard in Communicator is available through the [URL="http://connect.microsoft.com/"]Microsoft Connect program[/URL]. Note that throughout the rest of this article, CSTA refers to the generic protocol that is used between Office Communicator clients and the PBX.

Bootstrapping the RCC Channel
In the "How Presence Powers OCS" article, I explained how the SIP Uniform Resource Identifier (URI) is an important part of the OCS system and how each user is assigned a SIP URI that allows calls to be routed to the user. When Office Communicator clients talk to a SIP/CSTA Gateway, they need to identify what phone Office Communicator needs to control. This phone number is identified as a Line URI, which is basically a telephone number in RFC 3966 format. This Line URI property is stored in Active Directory in the user's record and is made available to Office Communicator as part of inband provisioning.
During startup, Office Communicator clients also need to connect to the SIP/CSTA gateway (which is addressed as defined by the Server URI in the user configuration in OCS) to set up a persistent INVITE channel. Communicator knows about the RCC capability and the Server URI using the inband provisioning mechanism (also explained in the article "How Presence Powers OCS").
The RCC system follows a command/­response model. Each message that Office Communicator sends to the SIP/CSTA Gateway contains a command encoded as an XML (ECMA 323) payload. Each response or notification from the SIP/CSTA Gateway also contains an XML (ECMA 323) payload. The first SIP INVITE creates the session and contains a RequestSystemStatus CSTA message. The SIP/CSTA Gateway accepts the request and responds with a RequestSystemStatusResponse in the 200 OK (see [B]Figure 3[/B]).
[IMG]http://i.technet.microsoft.com/dd440963.fig03_new%28en-us%29.gif[/IMG] Figure 3 [B]Invite model with SIP/CSTA Gateway [/B]

Notice that there is no BYE corresponding to the INVITE. This is because the INVITE is set up as a long-lasting session on which subsequent commands from Office Communicator can be sent or notifications received from the SIP/CSTA Gateway.
Once the INVITE/200 OK sequence is completed, Office Communicator queries the capabilities of the SIP/CSTA Gateway (which relates to capabilities of the PBX) to discover the supported feature set. And then it initiates monitoring on the phone line.
Querying the capabilities of the PBX is an important step in bootstrapping—depending on what features are supported on the PBX/CSTA Gateway, various UI elements in Office Communicator may be disabled or may not be available at all. For example, if the Single Step Transfer feature is not supported on the SIP/CSTA Gateway, Office Communicator will not show the transfer button for a call in the call controls.
Thus an RCC configuration requires two parameters that are consumed by the Office Communicator clients. First is Server URI, which is a SIP URI that contains the address of the SIP/CSTA gateway and allows the Office Communicator clients to connect to the server by issuing an SIP INVITE to the URI. (This URI is usually of the form [EMAIL="gateway@contoso.com"]gateway@contoso.com[/EMAIL].)
Second is Line URI, which is a TEL URI that uniquely identifies the phone number in the PBX system. This URI follows the RFC 3966 format (for instance, TEL:+14255551212 or TEL:4255551212;ext=1212).
Once the initial bootstrapping is completed, Office Communicator receives events from the PBX whenever a status change occurs on the monitored phone line as specified by a telephone number. When Office Communicator needs to originate or answer a call, it sends an INFO message that contains CSTA XML messages to the SIP/CSTA Gateway. Events received from the SIP/CSTA Gateway also contain CSTA XML messages embedded within SIP INFO messages (see [B]Figure 4[/B] for an example).
[IMG]http://i.msdn.microsoft.com/Global/Images/clear.gif[/IMG] Figure 4 INFO message and 200 OK response
[CODE]
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>

[/CODE]Note that OCS serves as a SIP Proxy in this scenario. Any signaling messages between Office Communicator clients and the SIP/CSTA Gateway are passed through transparently by the OCS server. To ensure that the SIP/CSTA Gateway is running and the signaling link is available, Office Communicator refreshes the INVITE dialog every 10 minutes by sending a Re-INVITE with the RequestSystemStatus command.

The Basic MakeCall Flow
The sequence of making a call is highlighted in [B]Figure 5[/B]. The user can make a call to a number by typing in the number in the Office Communicator search box or by selecting the phone number of a contact from the click-to-call list. When the user selects to call a number, Office Communicator issues a MakeCall command to the SIP/CSTA Gateway that contains the phone number that is selected for the call. The RCC interface only lets users make calls to the phone numbers. When the user selects the Communicator Call option to call someone, Office Communicator originates a VoIP call to the remote user's SIP URI.
[IMG]http://i.technet.microsoft.com/dd440963.fig05_L%28en-us%29.gif[/IMG] Figure 5 [B]Making a call [/B]

The message sequence in [B]Figure 5[/B] shows how the SIP/CSTA Gateway translates a MakeCall command into proprietary PBX messages; the PBX phone goes off-hook and places a call to the selected phone number.
Notice that the interface to the SIP/CSTA Gateway provides elaborate mechanisms to indicate various states of the phone. In this example, you can see that there are multiple events being received by Office Communicator that indicate the activity on the PBX phone. These start with the OriginatedEvent (indicating that the PBX phone is originating an outgoing call) to the Delivered­Event (indicating a Ringing state). By the time a Delivered­Event is received, it is possible that a media path for playing ringback sounds has already been established between the phone and the remote user.
When the call is finally answered, the PBX sends the appropriate signals to the SIP/CSTA Gateway and an EstablishedEvent is sent to Office Communicator indicating that the call has been answered (see [B]Figure 6[/B]).
[IMG]http://i.technet.microsoft.com/dd440963.fig06_L%28en-us%29.gif[/IMG] Figure 6 [B]The call has been answered [/B]


The Basic Answer Call Flow
When a call comes into the PBX system, the PBX informs the SIP/CSTA Gateway, which in turn originates a DeliveredEvent CSTA notification sent to Office Communicator (see [B]Figure 7[/B]). Once Office Communicator receives the DeliveredEvent notification, the incoming call notification is shown to the user.
[IMG]http://i.technet.microsoft.com/dd440963.fig07_L%28en-us%29.gif[/IMG] Figure 7 [B]Answering a call [/B]

Office Communicator also performs Reverse Name Lookup (RNL) against the Address Book Service and Microsoft Office Outlook contacts of the user to show a display name for the corresponding caller. The user can now answer the call from the notification, resulting in an AnswerCall CSTA command to the SIP/CSTA Gateway. At this point, the SIP/CSTA Gateway converts the AnswerCall to an appropriate PBX specific answer message and the two-way media channel is set up between the caller and the PBX phone.

RCC and Presence Integration
With the RCC integration, a user's phone status is now integrated with presence. For example, whenever the user is in a call on the PBX, Office Communicator will change the user's status to In a Call. This status can be viewed on other users' Office Communicator clients. Additionally, users can publish their personal phone numbers through presence so other people can call them on their home or mobile numbers through Office Communicator.
But note that when the Office Communicator 2007 presence is set to Do Not Disturb, the PBX system's Do Not Disturb capability isn't triggered. A user must manually manage the Do Not Disturb state on the PBX system.

RCC and Conferencing
When in an RCC call, Office Communicator 2007 does not allow the user to add another user to the call using Office Communicator. However, users can still create a conference on the PBX phone by using the PBX phone's conferencing capability. When this occurs, Office Communicator continues to show the call as a peer-to-peer call, instead of a conference call.
Similar to the escalation to three-party scenario, incoming conference calls on the PBX phone appear as peer-to-peer calls on Office Communicator and can be answered as peer-to-peer calls on Office Communicator.

RCC in Enterprise Voice with PBX
RCC can be used in the Enterprise Voice scenario with PBX integration (also known as dual forking). In an Enterprise Voice with PBX integration scenario, both the PBX and OCS systems fork calls toward each other to allow the user to use either the PBX phone or the Office Communicator softphone to answer calls. This option allows users to leverage all the benefits of Enterprise Voice.
The Enterprise Voice with PBX integration scenario with RCC added on provides a unique experience: users are able to answer an incoming call on the phone or on Office Communicator from a single incoming call notification in Office Communicator (see [B]Figure 8[/B]).
[IMG]http://i.technet.microsoft.com/dd440963.fig08%28en-us%29.gif[/IMG] Figure 8 [B]Choosing an endpoint to answer an incoming call [/B]

In addition, users with notebook computers can use Office Communicator as a softphone to make calls when outside corporate premises. User even have the ability to create conference calls from Office Communicator by leveraging the conferencing capabilities provided by the Office Communication Server A/V multipoint control units (MCUs).

The Limitations of RCC
RCC provides an easy way for achieving integration with an existing PBX deployment. However, an RCC-enabled user's capabilities are limited by what the wired PBX phone can do. For example, an Enterprise Voice user can leverage native OCS support for outside voice capabilities and make and receive VoIP calls from both inside and outside the organization.
Enterprise Voice scenario also enables several presence features that OCS provides (such as Presence access levels to Team, allowing urgent interruptions during Do Not Disturb). An RCC-only user will not have access to these features. In addition, other features, such as escalating two-party conferences to a multi-party conference, are also only supported with Enterprise Voice users.
In an RCC system, the PBX is the master of the call-handling rules. Therefore, any settings or rules that divert calls automatically or send these to a shared line are actually controlled at the PBX. New features available to an Enterprise Voice user, such as Simultaneous Ringing and the Delegation feature introduced with OCS 2007 R2, are not available for an RCC-only user.
RCC configurations are designed to be limited to a PBX deployed in a single location. This is why multiple location-specific dialing rules are not supported for RCC topology. In contrast, an Enterprise Voice configuration allows multiple locations to be specified and users in specific locations receive number normalization rules that are specific to their locations.
Nevertheless, RCC offers a handy way to provide telephony features with OCS in certain scenarios. While it offers a limited feature set compared to Enterprise Voice, when used within an Enterprise Voice configuration (for dual forking), RCC can give users a rich set of OCS features along with the flexibility to make and receive calls from either a desk phone or Office Communicator.



[/LEFT]