Chapter 9. Understanding Remote Call Control Scenario

In this chapter:

Why Consider Remote Call Control? 320

Summary 339

Many standard office environments have workspaces that contain a computer running a Microsoft operating system and Microsoft Office, and a Private Branch eXchange (PBX) or IP PBX phone. Typical information workers perform their daily work using this standard technology environment. In daily workflow, calls are placed to phone numbers of contacts whose contact information is located in Microsoft Office Outlook or the Global Address List, based on data stored by Microsoft Active Directory Domain Services. Without the ability to place a phone call directly from the desktop computer, the user must manually enter a phone number on the desktop phone, while looking at the screen and typing the digits. This is not only inconvenient but also results in calls placed to the wrong destination.

The Remote Call Control (RCC) scenario for Office Communications Server 2007 eliminates the necessity of manually entering phone numbers stored on the computer into a PBX or IP PBX phone. Furthermore, a user's Office Communicator presence state will reflect the fact that she is in a call by changing the presence state to In A Call. This scenario is supported by Live Communications Server 2005 SP1 and by Office Communications Server 2007 with Communicator 2007. This scenario is not supported by Office Communications Server 2007 with Microsoft Office Communicator Phone Edition.

Note

Office Communicator Phone Edition is the Internet Protocol (IP) phone solution for Office Communications Server 2007. Chapter 10, "VoIP Scenario," discusses the option to have multiple registered endpoints for the same user on Office Communications Server 2007. For example, one of the endpoints could be a Communicator 2007 application running on a desktop computer, and the other concurrently connected endpoint could be Office Communicator Phone Edition. Both act as VoIP endpoints.

If the user is enabled for RCC and not for Enterprise Voice, such as in the Voice over Internet Protocol (VoIP) scenarios, Office Communicator Phone Edition cannot be used. (For example, it is not possible to establish an outgoing call on Communicator 2007 and let the Office Communicator Phone Edition IP phone make the call.)

The user is able to control his PBX or IP PBX phone by using the Communicator 2007 graphical user interface. If the company has Office Communications Server 2007 Edge Server deployed to allow Remote Access scenarios, it is even possible for the user to control his office desktop phone while he is connected anywhere on the Internet. For example, a user can receive an incoming call on his PBX or IP PBX extension in the office and deflect the incoming call to his mobile phone number by clicking on a small pop-up window that shows the incoming call on Communicator 2007.

In the RCC scenario, the voice media stream of a phone call stays on the existing PBX or IP PBX phone and is not being handled by Communicator 2007. This is one of the major differences between the Remote Call Control scenario and the Enterprise Voice scenarios, as described in Chapter 10.

Why Consider Remote Call Control?

It is reasonable to ask why a company should deploy the RCC scenario when it could take an even bigger step and deploy one of the VoIP scenarios offered by Office Communications Server 2007. After all, today's enterprise IP networks are reliable, provide sufficient service levels, and fulfill VoIP-characteristic requirements. VoIP scenarios using Communicator 2007 offer an even richer set of functionality and better integration into other Microsoft Office applications (such as Microsoft Outlook) than the RCC scenario. In addition, the effort required to integrate with the existing telephone environment so that users can control their existing PBX or IP PBX phones can be eliminated by skipping the RCC step and migrating to VoIP immediately.

Even though we are living in the so-called "VoIP age" and many large enterprises have already replaced their existing Time Division Multiplexing (TDM) PBX with VoIP-based IP PBX, the majority of enterprises are still running TDM PBX systems. Their migration process from TDM to VoIP is delayed for multiple specific reasons. Office Communications Server 2007 offers with the RCC scenario a "lightweight" telephone integration scenario, enabling enterprises to offer computer-to-telephone integration to their users, supplying the ease of a computer telephone (softphone), without migrating their entire telephone environment to VoIP on the IP network.

Real World: Private Branch Exchange

A private branch exchange (PBX) is a communication system that connects phones, faxes, and modems to other extensions within a business or to the public switched telephone network (PSTN). A traditional PBX consists of telephone handsets that are physically wired to a switch located in the same or a nearby building. This traditional approach requires an elaborate wiring system, one that parallels a similar wiring setup for the computers in the building. Furthermore, the traditional PBX assigns a phone number to the port on the PBX where the wire is connected rather than to the person or the telephone device itself. This arrangement results in a labor-intensive process to set up or move an office worker's phone whenever the worker changes offices. These factors and many others combined with the declining costs of computer networking equipment have given rise to the IP PBX, or Internet Protocol PBX. These solutions provide the same functionality as a traditional PBX, often using equipment that so closely resembles its traditional brethren that office workers do not notice a difference. But the total cost of ownership of an IP PBX is substantially lower.

—Paul Tidwell

Software Development Engineer, Microsoft

For all companies that have already migrated to a VoIP platform, mostly in the form of an IP PBX, the main reason to configure the RCC scenario is to provide the ease of integrated telephone functionality in Microsoft Office applications to their users, as most users are already familiar with the look and feel of Communicator 2007 for instant messaging (IM) and presence.

Overview of Remote Call Control Scenario

As shown in Figure 9-1 a user using the RCC scenario has a PBX or IP PBX phone next to his desktop computer running Communicator 2007 enabled for RCC.

System architecture diagram for RCC scenario

Figure 9-1. System architecture diagram for RCC scenario

Apart from enabling the user's Communicator 2007 for RCC, it is necessary to install at least one Session Initiation Protocol/Computer-Supported Telephony Applications (SIP/CSTA) gateway connected to the existing PBX or IP PBX that also hosts the user's PBX phone or IP PBX phone. CSTA is an international standard set by the European Computer Manufacturers Association (ECMA) to combine network servers in general with PBX or IP PBX environments. There are PBX or IP PBX–specific SIP/CSTA gateways or vendor-neutral SIP/CSTA gateways, such as Genesys Enterprise Telephony Software (GETS) from Genesys, and it is their task to transmit call-related signaling information from the PBX or IP PBX to Communicator 2007 and vice versa. The SIP/CSTA gateway does this by establishing and terminating SIP sessions on the IP network site and converting these messages to CSTA-standard specific messages on the telephone network site to the existing PBX or IP PBX by using PBX/IP PBX-specific CSTA commands, but without handling the voice media stream.

The following functionalities are available with Communicator 2007 if a user is enabled for RCC:

  • Make call The RCC-enabled Communicator 2007 user can initiate a phone call by clicking on a call menu provided in Communicator 2007 or Microsoft Outlook.

  • Receive call The RCC-enabled Communicator 2007 user can accept an incoming call that is presented to her in the form of a pop-up window by clicking on the pop-up window. The existing PBX or IP PBX phone will go off-hook, and the speaker phone capabilities will be activated.

  • Caller identification If the RCC-enabled Communicator 2007 user receives an incoming call, Communicator 2007 will try to resolve the Calling Party Number to a more user-friendly format by presenting the calling party's name. This will be successful only if the phone number can be matched against an entry in Microsoft Outlook, a Communicator 2007 contact, or the Global Address List.

  • Call waiting If the RCC-enabled Communicator 2007 user is already in a call and receives a second call, Communicator 2007 displays a pop-up window to the user that informs him about this second waiting call.

  • Call hold and retrieve The RCC-enabled Communicator 2007 user is able to use the conversation window of Communicator to place an existing connection on hold and to retrieve it again. By placing the call on hold, the call is held on the PBX or IP PBX and—if available—music is played to the caller by the existing PBX or IP PBX.

  • Alternate call The RCC-enabled Communicator 2007 user can handle multiple calls at a time. Each call is represented by a separate communication window. The user can switch between the calls but can have only one active call at a time. The other calls are placed on hold. The number of concurrent calls depends on the existing PBX or IP PBX.

  • Single-step transfer The RCC-enabled Communicator 2007 user can forward an existing call unannounced to another phone number by clicking on the appropriate transfer button in Communicator 2007. This is one of the Communicator 2007 functionalities that is significantly easier to use than a regular PBX or IP PBX phone.

  • Consultative transfer The RCC-enabled Communicator 2007 user can place an existing call on hold, establish another call, and later connect the former call with the latter. This is another one of the Communicator 2007 functionalities that is significantly easier to use than a regular PBX or IP PBX phone.

  • DTMF (dual-tone multifrequency) digits The RCC-enabled Communicator 2007 user can initiate the sending of DTMF digits through the PBX system by using the Communicator 2007 conversation window DTMF dial pad in an active call.

    Note

    This feature is available only if the CSTA gateway supports sending of DTMF tones.

  • Forward to another telephone number The RCC-enabled Communicator 2007 user can forward an incoming call to another phone number while the call is in a ringing state. This functionality does not work automatically (call forward immediately) and is not available when the Communicator 2007 application is not running.

  • Conversation history The RCC-enabled Communicator 2007 user can see all of her incoming and outgoing calls in the Conversation History folder in Microsoft Outlook. The user does not receive notifications about calls that come in for the user while Communicator 2007 is not running.

  • Missed call The RCC-enabled Communicator 2007 user receives Missed Call Notifications in his Outlook Inbox for calls that the user did not answer and that came in while Communicator 2007 was running.

  • Reply with IM The RCC-enabled Communicator 2007 user can deflect an incoming call by answering with an instant message. This works only if the Calling Party Number can be resolved to a contact in the recipient's Communicator 2007 Contact List.

  • Call notes The RCC-enabled Communicator 2007 user can type notes in Microsoft Office OneNote directly from the Conversation window in Communicator 2007.

Note

The following functionalities were provided with Live Communications Server 2005 SP1 but are no longer provided with Office Communications Server 2007:

  • Conference calling

  • Location-based forwarding

  • Setting the Do Not Disturb presence state on a PBX or IP PBX phone

  • Showing display names provided by PBX or IP PBX by CSTA gateway

Even if an Office Communications Server 2007 user is enabled for RCC and the telephone functionalities are limited to a set of call control functionalities of the existing PBX or IP PBX phone, the following VoIP-related features are available as well:

  • Make and receive Communicator-to-Communicator audio calls

  • Make and receive Communicator-to-Communicator audio/video calls

  • Establish a video conversation between two Communicator 2007 clients while audio is handled by the PBX or IP PBX

Note

With Communicator 2007 and Office Communications Server 2007, it is in general not possible any longer to place computer-to-phone calls and phone-to-computer calls when the user is enabled for RCC, even if a SIP/PSTN gateway is deployed. Instead, the Enterprise Voice scenario provides exactly this functionality. There is one exception where RCC and Enterprise Voice can be configured for a single user. It is explained in Chapter 10.

By using the functionalities just listed, the audio/video media stream stays on the IP network, as shown in Figure 9-2. It is not possible to make a call to or from the existing telephone environment by using the SIP/CSTA gateway for the audio stream, because the SIP/CSTA gateway cannot convert audio streams from the telephone network into Secure Real-time Transport Protocol (SRTP) media streams as used by SIP-based Office Communications Server 2007.

Communicator-to-Communicator IP call

Figure 9-2. Communicator-to-Communicator IP call

Note

It is not possible for Communicator 2007 to make a direct SIP call to another SIP endpoint on a different SIP-based IP PBX. Office Communications Server 2007 will proxy SIP messages only to endpoints that are authenticated by the server.

Real World: Unified Communications Using RCC

In the world of Unified Communications, one can be forgiven for overlooking the Remote Call Control (RCC) scenario. With Communicator 2007 and Office Communications Server 2007 supporting such a rich and versatile set of telephony and voice scenarios, RCC is often the forgotten or misunderstood child in this technology family.

What is Remote Call Control?

In everyday terms, RCC enables you to control your PBX desk phone using your laptop or desktop computer, without a cable connecting your computer to the phone. Your desk phone and computer do not need to be in the same country, let alone the same room. RCC does not use Voice over IP (VoIP), nor is there a requirement to have an IP-PBX. This means that there is no need whatsoever to upgrade any of your company's IP network or telephony infrastructure. This is the advantage and lure of RCC: by simply deploying Office Communications Server 2007, Communicator 2007, and (sometimes) a gateway device, you can enable Unified Communications and deliver a useful and innovative solution to your users on a reasonably small budget.

What features does RCC provide?

RCC enables several compelling scenarios. First, users can simply click to call from Communicator 2007 or another presence-enabled application. The user's phone will automatically go off-hook (to speakerphone mode) and dial the number of the intended recipient. This saves the user from performing a directory lookup and typing the number into the phone keypad. Big deal! Now your employees are saving two or three seconds each time they place a call, so now they can spend more time gossiping at the water cooler. Keep reading.

The really great part of RCC is what happens on the other end of that call. For the recipient who is enabled for RCC, several things can happen. When the desk phone rings, the user sees a notification in Communicator 2007 that her phone is ringing—similar to an incoming instant message notification. If the user is at her desk, she can choose to take the call by clicking the Accept Call option in the notification. But if she is not at her desk (perhaps she is online but in a hotel, in a meeting, or in a cafe), she can choose to forward the call to another device, such as a mobile phone. A connection is made, voice mail is averted, and everyone is happy.

Another important benefit of RCC is that a user's presence status automatically changes to On The Phone whenever she is on the phone. This feature has tangible benefits. Wouldn't it be great to know that someone is on the phone before you try calling them? More connections, less voice mail!

What do you need to enable RCC?

To enable RCC, you must have a PBX. If you have a newer PBX, check to see if it supports SIP/CSTA. Major PBX vendors such as Avaya, Cisco, Mitel, and Nortel are shipping PBXs that support native RCC integration with Office Communications Server 2007. If your PBX does not meet this requirement, you need a SIP/CSTA gateway that resides in the path between the Office Communications Server and the PBX to perform the necessary translation.

How does it work?

The mechanism that enables RCC is fairly straightforward. When a user is configured for RCC, he receives two additional pieces of information from Office Communications Server 2007 during the Office Communications Server 2007 registration (sign-in) process. The first piece of information is a "Tel URI", or something that identifies the phone line that the user is allowed to control. The second piece of information is the "RCC URI", or something that identifies the address of the PBX or gateway to which the user will connect. With these two pieces of information, the Communicator 2007 client opens a SIP session with the Call-Control Gateway or PBX. Instead of sending friendly instant messages back and forth, however, Communicator 2007 sends call control (CSTA) messages to the gateway to negotiate features and get the status of the phone line. Communicator 2007 also asks for a "monitor" on the line, which enables Communicator to receive notifications about changes to the status of the line, such as when the user picks up the handset to make a call, or when the line receives an incoming call. This communications channel between Communicator and the gateway or PBX stays open for the duration of the user's session.

What else do I need to do?

Sounds easy, right? As with everything in life, there is fine print. You need to enable each user for RCC. As previously mentioned, this requires setting a unique Tel URI for each user, as well as configuring the RCC URI address, which is usually the same for all users connecting to a particular PBX. Then there is the small matter of phone number normalization.

Phone number normalization

The phone number field in Active Directory is a free-form text field. You probably have numbers specified in different formats and some unusual characters such as parentheses, letters, dashes, and dots thrown in for good measure. A typical phone number in Active Directory might look like this: +1 (803) 201-0333 x10333. User's phone numbers are downloaded into Communicator's local address book by Office Communications Server 2007 Address Book Services. This causes two problems. First, the click-to-call feature from the Communicator 2007 user interface probably will not work unless your PBX understands how to transform this string into a legitimate phone number. Second, reverse number lookup for incoming calls and missed-call notifications fail to match a friendly username to the incoming phone number, because this string is not in the same format as the incoming number on the user phone line.

There are a few options for fixing the phone number normalization problem. The simplest solution is to change all the phone numbers in Active Directory to a standard format, such as E.164 format. This format looks like this: +18032013333. If doing this is not possible, the next best option is to normalize the phone numbers by using the Office Communications Server 2007 Address Book Service. If that does not work, you might find that the PBX or CSTA gateway has some features or tools that will help. Note that the last option will usually only fix click-to-call scenarios, and it will not enable reverse number lookup functionality. Phone normalization can be a challenging problem to solve, and each case will be slightly different. When in doubt, refer to the documentation for the CSTA gateway or PBX vendor. This topic is usually covered in detail there.

In summary, RCC provides a simple and cost-effective way to enable unified communications for many companies with an older telephony infrastructure. RCC is a great interim step that enhances the feature set of Office Communications Server 2007 investments without requiring an overhaul of the existing telephony system.

—John Lamb

Principal Consultant, Modality Systems Ltd.

Technical Details Behind the Remote Call Control Scenario

Communicator 2007 has to send call-related information to and receive call-related information from the telephone environment by using the SIP/CSTA gateway. Therefore, during start-up, Communicator 2007 establishes a long-lasting SIP dialog with the SIP/CSTA gateway to transmit call control–related information on incoming calls, on outgoing calls, or in call commands, and it keeps this dialog established. SIP INFO messages are used to send call-related information to and from the SIP/CSTA gateway. The call-related information sits in a set of XML notations, which is the payload of these SIP INFO messages.

In Office Communications Server 2007, ECMA-269 was chosen to implement the application interface for telephone services. This interface enables a softphone application (a computing application) to monitor and control a PBX or IP PBX. ECMA-323 defines the XML schema for those services. ECMA-269 addresses a very broad range of applications. The softphone application implements a profile, which is a small subset of the overall scope of this standard. In Communicator 2007, the SIP implementation follows ECMA Technical Report TR/87.

In Office Communications Server 2007, SIP was chosen to implement the network protocol on the IP side of the SIP/CSTA gateway. ECMA-323 XML messages are tunneled in SIP messages (INVITE and INFO), as shown in the following message example, and they contain the control information for the PBX or IP PBX. This example shows the setup of the long-lasting SIP session with INVITE and responses, which is later used to send the call-related signaling information, as part of a set of XML notations in a SIP INFO message:

---------------------------------------------------------------
INVITE to Gateway
CSTA: RequestSystemStatus
---------------------------------------------------------------

INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/TCP 10.38.138.183:8759
Max-Forwards: 70
From: "Alice Ciccu" <sip:[email protected]>;tag=1fb5eae7ac;
   epid=a8ae525d8a
To: <sip:[email protected]>
Call-ID: cedd20b703994209ab6b1e13d4adc8ee
CSeq: 1 INVITE
Contact: <sip:[email protected]:8759;maddr=10.38.138.183;transport=tcp>;
   Proxy=replace
User-Agent: LCC/1.3
Supported: timer
Session-Expires: 1800;refresher=uac
Min-SE: 1800
Content-Disposition: signal;handling=required
Proxy-Authorization: Kerberos qop="auth",
   realm="SIP Communications Service", opaque="16439A15",
   crand="ab9f7b1b", cnum="9",
   targetname="sip/lcs-fe01.contoso.com", response=
         "602306092a864886f71201020201011100ffffffffc
         28e306f3dd4e5f46a187aa3e6084be1"
Content-Type: application/csta+xml
Content-Length: 329

<?xml version="1.0"?>
<RequestSystemStatus xmlns="http://www.ecma-international.org/standards/ecma-323/csta/
ed3"><extensions><privateData><private><lcs:line xmlns:lcs=
"http://schemas.microsoft.com/Lcs/2005/04/RCCExtension">
   tel:75513;phone-context=contoso.com</lcs:line></private>
   </privateData></extensions></RequestSystemStatus>

-------------------------------------------------------------
100 Trying from Gateway
-------------------------------------------------------------

SIP/2.0 100 Trying
Authentication-Info: Kerberos
rspauth="602306092A864886F71201020201011100FFFFFFFFC742986919AF8C
   0BE0FDECD779CD8460", srand="6061FF07", snum="11",
   opaque="16439A15", qop="auth", targetname=
   "sip/lcs-fe01.contoso.com", realm="SIP Communications Service"
Via: SIP/2.0/TCP 10.38.138.183:8759;received=10.37.211.6;
ms-received-port=2141;ms-received-cid=72300
From: "Alice Ciccu" <sip:[email protected]>;tag=1fb5eae7ac;epid=a8ae525d8aTo:
<sip:[email protected]>
Call-ID: cedd20b703994209ab6b1e13d4adc8ee
CSeq: 1 INVITE
Content-Length: 0

------------------------------------------------------------
200 OK from Gateway
CSTA: RequestSystemStatusResponse
------------------------------------------------------------
SIP/2.0 200 OK
Authentication-Info: Kerberos
rspauth="602306092A864886F71201020201011100FFFFFFFF5C17289F992E77E
D0349151CC936B961", srand="850C5E3F", snum="12",
   opaque="16439A15", qop="auth", targetname=
   "sip/lcs-fe01.contoso.com", realm="SIP Communications Service"
Via: SIP/2.0/TCP 10.38.138.183:8759;received=10.37.211.6;
   ms-received-port=2141;ms-received-cid=72300
Content-Length: 222
Record-Route: <sip:lcspool01.contoso.com;transport=tcp;
   ms-fe=lcs-fe01.contoso.com;lr;ms-route-sig=aa-
   jWGb9Pd8SAlTDJ76ACeKIIZogGO>
From: "Alice Ciccu" <sip:[email protected]>;tag=1fb5eae7ac;
   Epid=a8ae525d8a
To: <sip:[email protected]>;tag=hssUA_699671144-5048
Call-ID: cedd20b703994209ab6b1e13d4adc8ee
CSeq: 1 INVITE
Require: timer
Session-Expires: 1800;Refresher=uac
Supported: *,timer
Contact: csta-gw <sip:[email protected]:5060;
transport=tcp>
Allow: INVITE,BYE,CANCEL,ACK,INFO,PRACK,COMET,OPTIONS,SUBSCRIBE,
NOTIFY,REFER,REGISTER,UPDATE
Content-Type: application/csta+xml

<?xml version="1.0" encoding="UTF-16" standalone="no" ?>
<RequestSystemStatusResponse xmlns="http://www.ecma-international.org/standards/ecma-
323/csta/ed3">
<systemStatus>normal</systemStatus></RequestSystemStatusResponse>

-------------------------------------------------------------
ACK from client
-------------------------------------------------------------
ACK sip:lcspool01.contoso.com;transport=tcp;ms-fe=lcs-fe01.contoso.com;lr;
   ms-route-sig=aa-jWGb9Pd8SAlTDJ76ACeKIIZogGO SIP/2.0
Via: SIP/2.0/TCP 10.38.138.183:8759
Max-Forwards: 70
From: "Alice Ciccu" <sip:[email protected]>;tag=1fb5eae7ac;
   epid=a8ae525d8a
To: <sip:[email protected]>;tag=hssUA_699671144-5048
Call-ID: cedd20b703994209ab6b1e13d4adc8ee
CSeq: 1 ACK
Route: csta-gw <sip:[email protected]:5060;
   transport=tcp>
User-Agent: LCC/1.3
Proxy-Authorization: Kerberos qop="auth", realm=
   "SIP Communications Service", opaque="16439A15",
   crand="b6b62ff5", cnum="10", targetname="
   sip/lcs-fe01.contoso.com",
   response="602306092a864886f71201020201011100ffffffffa
   3bbb1a2b1af02f8f55ec392dd96525c"
Content-Length: 0

Note

Office Communications Server 2007 is not aware that the SIP INVITE message is used to establish a long-lasting SIP dialog for the RCC scenario. Office Communications Server 2007 currently does not support a "long-life" dialog and will terminate the session because of route expiration after 12 to 24 hours. Therefore, Communicator 2007 opens a new dialog (the default is after 30 minutes) with the same SIP/ECMA server (Session Initiation Protocol/European Manufacturers Association) (in this case the SIP/CSTA gateway) before the dialog is expired in Office Communications Server 2007 (regardless of the session timer), and it closes the existing dialog with this device (which is about to expire). Communicator 2007 ensures that events are not lost during the transition.

In the preceding SIP INFO message, Communicator 2007 establishes a logical transport channel and an association between itself, the SIP/CSTA gateway, and the switching system (PBX or IP PBX) to transmit all call-related information between the PBX or IP PBX and Communicator. The logical name of the user is described in the SIP FROM header:

---------------------------------------------------------
INFO from client
CSTA: SetForwarding
---------------------------------------------------------

INFO sip:lcspool01.contoso.com;transport=tcp;ms-fe=lcs-fe01.contoso.com;lr;ms-route-
sig=aa-jWGb9Pd8SAlTDJ76ACe
   KIIZogGO SIP/2.0
Via: SIP/2.0/TCP 10.38.138.183:8759
Max-Forwards: 70
From: "Alice Ciccu" <sip:[email protected]>;tag=1fb5eae7ac;
   epid=a8ae525d8a
To: <sip:[email protected]>;tag=hssUA_699671144-5048
Call-ID: cedd20b703994209ab6b1e13d4adc8ee
CSeq: 4 INFO
Route: csta-gw <sip:[email protected]:5060;transport=tcp>
Contact: <sip:[email protected]:8759;maddr=10.38.138.183;
transport=tcp>;proxy=replace
User-Agent: LCC/1.3Content-Disposition: signal;handling=required
Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications
Service", opaque="16439A15", crand="a4b77dd6", cnum="13", targetname="sip/lcs-
fe01.contoso.com", response=
"602306092a864886f71201020201011100ffffffffb354bf3532a930f8e7c741c
4588d631f"
Content-Type: application/csta+xml
Content-Length: 265

<?xml version="1.0"?>
<SetForwarding xmlns="http://www.ecma-international.org/standards
/ecma-323/csta/ed3"><device>tel:75513;phone-context=contoso.com
</device><forwardingType>forwardImmediate</forwardingType>
<activateForward>false</activateForward></SetForwarding>

--------------------------------------------------------------
200 OK from Gateway
CSTA: SetForwardingResponse
--------------------------------------------------------------
SIP/2.0 200 OK
Authentication-Info: Kerberos
rspauth="602306092A864886F71201020201011100FFFFFFFF7697AD30
   EC969F34032887CCCD76446E", srand="00D543B4", snum="15", opaque=
   "16439A15", qop="auth", targetname="sip/lcs-fe01.contoso.com",
   realm="SIP Communications Service"
Via: SIP/2.0/TCP 10.38.138.183:8759;received=10.37.211.6;
   ms-received-port=2141;ms-received-cid=72300
Content-Length: 152
From: "Alice Ciccu" <sip:[email protected]>;tag=1fb5eae7ac;
   epid=a8ae525d8a
To: <sip:[email protected]>;tag=hssUA_699671144-5048
Call-ID: cedd20b703994209ab6b1e13d4adc8ee
CSeq: 4 INFO
Contact: csta-gw <sip:[email protected]:5060;
   transport=tcp>
Allow: INVITE,BYE,CANCEL,ACK,INFO,PRACK,COMET,OPTIONS,SUBSCRIBE,
   NOTIFY,REFER,REGISTER,UPDATE
Supported: *Content-Type: application/csta+xml

<?xml version="1.0" encoding="UTF-16" standalone="no" ?>
<SetForwardingResponse xmlns="http://www.ecma-international.org/standards/ecma-323/csta/
ed3"/>

If the Communicator 2007 user wants to establish a phone call to extension 65000, the SIP message as a SIP INFO request looks like this:

-----------------------------------------------------------
INFO from client
CSTA: MakeCall
-----------------------------------------------------------
INFO sip:lcspool01.contoso.com;transport=tcp;
ms-fe=lcs-fe01.contoso.com;lr;
ms-route-sig=aa-jWGb9Pd8SAlTDJ76ACeKIIZogGO SIP/2.0
Via: SIP/2.0/TCP 10.38.138.183:8759
Max-Forwards: 70
From: "Alice Ciccu" <sip:[email protected]>;tag=1fb5eae7ac;
   epid=a8ae525d8a
To: <sip:[email protected]>;tag=hssUA_699671144-5048
Call-ID: cedd20b703994209ab6b1e13d4adc8ee
CSeq: 5 INFO
Route: csta-gw <sip:[email protected]:5060;transport=tcp>
Contact: <sip:[email protected]:8759;maddr=10.38.138.183;
transport=tcp>;proxy=replace
User-Agent: LCC/1.3
Content-Disposition: signal;handling=required
Proxy-Authorization: Kerberos qop="auth", realm=
"SIP Communications Service", opaque="16439A15", crand=
"bf7e3cd3", cnum="14", targetname="sip/lcs-fe01.contoso.com",
response="602306092a864886f71201020201011100ffffffffec2e8a44b84
ef7850d9c5f595e0d26c6"
Content-Type: application/csta+xml
Content-Length: 303

<?xml version="1.0"?>
<MakeCall xmlns="http://www.ecma-international.org/standards/
ecma-323/csta/ed3"><callingDevice>tel:75513;phone-context=
contoso.com</callingDevice><calledDirectoryNumber>
tel:65000;phone-context=dialstring
</calledDirectoryNumber><autoOriginate>doNotPrompt
</autoOriginate></MakeCall>

-----------------------------------------------------------
200 OK from Gateway
CSTA: MakeCallResponse
-----------------------------------------------------------
SIP/2.0 200 OK
Authentication-Info: Kerberos rspauth="602306092A864886F71201020201011100FFFFFFFF88C8000
928C70765CA7C6B1F526A9904", srand="11ED47CB", snum="17",
opaque="16439A15", qop="auth", targetname=
"sip/lcs-fe01.contoso.com", realm="SIP Communications Service"
Via: SIP/2.0/TCP 10.38.138.183:8759;received=10.37.211.6;
ms-received-port=2141;ms-received-cid=72300
Content-Length: 303
From: "Alice Ciccu" <sip:[email protected]>;tag=1fb5eae7ac;
   epid=a8ae525d8a
To: <sip:[email protected]>;tag=hssUA_699671144-5048
Call-ID: cedd20b703994209ab6b1e13d4adc8ee
CSeq: 5 INFO
Contact: csta-gw <sip:[email protected]:5060;transport=tcp>
Allow: INVITE,BYE,CANCEL,ACK,INFO,PRACK,COMET,OPTIONS,SUBSCRIBE,
NOTIFY,REFER,REGISTER,UPDATE
Supported: *Content-Type: application/csta+xml

<?xml version="1.0" encoding="UTF-16" standalone="no" ?>
<MakeCallResponse xmlns="http://www.ecma-international.org/
standards/ecma-323/csta/ed3"><callingDevice><callID>3329005
</callID><deviceID typeOfNumber="dialingNumber">
tel:75513;phone-context=contoso.com</deviceID></callingDevice>
</MakeCallResponse>

Setting Up the Remote Call Control Scenario

To set up the RCC scenario, you need to perform the following steps, which should be performed in order and will be explained in detail below:

  1. Install the SIP/CSTA gateway, and configure the CSTA interface on the PBX or IP PBX.

  2. Configure a user for RCC by doing the following:

    1. Enable the user for RCC in Active Directory.

    2. Configure a Line Server URI (Server Uniform Resource Identifier) and Line URI (Line Uniform Resource Identifier) for the user in Active Directory.

    3. Configure an RCC URI for the user.

  3. Configure a route on the Office Communications Server pool for the Server URI.

  4. Start Communicator.

The following sections describe these steps in more detail.

Installing the CSTA Gateway and Configuring the SIP/CSTA Interface on the PBX or IP PBX

For integration with the existing telephone environment, a SIP/CSTA gateway is needed. This gateway is connected to the SIP/CSTA interface provided by the existing PBX or IP PBX. It is possible to have multiple SIP/CSTA gateways connected to Office Communications Server 2007, but for a single user, only one SIP/CSTA gateway can be configured. However, only one SIP/CSTA gateway per PBX node is recommended to avoid numbering-plan conflicts.

There are PBX/IP PBX–specific CSTA gateways and vendor-neutral CSTA gateways available on the market. You need to select a CSTA gateway that supports your existing PBX/IP PBX if the PBX/IP PBX doesn't offer a native CSTA interface.

Configuring a User for RCC

To configure a user for RCC, you first need to enable the user for RCC in Active Directory by using the Active Directory Users and Computers Management Console. In the Office Communications Server 2007 Active Directory Snap-In under Advanced Settings, select the configuration option Enable Remote Call Control, as shown in Figure 9-3.

Enabling and configuring a user for RCC

Figure 9-3. Enabling and configuring a user for RCC

You then configure a Server URI for the user. This Server URI points to the SIP/CSTA gateway. Communicator 2007 sends its SIP call control messages to the SIP/CSTA gateway defined in the Server URI field. The syntax of the Server URI entered here must match the requirements of the SIP/CSTA gateway. (Please refer to the documentation provided by the SIP/CSTA gateway vendor.) Here are some examples:

The E.164 number is the phone number of the user in E.164 format (+<Country Access Code><Area Code><local number>, such as +14255550125), and the SIP/CSTA Gateway FQDN is the fully qualified domain name of the SIP/CSTA gateway.

Finally, you configure a Line URI for the user. This URI is used to send call control information to and receive it from the existing telephone environment, as Calling or Called Party Number Identification. The syntax must match the requirements of the SIP/CSTA gateway. (For more information, refer to the SIP/CSTA gateway documentation provided by the SIP/CSTA gateway vendor.) For example, the following syntaxes are common:

  • Tel:+14255550125;ext=125

    (Tel:<E.164 number>;ext=<extension>)

  • Tel:+14255550125;phone-context=mitel.com

    (Tel:<E.164 number>;phone-context=<SIP/CSTA Gateway name>.<com>)

The E.164 number and the number string following ext= must match the number and extension the user has on the existing telephone environment.

Note

When you enable a user for PBX integration (also see Chapter 10) as part of the Enterprise Voice scenario, the user can still be enabled for RCC. This is the only exception where a user can be enabled for RCC and for Enterprise Voice at the same time. The Server URI and Line URI fields must be entered as described later in this chapter.

Configuring a Route on the Office Communications Server Pool for Server URI

All SIP traffic from Communicator 2007 always goes through Office Communications Server 2007 and is proxied by the server to the SIP/CSTA gateway. To send SIP INFO call control messages from Communicator 2007 to the SIP/CSTA gateway, the same SIP dialog is used that Communicator 2007 established in its start-up phase by sending a SIP INVITE message to the SIP/CSTA gateway. Communicator 2007 sends its SIP INVITE and SIP INFO call control messages to this SIP/CSTA gateway, which is configured in the Server URI field. This must be the FQDN of the SIP/CSTA gateway. On Office Communications Server 2007, for every Server URI, a route must be configured with the destination address to which Office Communications Server 2007 must proxy SIP call control messages. You can configure this under pool-level settings on the Routing tab, as shown in Figure 9-4.

Configuring routes for Server URIs

Figure 9-4. Configuring routes for Server URIs

For each route to a SIP/CSTA Gateway Server, the following settings must be configured:

  • Matching URI The syntax, sip:*@[CSTA Gateway FQDN], means that this route will be used for any number (*) configured in the Server URI field of the Active Directory user properties page where the FQDN of the SIP/CSTA gateway Server matches the value entered here.

  • Next hop This is the FQDN or IP address of your SIP/CSTA gateway.

  • Port This is the SIP/CSTA gateway that is configured to listen for SIP traffic.

  • Transport protocol This is the transport protocol that the SIP/CSTA Gateway is configured to use.

Note

If Transport Layer Security (TLS) is configured as the transport protocol, the FQDN must be entered in the Next Hop field. If TCP is selected, the IP Address of the CSTA Gateway Server must be entered in the Next Hop field. The FQDN is needed in the TLS mode to allow certificate verification for secure communication. If TLS is not used, a host authorization entry must also be added so that the Office Communications Server treats the CSTA gateway as authenticated.

Note

It is possible to have multiple SIP/CSTA gateways configured in the same Office Communications Server 2007 pool.

Starting Communicator 2007

When Communicator 2007 starts, it retrieves its Server and Line URI settings, as well as the RCC-enabled settings through Inband Provisioning. Inband Provisioning transmits configuration settings to the Communicator 2007 client, even when Communicator 2007 has no access to Group Policies stored in Active Directory. Therefore, it is also possible to use RCC when the user is remotely connected to the Office Communications Server 2007 environment on the Internet.

On an incoming call, the PBX or IP PBX rings the user's existing PBX or IP PBX phone and also sends out an incoming call notification to Communicator through the SIP/CSTA gateway, as shown in Figure 9-5 by using a SIP INFO message sent from the SIP/CSTA gateway to Communicator 2007. The user can either answer the incoming call on his PBX or IP PBX phone by picking up the receiver or accept the incoming call on Communicator, which activates the speaker phone functionality on the PBX or IP PBX phone.

Incoming RCC call

Figure 9-5. Incoming RCC call

To resolve the Calling Party Number to a name, Communicator first applies the number normalization Regular Expressions configured in the Address Book Service on the Office Communications Server 2007 pool on the Calling Party Number. After that, Communicator 2007 matches the current E.164 format normalized Calling Party Number with the phone numbers stored in Active Directory or Outlook contacts. This functionality is called reverse number lookup. If Communicator 2007 successfully applies reverse number lookup and finds a name that matches a Calling Party Number, this name is presented to the user in the pop-up window and the Conversation window, instead of the Calling Party Number.

Note

Regular Expressions for number normalization can be configured as described in file following file on Office Communications Server Standard Edition or Enterprise Edition:

\%installation path OCS%Microsoft Office Communications Server 2007Web ComponentsAddress Book FilesSample_Company_Phone_Normalization_Rules.txt

This file also contains examples and an explanation of how to test the phone number normalization rules.

Some CSTA implementations on PBX or IP PBX provide these reverse number lookup functionalities. Thus, instead of or in addition to the Calling Party Number, a display name is transmitted to Communicator on an incoming call. This display name is ignored by Communicator 2007 because it is not possible for Communicator 2007 to verify the name.

Depending on the implementation in the PBX or IP PBX, the Calling Party Number can have the following formats:

  • Extension (for example, 1212)

  • E.164 format (for example, +14255550125)

  • Both (+14255550125;ext=1212)

Note

The format of the Calling Party Number entered in the PBX or IP PBX must match the requirements of the SIP/PSTN gateway. Sometimes this is in the E.164 format and sometimes it is not.

If the Calling Party Number string does not contain a number on an incoming call, Communicator 2007 will not apply reverse number lookup.

On an outgoing call initiated on Communicator 2007, Communicator 2007 first applies the Number Normalization regular expression rules (the same rules that were configured for reverse number lookup on incoming calls, which convert a number string to E.164 format) on the number string entered as Called Party Number in Communicator 2007 before sending the request to the SIP/CSTA gateway by using the established long-lasting SIP dialog. This is shown in Figure 9-6.

Outgoing RCC call

Figure 9-6. Outgoing RCC call

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset