Office Communicator 2007 R2 has to send call-related information to and receive call-related information from the SIP/CSTA gateway. When Office Communicator 2007 R2 starts, it establishes a long-term 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 until Office Communicator 2007 R2 is shut down. SIP INFO messages are used to send call-related information to and from the SIP/CSTA gateway. The call-related information is encoded as XML, which is the payload of these SIP INFO messages.

In Office Communicator 2007 R2, the SIP implementation follows ECMA Technical Report TR/87. The aforementioned XML encoding of call-related information follows the ECMA-323 standard.

The following is an example of the SIP INFO message between Office Communicator 2007 R2 and the SIP/CSTA gateway:

INFO sip:[email protected]:5061;transport=tls;ms-role-rs-from;lr;ms-
route-sig=fsw3ylQ4X4vWNp2izAEQzWGw7NpJnQ1WDx_Z8P0wAA SIP/2.0
Via: SIP/2.0/TLS 172.24.32.119:51063
Max-Forwards: 70
From: <sip:[email protected]>;tag=9708e2df90;epid=bd23d94254
To: <sip:[email protected]>;tag=1fa3a090-e86b1dac-13c4-40030-647a3-
edaf1a3-647a3
Call-ID: a3f0077597a645ed91dfed3bf7e88d93
CSeq: 2 INFO
User-Agent: UCCP/2.0.6362.0 OC/2.0.6362.0 (Microsoft Office Communicator)
Content-Disposition: signal;handling=required
Supported: timer
Proxy-Authorization: Kerberos qop="auth", realm="SIP Communications Service",
opaque="F6103640", crand="d4eeb47a", cnum="11", targetname="sip:[email protected].
litwareinc.com", response="602306092a864886f71201020201011100ffffffff54c977329332842b8
245d15438797106"
Content-Type: application/csta+xml
Content-Length: 313

<?xml version="1.0"?>
<GetCSTAFeatures 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">te
l:+14255550125;ext=125</lcs:line>
      </private>
    </privateData>
  </extensions>
</GetCSTAFeatures>

SIP/2.0 200 OK
Authentication-Info: Kerberos rspauth="602306092A864886F71201020201011100FFFFFFFF8
4471479F62D94AC3307F0F1CA27DA36", srand="EFB30DB0", snum="13", opaque="F6103640",
qop="auth", targetname="sip:[email protected]", realm="SIP
Communications Service"
From: <sip:[email protected]>;tag=9708e2df90;epid=bd23d94254
To: <sip:[email protected]>;tag=1fa3a090-e86b1dac-13c4-40030-647a3-
edaf1a3-647a3
Call-ID: a3f0077597a645ed91dfed3bf7e88d93
CSeq: 2 INFO
Content-Disposition: signal;handling=required
Via: SIP/2.0/TLS 17.1.19:51063;ms-received-port=51063;ms-received-cid=185D300
Supported: 100rel,replaces,timer
User-Agent: Example Gateway Release 1.0 version 4.2.3
Contact: <sip:[email protected]>
Content-Type: application/csta+xml
Content-Length: 985
<?xml version="1.0" encoding="UTF-8"?>
<GetCSTAFeaturesResponse xmlns="http://www.ecma-international.org/standards/ecma-323/
csta/ed3" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <supportedServices>
    <systemStatServList>
      <requestSystemStatus />
    </systemStatServList>
    <monitoringServList>
       <monitorStart />
       <monitorStop />
    </monitoringServList>
    <callControlServList>
      <answerCall />
      <clearConnection />
      <consultationCall />
      <deflectCall />
      <holdCall />
      <makeCall />
      <retrieveCall />
      <singleStepTransfer />
      <transferCall />
    </callControlServList>
    <callAssociatedServList>
      <generateDigits />
    </callAssociatedServList>
    <logicalServList>
      <setForwarding />
    </logicalServList>
  </supportedServices>
  <supportedEvents>
    <callControlEvtsList>
      <connectionCleared />
      <delivered />
      <diverted />
      <established />
      <failed />
      <held />
      <originated />
      <retrieved />
      <transferred />
    </callControlEvtsList>
    <logicalEvtsList>
      <forwarding />
    </logicalEvtsList>
  </supportedEvents>
</GetCSTAFeaturesResponse>

In the preceding SIP INFO message, Office Communicator 2007 R2 is requesting the list of supported PBX features. The PBX advertises its supported feature set with the GetCSTA-FeaturesResponse message. This is an important transaction to note because it impacts features lighting up in the Office Communicator user interface. For example, the PBX in the previous response supports the Call Transfer function because the <TransferCall/> primitive is present in the <CallControlServList> node. Therefore, Office Communicator will enable the Transfer button. Further examples in later sections of this chapter highlight how Office Communicator 2007 R2 interacts with the SIP/CSTA gateway.

Bootstrapping

Bootstrapping sequence establishes the communication path between Office Communicator and the SIP/CSTA gateway. The first part of bootstrapping is downloading the Line URI and Server URI parameters from Office Communications Server by using the in-band provisioning mechanism. Office Communicator then establishes a long-term INVITE dialog with the SIP/CSTA gateway specified in the Server URI. Office Communicator sends the RequestSystem-Status CSTA command, to which the PBX responds with a RequestSystemStatusResponse message. Once this exchange is completed, the SIP INVITE dialog is set up, and INFO messages can be sent in this dialog.

The first INFO message is the GetCSTAFeatures message that you have seen before, which Office Communicator sends to the SIP/CSTA gateway to discover the call related features supported by the PBX. The second INFO message with the CSTA command, MonitorStart, indicates that Office Communicator should start monitoring the user’s PBX phone line. This is required so that the PBX starts sending events about the line state to Office Communicator via the SIP/CSTA gateway. Once these events are exchanged, Office Communicator is ready to make and receive RCC calls. Figure 9-4 illustrates the bootstrapping procedure.

Figure 9-4. Bootstrapping RCC

Note

Communicator periodically sends a RE-INVITE with RequestSystemStatus approximately every 10 minutes to ensure that the SIP/CSTA gateway is up and running and that the long-lasting SIP dialog is maintained. This is a heartbeat mechanism that is maintained from Office Communicator 2007 R2 to the SIP/CSTA gateway.

Receiving a Call

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

Received calls are always indicated to Office Communicator using a DeliveredEvent INFO message that originates from the SIP/CSTA gateway. Once the user picks up the call, an AnswerCall message is sent to the PBX, which responds with an EstablishedEvent message to indicate the successful call set-up. Figure 9-5 illustrates how a call is received.

Figure 9-5. Receiving a call

Real World: Troubleshooting Remote Call Control Scenarios

John Lamb

Director, Modality Systems Limited

Setting up Remote Call Control (RCC) integration between Office Communications Server 2007 R2 and a PBX is usually a straightforward process. It involves configuring your Office Communications Server environment to exchange RCC messages with your PBX. Many new PBXs support native integration with Office Communications Server, and for those that do not, a third-party RCC gateway can be used to facilitate the integration.

However, one of the more problematic RCC scenarios is the Reverse Number Lookup (RNL) aspect of matching an incoming call number to a name in the directory. When an RCC-enabled user receives a call on her desk phone, the RCC message exchange causes Office Communicator to alert the user that her phone is ringing. This notification message displays information about the caller’s phone number. If RNL is working properly, the notification will also display the caller’s name.

The challenge with RNL lies with getting the caller’s phone number as sent by the PBX (or gateway) to be in the same format as the phone number stored in the Office Communicator address book. Because the phone numbers in the address book are stored in E.164 format, for example, +442071234567, this is what the PBX must send in the RCC message.

The quickest way to determine what the PBX is sending is to enable logging in Office Communicator. This is enabled on the General tab within the Options user interface. When logging is enabled, a text file is created in the %USERPROFILE%Tracing directory that contains debugging information, including the SIP messages that are exchanged. This log file will have a .uccapilog extension (Office Communicator 2007 R2), or a .uccplog extension (Office Communicator 2007).

Once logging is enabled, reproduce the incoming call and then open the text file and look for the SIP INFO message containing the CSTA XML body containing the incoming call notification. The SIP INFO message should contain something that looks like this:

<OriginatedEvent xmlns="http://www.ecma-international.org/standards/ecma-
323/csta/ed3">
     <monitorCrossRefID>1253</monitorCrossRefID>
     <originatedConnection>
         <callID>4067933</callID>
         <deviceID typeOfNumber="dialingNumber">tel:12345;phone-
context=dialstring</deviceID>
     </originatedConnection>
     <callingDevice>
          <deviceIdentifier>tel:12345;phone-context=dialstring</
deviceIdentifier>
     </callingDevice>
     <calledDevice>
          <deviceIdentifier>tel:+442079876543;phone-context=dialstring</
deviceIdentifier>
     </calledDevice>
     <localConnectionInfo>connected</localConnectionInfo>
     <cause>normal</cause>
     <callLinkageData>
<globallyUniqueCallLinkageID>2E2600000000003E125D</
globallyUniqueCallLinkageID>
     </callLinkageData>
</OriginatedEvent>

In this case, look for the <callingDevice><deviceIdentifier> node in the XML body of the CSTA message. In the previous example, you can see that the PBX (or gateway) is sending the following calling device ID:

tel:12345;phone-context=dialstring

Because this is not in E.164 format, Office Communicator will not be able to match this number with anything in its address book. The simplest solution is to configure the PBX or RCC gateway to perform digit manipulation so that the number will be in the correct format. In this case, the number should be:

tel:+442070012345;phone-context=dialstring

Consult the PBX or gateway vendor’s documentation to see if this type of number manipulation is supported.

Making a Call

When a call is made, Office Communicator sends a MakeCall message to the SIP/CSTA gateway with the normalized phone number to connect to. When the user types a phone number manually, Office Communicator will apply the normalization rules to generate an E.164 number before sending it to the SIP/CSTA gateway.

Note

Phone numbers from the Click To Call list are already normalized.

Once the MakeCall request is made, the SIP/CSTA gateway responds with several events. OriginatedEvent indicates that the PBX has initiated a call, DeliveredEvent indicates the call has been delivered to the other end, and EstablishedEvent indicates an answer. Figure 9-6 illustrates how a call is made.

Figure 9-6. Making a call