Overview

Table Of Contents

Overview

Call Control

First-Party Call Control

Third-Party Call Control

Multiple TAPI Applications

Compatibility

Supported Device and Line Types

Startup with Windows

Resets and Restarts

Debug Tracing

Exception Notes

Call Origin

Line Type

Shared Dual Lines

Outgoing Calls on Shared Lines

MAC Address/Device ID

Overview

Revised: January 12, 2007

This chapter outlines the key concepts that are involved in using Cisco Unified CME TSP 2.1 and provides notes on the operation and implementation of Cisco Unified CME TSP 2.1.

• Call Control

• Multiple TAPI Applications

• Compatibility

• Supported Device and Line Types

• Startup with Windows

• Resets and Restarts

• Debug Tracing

• Exception Notes

Cisco Unified CME TSP 2.1 connects to Cisco Unified CME endpoints and exposes the TAPI version 2.2 functions to Windows applications. Cisco Unified CME TSP 2.1 supports a single line device; that is, it can control or emulate only one ephone. Figure 1 shows how various Cisco components fit into the Microsoft Windows telephony services in control mode of operation. Figure 2 shows the similar components when the TSP is configured to terminate media in emulation mode.

Figure 1 Windows Telephony Architecture and Cisco Unified CME TAPI Components in Control Mode

Cisco Unified CME TSP 2.1 control mode allows a Windows application to control calls and terminate packetized voice on an associated IP phone. This mode is often referred to as "third-party call control".

Figure 2 Windows Telephony Architecture and Cisco Unified CME TAPI Components in Emulation Mode

Cisco Unified CME TSP 2.1 emulation mode allows a Windows application to become an IP phone on your PC using an appropriate Windows driver. In emulation mode, the Cisco Unified CME TSP 2.1 application terminates the media. This mode is often referred to as "first-party call control."

Call Control

You can configure Cisco Unified CME TSP 2.1 to provide either first- or third-party call control.

First-Party Call Control

In first-party call control, the application terminates the packetized audio stream. Cisco Unified CME TSP 2.1 uses Windows drivers to stream the audio packets to the selected audio devices when the call is connected. The result is call progress tones and the alerting tones are delivered to the specified audio devices.

Note You must specify playback and recording audio devices using the Cisco Unified CME TSP 2.1 Setup Wizard. For more information see the Cisco Unified CME Telephony Service Provider 2.1 Setup Guide available at www.cisco.com.

In first-party configuration, the Windows application using Cisco Unified CME TSP 2.1 essentially becomes an IP softphone and looks like an IP phone to Cisco Unified CME.

Third-Party Call Control

In third-party call control, the audio stream is terminated on an IP phone on your desk and the TAPI application provides the remote control of calls to that IP phone. Call progress and alerting tones are not played for the calls.

Multiple TAPI Applications

In the Cisco Unified CME TSP 2.1 solution, the TAPI application and Cisco Unified CME TSP 2.1 get installed on the same machine. The TAPI application and Cisco Unified CME TSP 2.1 do not directly interface with each other. A layer written by Microsoft sits between the TAPI application and the Cisco Unified CME TSP 2.1. This layer, known as TAPISRV, allows the installation of multiple TSPs on the same machine, and it hides that fact from the TAPI application. The only difference to the TAPI application is that it is now informed that there are more lines that it can control.

Consider an example. Assume that Cisco Unified CME TSP 2.1 exposes 6 lines, and Microsoft H323 TSP exposes another line. The TAPI application has access to and control of both the Cisco Unified CME lines and the H323 line. The application communicates with TAPISRV, and TAPISRV takes care of communicating with the correct TSP.

Compatibility

Cisco Unified CME TSP 2.1 serves as a TAPI 2.2 service provider. When developing an application, be sure to use only functions that Cisco Unified CME TSP 2.1 supports. For example, transfer is supported, but fax detection is not. If an application requires a media or bearer mode that is not supported, it will not work as expected.

Note Cisco Unified CME TSP 2.1 does not support the Call Center and Agent functions of the TAPI 2.2 specification.

Supported Device and Line Types

Cisco Unified CME TSP 2.1 supports the following device types:

•Cisco Unified IP Phone 7902

•Cisco Unified IP Phone 7905

•Cisco Unified IP Phone 7906G

•Cisco Unified IP Phone 7911G

•Cisco Unified IP Phone 7914 Expansion Module

•Cisco Unified IP Phone 7920

•Cisco Unified IP Phone 7940

•Cisco Unified IP Phone 7941G and 7941GE

•Cisco Unified IP Phone 7960

•Cisco Unified IP Phone 7961G and 7961GE

•Cisco Unified IP Phone 7970G

•Cisco Unified IP Phone 7971G

•Cisco IP Communicator 2.0.1.1

The TSP supports the following types of lines or DN configured on the ephone:

•Single Line DNs—Single line DNs allow a single instance of a call to be associated with the DN.

•Dual Line DNs—Dual line DNs allow two calls to be associated with the DN.

•Shared lines—A DN is shared when it is configured on more than one ephone. Incoming calls are presented to all the ephones. When the call is connected at one position, all other ephones are provided a "Line in Use" status. For shared lines that are "dual", the second call is presented only to the ephone with the connected call.

•Monitored DNs—When a DN is monitored at an ephone, its busy/idle status is presented at the endpoint. The endpoint cannot use the Monitored DN to make or answer calls.

Startup with Windows

Cisco Unified CME TSP 2.1, as with other TSPs, launches at Windows startup. Even though Cisco Unified CME TSP 2.1 is running, it is normally not connected to Cisco Unified CME until a Windows application opens a session. Most TAPI applications open a TAPI session when the application is started and close it when the application terminates. However certain applications, such as Microsoft Outlook, open and close a TAPI session when a call is made. Cisco Unified CME TSP 2.1 provides a "Startup with Windows" mode in which it registers or "connects" to Cisco Unified CME at Windows startup and does not un-register until Windows shuts down. This "Startup with Windows" mode makes calling from such applications much faster.

Resets and Restarts

When Cisco Unified CME TSP 2.1 receives a Reset or Restart message from Cisco Unified CME, it immediately disconnects, removes all lines, and sends a LINE_CLOSE message to the Windows application indicating that the Cisco Unified CME session has been terminated. Both the Reset and Restart messages are treated in an identical manner.

Note Certain other failure conditions, including loss of network connection and loss of a media audio device, can also cause the TSP to send a LINE_CLOSE message.

For a restart or reset, the TSP polls Cisco Unified CME to determine if it is ready to accept a connection. Upon receipt of confirmation, it sends a LINE_REINIT message to the application. This is an indication to the application that the TAPI session can be re-opened. If the "Startup with Windows" option is enabled, then the TSP automatically connects to the configured Cisco Unified CME endpoint. Otherwise, the TAPI session remains closed until the application re-opens the line.

Debug Tracing

Cisco Unified CME TSP 2.1 supports five levels of debug tracing. Debug traces are enabled from the Cisco Unified CME TSP 2.1 Setup Wizard. The trace levels are as follows:

•Trace Level 0—Tracing is turned off. The Trace Level should be set to zero in normal operation to avoid accumulating large trace files.

•Trace Level 1—Provides trace of TAPI function calls and messages.

•Trace Level 2—Provides TSP level of debug trace messages, including TAPI function calls and messages.

•Trace Level 3—Provides TSP level of debug trace messages and summary of Skinny (SCCP) messages.

•Trace Level 4—Provides TSP level of debug trace messages and Skinny message details.

•Trace Level 5—Provides Trace Level 4 and RTP transmission details.

Note Levels 4 and 5 are very verbose and can quickly accumulate large amounts of log data. These modes should only be used at the direction of technical support.

Exception Notes

The following notes relate to some of the exceptions and idiosyncratic behavior you may encounter with Cisco Unified CME TSP 2.1.

Call Origin

The call origin information indicating an internal or external call is determined from the ring type message — Inside Ring or Outside Ring. When there are multiple calls, the TSP associates the ring-type message with the oldest ringing call. In some cases this association may not be correct. In cases where the call origin cannot be determined it is set to external by default.

Line Type

The Cisco Unified CME TSP 2.1 Setup Wizard automatically downloads the line configuration from Cisco Unified CME during the registration process. This configuration information only provides the line name and number. By default the TSP categorizes all the lines as dual-line DNs. For proper operation of the TSP the line types need to be manually set up to correctly reflect the configuration of the DN on the ephone.

Shared Dual Lines

The Cisco Unified CME call-handling model allows only the active ephone of shared dual line DN to receive additional calls. That is, if an ephone is active on a call on a shared DN, other ephones with the same DN will see the DN in use. If a second call is made to the dual-line DN, that call is only presented to the active ephone. The other ephone does not receive any indication of the second call.

Outgoing Calls on Shared Lines

When an outgoing call is made from a shared DN, the "shares" do not receive dialed number information. Therefore the TSP can only provide the call state "Outgoing call" information, but not any name or number.

MAC Address/Device ID

Cisco Unified CME requires a unique ID in the MAC Address format for each ephone. It does not require this to be the actual MAC Address of the PC or endpoint. In phones, this Device ID is normally the MAC Address of the phone. However for the TSP, this can be any number.

Note If a device ID is entered for the TSP, during the registration process Cisco Unified CME matches this device ID to its configuration files. If there is no ephone configured with this device ID, an ephone configuration is automatically created. There are no lines configured for this ephone, however. If incorrect MAC address or device IDs are entered during the TSP configuration process, you must manually remove them from the Cisco Unified CME configuration.