Cisco Unified CallManager TAPI Developers Guide Release 5.0
Chapter 1. Overview
Downloads: This chapterpdf (PDF - 265.0KB) The complete bookPDF (PDF - 3.48MB) | Feedback

Overview

Table Of Contents

Overview

Cisco Unified TSP 5.0 Functions

Call Control

First-Party Call Control

Third-Party Call Control

CTI Port

Dynamic Port Registration

CTI Route Point

Media Termination at Route Point

CTI Manager (Cluster Support)

Cisco Unified CallManager Failure

Call Survivability

CTI Manager Failure

Cisco Unified TAPI Application Failure

Supported Device Types

Forwarding

Redirect and Blind Transfer

lineRedirect

lineDevSpecific - Redirect Reset Original Called ID

lineDevSpecific - Redirect Set Original Called ID

lineDevSpecific - Redirect FAC CMC

lineBlindTransfer

lineDevSpecific - BlindTransfer FAC CMC

Extension Mobility Support

Directory Change Notification Handling

Monitoring Call Park Directory Numbers

Multiple Cisco Unified TSPs

Multiple Calls per Line Appearance

Maximum Number of Calls

Busy Trigger

CFNA Timer

Shared Line Appearance

Select Calls

Direct Transfer

Join

Privacy Release

Barge and cBarge

Cisco Unified TSP Auto Update Functionality

QoS Support

Presentation Indication (PI)

Compatibility

Unicode Support

TLS Support

SRTP Support

FAC/CMC Support

CTI Port Third Party Monitoring Port

CTI Device/Line Restriction

XSI Object Pass Through


Overview


This chapter outlines the key concepts that are involved in using Cisco Unified TAPI service provider (Cisco Unified TSP) and lists the functions available in the Cisco Unified CallManager Release 5.0 implementation. The Cisco Unified TAPI service provider shipped with Cisco Unified CallManager Release 5.0 is TAPI version 2.1.

Cisco Unified TSP 5.0 Functions

The following list includes all the functions that are available in the Cisco TSP implementation for Cisco Unified CallManager Release 5.0:

Call Control

CTI Port

Dynamic Port Registration

CTI Route Point

Media Termination at Route Point

CTI Manager (Cluster Support)

Supported Device Types

Forwarding

Redirect and Blind Transfer

Extension Mobility Support

Directory Change Notification Handling

Monitoring Call Park Directory Numbers

Multiple Cisco Unified TSPs

Multiple Calls per Line Appearance

Shared Line Appearance

Select Calls

Direct Transfer

Join

Privacy Release

Barge and cBarge

Cisco Unified TSP Auto Update Functionality

QoS Support

Presentation Indication (PI)

Compatibility

Unicode Support

TLS Support

SRTP Support

FAC/CMC Support

CTI Port Third Party Monitoring Port

CTI Device/Line Restriction

XSI Object Pass Through

Call Control

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

First-Party Call Control

In first-party call control, the application terminates the audio stream. Ordinarily, this occurs using the Cisco wave driver. However, if you want the application to control the audio stream instead of the wave driver, use the Cisco Device Specific extensions.

Third-Party Call Control

In third-party call control, the control of an audio stream terminating device is not "local" to the Cisco Unified CallManager. In such cases, the controller might be the physical IP phone on your desk or a group of IP phones for which your application is responsible.

CTI Port

For first-party call control, a CTI port device must exist in the Cisco Unified CallManager. Because each port can only have one active audio stream at a time, most configurations only need one line per port.

A CTI port device does not actually exist in the system until you run a TAPI application and a line on the port device is opened requesting LINEMEDIAMODE_AUTOMATEDVOICE and LINEMEDIAMODE_INTERACTIVEVOICE. Until the port is opened, anyone calling the directory number associated with that CTI port device receives a busy or reorder tone.

The IP address and UDP port number is either specified statically (the same IP address and UDP port number is used for every call) or dynamically. By default, CTI Ports use static registration.

Dynamic Port Registration

The purpose of the Dynamic Port Registration feature is to allow applications to specify the IP address and UDP port number on a call-by-call basis. Currently, the IP address and UDP port number are specified when a CTI Port registers and is static through the life of the registration of the CTI Port. When media is requested to be established to the CTI Port, the same static IP address and UDP port number is used for every call.

An application that wishes to use Dynamic Port Registration must specify the IP address and UDP port number on a call before invoking any features on the call. If the feature is invoked before the IP address and UDP port number are set, the feature will fail and the call state will be set depending on when the media timeout occurs.

CTI Route Point

You can use Cisco Unified TAPI to control CTI route points. CTI route points allow Cisco Unified TAPI applications to redirect incoming calls with an infinite queue depth. This allows incoming calls to avoid busy signals.

CTI route point devices have an address capability flag of LINEADDRCAPFLAGS_ROUTEPOINT. When your application opens a line of this type, it can handle any incoming call by disconnecting, accepting, or redirecting the call to some other directory number. The basis for redirection decisions can be caller ID information, time of day, or other information that is available to the program.

Media Termination at Route Point

The purpose of the Media Termination at Route Point feature is to allow applications to terminate media at route points. This feature enables applications to pass the IP address and port number where they want the call at the route point to have media established.

Following are the features supported at route points:

Answer

Multiple active calls

Redirect

Hold

UnHold

Blind Transfer

DTMF Digits

Tones

CTI Manager (Cluster Support)

The CTI Manager, along with the Cisco Unified TSP, provide an abstraction of the Cisco Unified CallManager cluster that allows TAPI applications to access Cisco Unified CallManager resources and functionality without being aware of any specific Cisco Unified CallManager. The Cisco Unified CallManager cluster abstraction also enhances the failover capability of CTI Manager resources. A failover condition occurs when a Cisco Unified CallManager node fails, a CTI Manager fails, or a TAPI application fails, as illustrated in Figure 1-1.

Figure 1-1 Cluster Support Architecture

Cisco Unified CallManager Failure

When a Cisco Unified CallManager node in a cluster fails, the CTI Manager recovers the affected CTI ports and route points by reopening these devices on another Cisco Unified CallManager node. When the failure is first detected, Cisco Unified TSP sends a PHONE_STATE (PHONESTATE_SUSPEND) message to the TAPI application.

When the CTI port/route point is successfully reopened on another Cisco Unified CallManager, Cisco Unified TSP sends a phone PHONE_STATE (PHONESTATE_RESUME) message to the TAPI application. If no Cisco Unified CallManager is available, the CTI Manager waits until an appropriate Cisco Unified CallManager comes back in service and tries to open the device again. The lines on the affected device also go out of service and in service with the corresponding LINE_LINEDEVSTATE (LINEDEVSTATE_OUTOFSERVICE) and LINE_LINEDEVSTATE (LINEDEVSTATE_INSERVICE) events sent by Cisco Unified TSP to the TAPI application. If for some reason the device or lines cannot be opened, even when all Cisco Unified CallManagers come back in service, the devices or lines are closed, and Cisco Unified TSP will send PHONE_CLOSE or LINE_CLOSE messages to the TAPI application.

When a failed Cisco Unified CallManager node comes back in service, CTI Manager "re-homes" the affected CTI ports or route points back to their original Cisco Unified CallManager. The graceful re-homing process ensures that the re-homing only starts when calls are no longer being processed or are active on the affected device. For this reason, the re-homing process may not finish for a long time, especially for route points, which can handle many simultaneous calls.

When a Cisco Unified CallManager node fails, phones currently re-home to another Cisco Unified CallManager node in the same cluster. If a TAPI application has a phone device opened and the phone goes through the re-homing process, CTI Manager automatically recovers that device, and Cisco Unified TSP sends a PHONE_STATE (PHONESTATE_SUSPEND) message to the TAPI application. When the phone successfully re-homes to another Cisco Unified CallManager node, Cisco Unified TSP sends a PHONE_STATE (PHONESTATE_RESUME) message to the TAPI application.

The lines on the affected device also go out of service and in service and Cisco Unified TSP sends LINE_LINEDEVSTATE (LINEDEVSTATE_OUTOFSERVICE) and LINE_LINEDEVSTATE (LINEDEVSTATE_INSERVICE) messages to the TAPI application.

Call Survivability

When a device or Cisco Unified CallManager failure occurs, no call survivability exists; however, media streams that are already connected between devices will survive. Calls in the process of being set up or modified (transfer, conference, redirect) simply get dropped.

CTI Manager Failure

When a primary CTI Manager fails, Cisco Unified TSP sends a PHONE_STATE (PHONESTATE_SUSPEND) message and a LINE_LINEDEVSTATE (LINEDEVSTATE_OUTOFSERVICE) message for every phone and line device that the application opened. Cisco Unified TSP then connects to a backup CTIManager. When a connection to a backup CTI Manager is established and the device or line successfully reopens, the Cisco Unified TSP sends a PHONE_STATE (PHONESTATE_RESUME) or LINE_LINEDEVSTATE (LINEDEVSTATE_INSERVICE) message to the TAPI application. If the Cisco Unified TSP is unsuccessful in opening the device or line for a CTI port or route point, the Cisco Unified TSP closes the device or line by sending the appropriate PHONE_CLOSE or LINE_CLOSE message to the TAPI application.

After Cisco Unified TSP is connected to the backup CTIManager, Cisco Unified TSP will not reconnect to the primary CTIManager until the connection is lost between Cisco Unified TSP and the backup CTIManager.

If devices are added to or removed from the user while the CTI Manager is down, Cisco Unified TSP generates PHONE_CREATE/LINE_CREATE or PHONE_REMOVE/LINE_REMOVE events, respectively, when connection to a backup CTI Manager is established.

Cisco Unified TAPI Application Failure

When a Cisco TAPI application fails, that is, the CTI Manager closes the provider, calls at CTI ports and route points that have not yet been terminated get redirected to the Call Forward On Failure (CFF) number that has been configured for them. New calls into CTI Ports and Route Points that are not opened by an application are routed to their CFNA number.

Supported Device Types

Cisco Unified TSP supports the following device types:

30 SP+ (This device has spurious offhook problems, not recommended.)

12 SP+ (This device has spurious offhook problems, not recommended.)

12 SP (This device has spurious offhook problems, not recommended.)

7835

7902

7905

7910

7912

7914

7940

7960

7965

7970

CTI Route Points

CTI Ports

VG248 Analog Devices

ATA186 Analog Devices

Forwarding

Cisco Unified TSP now provides added support for the lineForward() request to set and clear ForwardAll information on a line. This will allow TAPI applications to set the Call Forward All setting for a particular line device. Activating this feature will allow users to set the call forwarding Unconditionally to a forward destination.

Cisco Unified TSP sends LINE_ADDRESSSTATE messages when lineForward() requests successfully complete. These events also get sent when call forward indications are obtained from the CTI, indicating that a change in forward status has been received from a third party, such as the Cisco Unified CallManager Administration or another application setting call forward all.

Redirect and Blind Transfer

The Cisco Unified TSP supports several different methods of Redirect and Blind Transfer. This section outlines the different methods as well as the differences between each method.

lineRedirect

This is the standard TAPI lineRedirect function. It is used to redirect calls to a specified destination. The Calling Search Space and Original Called Party used by Cisco Unified TSP for this function are as follows:

Calling Search Space (CSS) — Uses CSS of the CallingParty (the party being redirected) for all cases unless the call is in a conference or a member of a two-party conference where it uses the CSS of the RedirectingParty (the party that is doing the redirect).

Original Called Party — not changed.

lineDevSpecific - Redirect Reset Original Called ID

This function is used to redirect calls to a specified destination while resetting the Original Called Party to the party that is redirecting the call. The Calling Search Space and Original Called Party used by Cisco Unified TSP for this function are as follows:

Calling Search Space (CSS) — Uses CSS of the CallingParty (the party being redirected).

Original Called Party — set to the RedirectingParty (the party that is redirecting the call).

lineDevSpecific - Redirect Set Original Called ID

This function is used to redirect calls to a specified destination while allowing the application to set the Original Called Party to any value. The Calling Search Space and Original Called Party used by Cisco Unified TSP for this function are as follows:

Calling Search Space (CSS) — Uses CSS of the CallingParty (the party being redirected).

Original Called Party — set to the preferredOriginalCalledID specified in the lineDevSpecific function.

This request can be used to implement the Transfer to Voice Mail feature (TxToVM). Using this feature, applications can transfer the call on a line directly to another line's voice mailbox. TxToVM can be achieved by specifying the following fields in the above request: voice mail pilot as the destination DN and the DN of the line to whose voice mail box the call is to be transferred as the preferredOriginalCalledID.

lineDevSpecific - Redirect FAC CMC

This function is used to redirect calls to a specified destination that requires either a FAC, CMC, or both. The Calling Search Space and Original Called Party used by Cisco Unified TSP for this function are as follows:

Calling Search Space (CSS) — Uses CSS of the CallingParty (the party being redirected).

Original Called Party — not changed.

lineBlindTransfer

This is the standard TAPI lineBlindTransfer function. It is used to blind transfer calls to a specified destination. The Calling Search Space and Original Called Party used by Cisco Unified TSP for this function are as follows:

Calling Search Space (CSS) — Uses CSS of the TransferringParty (the party that is transferring the call).

Original Called Party — set to the TransferringParty (the party that is transferring the call).

lineDevSpecific - BlindTransfer FAC CMC

This function is used to blind transfer calls to a specified destination that requires either a FAC, CMC, or both. The Calling Search Space and Original Called Party used by Cisco Unified TSP for this function are as follows:

Calling Search Space (CSS) — Uses CSS of the TransferringParty (the party that is transferring the call).

Original Called Party — set to the TransferringParty (the party that is transferring the call).

Extension Mobility Support

Extension Mobility, a Cisco Unified CallManager feature, allows a user to log in and log out of a phone. Cisco Unified CallManager Extension Mobility loads a user Device Profile (including line, speed dial numbers, and so on) onto the phone when the user logs in.

Cisco Unified TSP recognizes a user who is logged into a device as the Cisco Unified TSP User.

Using the Cisco Unified CallManager Administration pages, you can associate a list of controlled devices with a user.

When the Cisco Unified TSP user logs into the device, the lines that are listed in the user's Extension Mobility profile are placed on the phone device, and lines previously on the phone are removed. If the device is not in the controlled device list for the Cisco Unified TSP User, the application receives a PHONE_CREATE or LINE_CREATE message. If the device is in the controlled list, the application receives a LINE_CREATE message for the added line and a LINE_REMOVE message for the removed line.

When the user logs out, the original lines get restored. For a non-controlled device, the application perceives a PHONE_REMOVE or LINE_REMOVE message. For a controlled device, it perceives a LINE_CREATE message for an added line and a LINE_REMOVE message for a removed line.

Directory Change Notification Handling

The Cisco Unified TSP sends notification events when a device has been added to or removed from the user's controlled device list in the directory. Cisco Unified TSP sends events when the user is deleted from the Cisco Unified CallManager Administration pages.

Cisco Unified TSP sends a LINE_CREATE or PHONE_CREATE message when a device is added to a users' control list.

It sends a LINE_REMOVE or PHONE_REMOVE message when a device is removed from the user's controlled list or the device is removed from database.

When the Cisco Unified CallManager system administrator deletes the current user, Cisco Unified TSP generates a LINE_CLOSE and PHONE_CLOSE message for each open line and open phone. After doing this, it sends a LINE_REMOVE and PHONE_REMOVE message for all lines and phones.


Note Cisco Unified TSP generates PHONE_REMOVE / PHONE_CREATE messages only if the application called the phoneInitialize function earlier.

Change notification is generated if the device is added to or removed from the user by using the Cisco Unified CallManager Administration pages or Bulk Administration Tool (BAT).

If you program against the LDAP directory, change notification does not generate.


Monitoring Call Park Directory Numbers

The Cisco Unified TSP supports monitoring calls on lines that represent Cisco Unified CallManager Call Park Directory Numbers (Call Park DNs). The Cisco Unified TSP uses a device-specific extension in the LINEDEVCAPS structure that allows TAPI applications to differentiate Call Park DN lines from other lines. If an application opens a Call Park DN line, all calls that are parked to the Call Park DN get reported to the application. The application cannot perform any call control functions on any calls at a Call Park DN.

To open Call Park DN lines, you must check the Monitor Call Park DNs check box in the Cisco Unified CallManager User Administration for the Cisco Unified TSP user. Otherwise, the application will not perceive any of the Call Park DN lines upon initialization.

Multiple Cisco Unified TSPs

In the Cisco Unified TAPI solution, the TAPI application and Cisco Unified TSP get installed on the same machine. The Cisco Unified TAPI application and Cisco Unified TSP do not directly interface with each other. A layer written by Microsoft sits between the TAPI application and Cisco Unified TSP. This layer, known as TAPISRV, allows the installation of multiple TSPs on the same machine, and it hides that fact from the Cisco Unified 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 TSP1 exposes 100 lines, and Cisco Unified TSP2 exposes 100 lines. In the single Cisco Unified TSP architecture where Cisco Unified TSP1 is the only Cisco Unified TSP that is installed, Cisco Unified TSP1 would tell TAPISRV that it supports 100 lines, and TAPISRV would tell the application that it can control 100 lines. In the multiple Cisco Unified TSP architecture, where both Cisco Unified TSPs are installed, this means that Cisco Unified TSP1 would tell TAPISRV that it supports 100 lines, and Cisco Unified TSP2 would tell TAPISRV that it supports 100 lines. TAPISRV would add the lines and inform the application that it now supports 200 lines. The application communicates with TAPISRV, and TAPISRV takes care of communicating with the correct Cisco Unified TSP.

Ensure that each Cisco Unified TSP is configured with a different username and password that you administer in the Cisco Unified CallManager Directory. Configure each user in the Directory so devices that are associated with each user do not overlap. Each Cisco Unified TSP in the multiple Cisco Unified TSP system does not communicate with the others. Each Cisco Unified TSP in the multiple Cisco Unified TSP system creates a separate CTI connection to the CTI Manager as shown in Figure 1-2. Multiple Cisco Unified TSPs help in scalability and higher performance.

Figure 1-2 Mutiple Cisco Unified TSPs Connect to CTI Manager

Multiple Calls per Line Appearance

Maximum Number of Calls

The maximum number of calls per Line Appearance is database configurable. This means that the Cisco Unified TSP supports more than two calls per line on MCD (Multiple Call Display) devices. An MCD device is a device that can display more than two call instances per DN at any given time. For non-MCD devices, the Cisco Unified TSP supports a maximum of two calls per line. The absolute maximum number of calls per line appearance is 200.

Busy Trigger

In Cisco Unified CallManager there is a setting, busy trigger, that indicates the limit on the number of calls per line appearance before Cisco Unified CallManager will reject an incoming call. The busy trigger setting is database configurable, per line appearance, per cluster. The busy trigger setting replaces the old call waiting flag per DN. The busy trigger setting cannot be modified using the Cisco Unified TSP.

CFNA Timer

The Call Forward No Answer (CFNA) timer is database configurable, per DN, per cluster. This timer is not configurable using Cisco Unified TSP.

Shared Line Appearance

Cisco Unified TSP supports opening two different lines that each share the same DN. Each of these lines is known as a Shared Line Appearance.

The CUnified CMallows multiple active calls to exist concurrently on each of the different devices that share the same line appearance. Each device is still limited to, at most, one active call and multiple hold or incoming calls at any given time. This functionality can be supported by applications that use the Cisco Unified TSP to monitor and control shared line appearances.

If a call is active on a line that is a shared line appearance with another line, then the call appears on the other line with the dwCallState=CONNECTED and the dwCallStateMode=INACTIVE. Even though the call party information may not be displayed on the actual IP Phone for the call at the other line, the call party information is still reported by Cisco Unified TSP on the call at the other line. This gives the application the ability to decide if it wishes to block this information or not. Also, no call control functions are allowed on a call that is in the CONNECTED INACTIVE call state.

Cisco Unified TSP does not support shared lines on CTI Route Point devices.

In the scenario where a line is calling a DN that contains multiple shared lines, the dwCalledIDName in the LINECALLINFO structure for the line with the outbound call may be empty or set randomly to the name of one of the shared DN's. The reason for this should be obvious as Cisco Unified TSP and the Cisco Unified CallManager cannot resolve which of the shared DN's you are calling until the call is answered.

Select Calls

There is a softkey "Select" on the IP Phones that allows a user the ability to select call instances in order to perform feature activation, such as transfer or conference, on those calls. The action of selecting a call on a line locks that call so that it cannot be selected by any of the shared line appearances. Pressing the "Select" key on a selected call will de-select the call.

The ability to select calls is not supported by Cisco Unified TSP. The reason for this is that all of the Transfer and Conference functions contain parameters indicating which calls the operation should be invoked on. Therefore, there is no reason to support "Select" through Cisco Unified TSP.

Cisco Unified TSP supports the events caused by a user selecting a call on a line that is being monitored by the application. When a call on a line is selected, all of the other lines that share the same line appearance will see the call state change to dwCallState=CONNECTED, and dwCallStateMode=INACTIVE.

Direct Transfer

In Unified CM, a softkey, "Direct Transfer," is provided to transfer the other end of one established call to the other end of another established call, while dropping the feature initiator from those two calls. Here, an established call refers to a call that is either in the onhold state or in the connected state. The "Direct Transfer" feature does not initiate a consultation call and does not put the active call onhold.

A TAPI application can invoke the "Direct Transfer" feature using the TAPI lineCompleteTransfer() function on two calls that are already in the established state. This also means that the two calls do not have to be initially set up using the lineSetupTransfer() function.

Join

In Unified CM, a softkey, "Join," is provided to join all the parties of established calls (at least two) into one conference call. The "Join" feature does not initiate a consultation call and does not put the active call onhold. It also can include more than 2 calls, resulting in a call with more than 3 parties.

Cisco Unified TSP exposes the "Join" feature as a new device specific function which is known as lineDevSpecific() - Join. This function can be performed on two or more calls that are already in the established state. This also means that the two calls do not have to be initially set up using the lineSetupConference() or linePrepareAddToConference() functions.

Cisco Unified TSP also supports the lineCompleteTransfer() function with dwTransferMode=Conference. This function allows a TAPI application to join all the parties of two, and only two, established calls into one conference call.

Cisco Unified TSP also supports the lineAddToConference() function to join a call to an existing conference call that is in the ONHOLD state.

There is a feature interaction issue involving Join, Shared Lines, and the Maximum Number of Calls. The issue occurs when you have two shared lines and the maximum number of calls on one line is less than the maximum number of calls on the other line. If a Join is performed on the line that has more maximum calls, then this issue will be encountered if the primary call of the Join is beyond the maximum number of calls for the other shared line.

For example, in a scenario where one shared line, A, has a maximum number of calls set to 5 and another shared line, A', has a maximum number of calls set to 2. The scenario involves the following steps:

A calls B. B answers. A puts the call onhold.

C calls A. A answers. C puts the call onhold.

At this point, line A has two calls in the ONHOLD state and line A' has two calls in the CONNECTED_INACTIVE state.

D calls A. A answers.

At this point, the call will be presented to A, but it will not be presented to A'. The reason for this is because the maximum calls for A' is set to 2.

A performs a Join operation either through the phone or using the lineDevSpecific - Join API to join all the parties in the conference. It uses the call between A and D as the primary call of the Join operation.

Because the call between A and D was used as the primary call of the Join, the ensuing conference call will not be presented to A'. Both calls on A' will go to the IDLE state. The end result is that A' will not see the conference call that exists on A.

Privacy Release

The Cisco Unified CallManager Privacy Release feature allows the user to dynamically alter its privacy setting. The privacy setting affects all existing and future calls on the device.

Cisco Unified TSP does not support the Privacy Release feature.

Barge and cBarge

The Barge and cBarge features are supported in Cisco Unified CallManager. The Barge feature uses the built-in conference bridge and cBarge uses the shared conference resource in Cisco Unified CallManager.

Cisco Unified TSP supports the events caused by the invocation of the Barge and cBarge features. It does not support invoking either Barge or cBarge through an API of Cisco Unified TSP.

Cisco Unified TSP Auto Update Functionality

Cisco Unified TSP supports auto update functionality so that the latest plug-in can be downloaded and installed on a client machine. The new plug-in will be QBE compatible with the connected CTIManager. When the Cisco Unified CallManager is upgraded to a higher version, and Cisco Unified TSP auto update functionality is enabled, the user will receive the latest compatible Cisco Unified TSP, which will work with the upgraded Cisco Unified CallManager. This makes sure that the applications work as expected with the new release of Cisco Unified CallManager (provided the new call manager interface is backward compatible with the TAPI interface). Cisco Unified TSP installed locally on the client machine allows applications to set the auto update options as part of the Cisco Unified TSP configuration. The user can opt for updating Cisco Unified TSP in following different ways:

Update Cisco Unified TSP whenever a different version (higher version than the existing version) is available on the Cisco Unified CallManager server.

Update Cisco Unified TSP whenever there is a QBE protocol version mismatch between the existing Cisco Unified TSP and the Cisco Unified CallManager version.

Do not update Cisco Unified TSP using Auto Update functionality.

QoS Support

Cisco Unified TSP supports the Cisco baseline for baselining of Quality of Service (QoS). Cisco Unified TSP marks the IP DSCP (Differentiated Services Code Point) for QBE control signals flowing from TSP to CTI with the value of the Cisco Unified CallManager Service parameter "DSCP IP for CTI Applications" as sent by CTI in the ProviderOpenCompletedEvent. The Cisco TAPI Wave driver marks the RTP packets with the value that is sent by CTI in the StartTransmissionEvent. The DSCP value received in the StartTransmissionEvent is stored in the DevSpecific portion of the LINECALLINFO structure and the LINECALLINFOSTATE_DEVSPECIFIC event with the QoS indicator is fired.

Presentation Indication (PI)

There is a need to separate the presentability aspects of a number (calling, called, and so on) from the actual number itself. For example, when the number is not to be displayed on the IP phone, the information might still be needed by another system, such as Unity VM. Hence, each number/name of the display name needs to be associated with a Presentation Indication (PI) flag, which will indicate whether the information should be displayed to the user or not.

This feature can be setup as follows:

On a Per Call Basis

Route Patterns and Translation Patterns can be used to set or reset PI flags for various partyDNs/Names on a per call basis. If the pattern matches the digits, then the PI settings associated with the pattern will be applied to the call information.

On a Permanent Basis

A trunk device can be configured with "Allow" or "Restrict" options for parties. This will set the PI flags for the corresponding party information for all calls from this trunk.

Cisco Unified TSP supports this feature. If calls are made via Translation patterns with all of the flags set to Restricted then the CallerID/Name, ConnectedID/Name and RedirectionID/Name will be sent to applications as Blank. The LINECALLPARTYID flags will also be set to Blocked if both the Name and Party number are set to Restricted.

Compatibility

The Cisco TAPI Service Provider is a TAPI 2.1 service provider.

When developing an application, be sure only to use functions supported by the Cisco TAPI Service Provider. For example, transfer is supported, but fax detection is not. If an application requires a media or bearer mode that is not supported, then it will not work as expected.

Cisco Unified TSP does not support TAPI 3.0 applications.

Unicode Support

Cisco Unified TSP provides support for Unicode character sets.

Cisco Unified TSP will send Unicode party names to the application in all call events. The party name needs to be configured in the CUnified CMadmin pages. This support is limited to only party names. The locale information is also sent to the application. The UCS-2 encoding for Unicode is used.

The party names will be in the DevSpecific portion of the LINECALLINFO structure.

TLS Support

Cisco Unified TSP will start supporting security for signalling and media. It will take care of providing secure CTI QBE signalling through TLS. This will help prevent security attacks like man in the middle, spoofing, and eavesdropping. Signaling data will be passed over a secure channel and will be encrypted. The data on this secure connection can not be viewed by any third party on the network. TLS support provides secure, encrypted and authenticated signaling communication stream between TSP/CTI applications and the CTIManager. This secure signaling path would be used for SRTP keys exchange for media security as well.

SRTP Support

Secure RTP feature is supported from this release. Detail SRTP key information will be reported to applciaiton if there is secure connection to CTIManager and the applcaition user is authorized to receive SRTP information. However there is will be no SRTP key information available for mid-call event, except secure media indicator. And the secure media indicator for each call on the device will be sent as LineCallDevSpecific event upon PhoneDevSpecific request with CPDST_REQUEST_RTP_SNAPSHOT_INFO message type.

During device registration, application has an option to specify algorithm Ids for SRTP feature.

FAC/CMC Support

There are two CallManager features, Forced Authorization Code (FAC) and Client Matter Code (CMC), that the Cisco Unified TSP supports and interacts with. The FAC feature allows the System Administrator the ability to require users to enter an authorization code in order to reach certain dialed numbers. The CMC feature allows the System Administrator the ability to require users to enter a client matter code in order to reach certain dialed numbers.

The CallManager alerts a user of a phone that a FAC or CMC must be entered by sending a "ZipZip" tone to the phone which the phone in turn plays to the user. Cisco Unified TSP will send a new LINE_DEVSPECIFIC event to the application whenever a "ZipZip" tone is to be played by the application. This can be used by the application to indicate when a FAC or CMC is required. For an application to start receiving the new LINE_DEVSPECIFIC event, it must perform the following steps:

1. lineOpen with dwExtVersion set to 0x00050000 or higher

2. lineDevSpecific - Set Status Messages to turn on the Call Tone Changed device specific events

The FAC or CMC code can be entered by the application using the lineDial() API. The code may be entered in its entirety or it may be entered one digit at a time. An application may also enter the FAC and CMC code in the same string as long as they are separated by a "#" character and also ended with a "#" character. The "#" character at the end is optional as it only serves to indicate dialing is complete.

If an application does a lineRedirect() or a lineBlindTransfer() to a destination that requires a FAC or CMC, then Cisco Unified TSP will return an error. The error returned by Cisco Unified TSP indicates whether a FAC, CMC, or both is required. Cisco Unified TSP supports two new lineDevSpecific() functions, one for Redirect and one for BlindTransfer, that will allow an application to enter a FAC or CMC, or both, when either Redirecting or Blind Transferring a call.

CTI Port Third Party Monitoring Port

Opening a CTI port device in first party mode means that either the application is terminating the media itself at the CTI port or that the application is using the Cisco Wave Drivers to terminate the media at the CTI port. This is also known as registering the CTI port device.

Opening a CTI port in third party mode means that the application is interested in just opening the CTI port device, but it does not want to handle the media termination at the CTI port device. An example of this would be a case where an application would want to open a CTI port in third party mode because it is interested in monitoring a CTI port device that has already been opened/registered by another application in first party mode. Please note that opening a CTI Port in third party mode does not prohibit the application from performing call control operations on the line or on the calls of that line.

Cisco Unified TSP allows TAPI applications to open a CTI port device in third party mode via the lineDevSpecific API, provided, the application has negotiated at least extension version 5.0 and set the high order bit so that the extension version is set to at least 0x80050000.

The TAPI architecture allows two different TAPI applications to be running on the same PC using the same Cisco Unified TSP. In this situation, if both applications want to open the CTI port, there could be problems. Therefore, the first application to open the CTI port will control which mode in which the second application is allowed to open the CTI port. In other words, both or all applications running on the same PC, using the same Cisco Unified TSP, must open CTI ports in the same mode in order to be successful. If the second application tries to open the CTI port in a mode that is different from the way in which the first application opened it, then the lineDevSpecific() request will fail.

CTI Device/Line Restriction

With CTI Device/Line restriction implementation, a CTIRestricted flag will be placed on device or line basis. When a device is restricted, it will assume all its configured lines are restricted.

Cisco Unified TSP will not report any restricted devices and lines back to applcaition. And when a CTIRestricted flag is changed from CUnified CMadmin, Cisco Unified TSP will treat it as normal device/line add or removal.

XSI Object Pass Through

XSI-enabled IP phones allow applications to directly communicate with the phone and access XSI features, such as manipulate display, get user input, play tone, and so on. In order to allow TAPI applications access to the XSI capabilities without having to set up and maintain an independent connection directly to the phone, TAPI provides the ability to send the device data through the CTI interface. This feature is exposed as a Cisco Unified TSP device-specific extension.

Only PhoneDevSpecificDataPassthrough request is supported for the IP phone devices.