Cisco TAPI Developer Guide for Cisco CallManager 4.2(1)
Preface
Downloads: This chapterpdf (PDF - 375.0KB) The complete bookPDF (PDF - 5.25MB) | Feedback

Preface

Table Of Contents

Preface

Introduction

Purpose

Audience

New and Changed Information

Cisco TSP 4.2(1) Enhancements

Cisco CallManager Version Compatibility

Windows 2003 Support

Call Forwarding

Privacy on Hold

Directed Call Park

Cisco TSP 4.1(3) Enhancements

Cisco TSP 4.1(2) Enhancements

FAC and CMC Support

CTI Port Third-Party Monitoring

QSIG Path Replacement

Progressing Call State

Transfer/Conference Destination DN in Setup Request Support

Modified Cisco TSP 4.1(2) Entities

Cisco TSP 4.0 Enhancements

Dynamic Port Registration

Media Termination at Route Point

Redirect Support for Blind Transfer

Redirect Set Original Called ID

Multiple Calls per Line Appearance

Shared Line Appearance

Select Calls

Transfer Changes

Direct Transfer

Conference Changes

Call Join

Privacy Release

Barge and cBarge

TSP Auto Update Functionality

QoS Support

Forwarding Changes

Presentation Indication Flag

Modified Cisco TSP 4.0 Entities

Changes from Cisco TSP 3.3 to Cisco TSP 4.0

Line In Service or Out of Service

LINE_CALLINFO

User Deletion from Directory

Removal of lineDevSpecific() - Swap Hold Setup Transfer

Call Reason Enhancements

Changes to phoneSetDisplay()

Cisco TSP 3.3 Enhancements

Reporting TSP Initialization Problems or Errors to the Application

New or Changed Cisco TSP 3.3 Entities

Changes from Cisco TSP 3.2 to Cisco TSP 3.3

User Deletion from Directory

Opening Two Lines on One CTI Port Device

Cisco TSP 3.2 Enhancements

Changes from Cisco TSP 3.1 to Cisco TSP 3.2

Cisco TSP 3.1 Enhancements

Changes from Cisco TSP 3.0 to Cisco TSP 3.1

Line In Service or Out of Service

LINE_CALLINFO

New or Changed Cisco TSP 3.1 Entities

Organization

Related Documentation

Required Software

Supported Windows Platforms

Conventions

Obtaining Documentation

Cisco.com

Documentation DVD

Ordering Documentation

Documentation Feedback

Cisco Product Security Overview

Reporting Security Problems in Cisco Products

Obtaining Technical Assistance

Cisco Technical Support Website

Submitting a Service Request

Definitions of Service Request Severity

Obtaining Additional Publications and Information


Preface


This chapter introduces Cisco Telephony Application Programmer's Interface (TAPI) implementation, describes the purpose of this document, and outlines the required software. The chapter includes the following topics:

Introduction

Purpose

Audience

New and Changed Information

Organization

Related Documentation

Required Software

Supported Windows Platforms

Conventions

Obtaining Documentation

Documentation Feedback

Cisco Product Security Overview

Obtaining Technical Assistance

Obtaining Additional Publications and Information

Introduction

Telephony Application Programmer's Interface (TAPI) comprises the set of classes and principles of operation that constitute a telephony application programming interface. TAPI implementations provide the interface between computer telephony applications and telephony services. The Cisco CallManager includes a TAPI Service Provider (Cisco TSP). The Cisco TAPI Service Provider allows developers to create customized IP telephony applications for Cisco users; for example, voice messaging with other TAPI compliant systems, automatic call distribution (ACD), and caller ID screen popups. Cisco TSP enables the Cisco IP Telephony system to understand commands from the user-level application such as Cisco SoftPhone via the operating system.

The Cisco TAPI implementation uses the Microsoft TAPI v2.1 specification and supplies extension functions to support Cisco IP Telephony Solutions. To enable a Cisco TAPI-based solution, you must have the following:

TAPI support/service that is running on the operating system

A TAPI-based software application

A Cisco IP Telephony phone system


Note The system does not support using Cisco TAPI 2.1 TSP via the TAPI 3.x compatibility layer.


Purpose

This document describes the Cisco TAPI implementation by detailing the functions that comprise the implementation software and illustrating how to use these functions to create applications that support the Cisco IP Telephony hardware, software, and processes. Use this document with the Cisco CallManager manuals to develop applications.

A primary goal of a standard Application Programming Interface (API) such as TAPI specifies providing an unchanging programming interface under which varied implementations may stand. Cisco's goal in implementing TAPI for the Cisco CallManager platform remains to conform as closely as possible to the TAPI specification, while providing extensions that enhance TAPI and expose the advanced features of Cisco CallManager to applications.

As new versions of Cisco CallManager and the Cisco TSP are released, variances in the API should be very minor and should tend in the direction of compliance. Cisco stays committed to maintaining its API extensions with the same stability and reliability, though additional extensions may be provided as new Cisco CallManager features become available.

Audience

Cisco intends this document to be for use by telephony software engineers who are developing Cisco telephony applications that require TAPI. This document assumes that the engineer is familiar with both the C or C++ languages and the Microsoft TAPI specification.

New and Changed Information

This section describes new features and changes for Cisco TAPI that are pertinent to the specified release of Cisco CallManager.

Cisco TSP 4.2(1) Enhancements

This section describes the Cisco TSP enhancements for Cisco CallManager 4.2(1).

Cisco CallManager Version Compatibility

It is not necessary to upgrade Cisco TSP when upgrading to Cisco CallManager 4.2(1), unless you want to use features that are new for the 4.2(1) release. Previously, it was required to upgrade Cisco TSP when upgrading Cisco CallManager.

Windows 2003 Support

Cisco TSP is now supported on Windows 2003.

Call Forwarding

Cisco CallManager 4.2(1) provides enhancements to the forwarding and Automated Alternate Routing (AAR) logic to redirect calls that cannot be connected due to no bandwidth or an unregistered directory number.

No Bandwidth

In this scenario a call comes in from a gateway at the central site (Centralized Call Manager Configuration) for a phone at a remote site. Previously, if there was insufficient bandwidth to deliver the call to the remote site and AAR was enabled, Cisco CallManager rerouted the call through PSTN or other network by using an alternate number. The alternate number was derived from the external phone number mask. The AAR could not redirect the call to an alternate destination (for example, a cell phone or voicemail).

Now you can configure an alternate call destination or direct the call to voicemail. The no bandwidth calls are handled by AAR and are rerouted to the AAR Destination Mask or to voicemail.

TAPI applications receive the LINECALLREASON_FWDBUSY call reason in this scenario.

Unregistered Phone

In this scenario, a call is targeted to an unregistered DN. Previously, this type of call was handled by the CFNA (Call Forward No Answer) forwarding logic.

Now Cisco CallManager can determine whether the call was not answered or if the target DN is unregistered. This feature adds a new call forwarding type CFUR (Call Forward Unregistered) to handle the calls which are routed to an unregistered DN.

TAPI applications receive the LINECALLREASON_FWDNOANSWER call reason in this scenario.

Privacy on Hold

A shared line cannot retrieve a held call on which privacy is enabled. However, a shared line can retrieve the call if its privacy mode is disabled.

When a privacy enabled call is put on hold, Cisco TSP reports the call state as CONNECTED INACTIVE for calls on shared lines.

Directed Call Park

Directed Call Park allows you to select a park code at which to park a call. Previously, you could not select the park code; it was assigned automatically.

Cisco TSP sends the prefix code to the application as part of dwConnectedIDName in the format "Park Number:<PrefixCode><DParkDN>". Applications can use <PrefixCode> and <DParkDN> to unpark a parked call.

When the call is parked, unparked or reverted for the directed call park, the call reasons reported by Cisco TSP are the same as for the normal park cases:

LINECALLREASON_UNPARK is reported when the call is unparked.

LINECALLREASON_REMINDER is reported when call park reversion happens.

Cisco TSP 4.1(3) Enhancements

Cisco CallManager release 4.1(3) includes the following Cisco TAP enhancements:

Support for the AutoCallPickup feature. However, Cisco TSP itself does not support the new Auto Call Pickup feature or the existing Call Pickup feature either through the API or by monitoring the call that is being picked up. Cisco TSP contains no interface changes for Release 4.1(3).

A LINE_CALLDEVSPECIFIC event for RTP events. RTP events are generated as a LINE_CALLDEVSPECIFIC event that contains the call handle of the call. To activate the feature, the application must negotiate an extension version great than or equal to 0x00040001 when opening the line.

Cisco TSP 4.1(2) Enhancements

The following sections describe the Cisco TSP enhancements for Cisco CallManager 4.1(2).

FAC and CMC Support

Cisco TSP supports two new Cisco CallManager features: Forced Authorization Codes (FAC) and Client Matter Codes (CMC). The FAC feature allows the System Administrator to require users to enter an authorization code to reach certain dialed numbers. The CMC feature allows the System Administrator require users to enter a client matter code to reach certain dialed numbers.

The Cisco 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. The Cisco TSP will send a new LINE_DEVSPECIFIC event to the application whenever a "ZipZip" tone is to be played by the application. The application can use this 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:

lineOpen with dwExtVersion set to 0x00050000 or higher

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

The application can enter the FAC or CMC code by 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 optional "#" character at the end only serves to indicate to the Cisco CallManager that dialing is complete.

If an application does a lineRedirect() or a lineBlindTransfer() to a destination that requires a FAC or CMC, then the TSP will return an error. The error that is returned by the TSP indicates whether a FAC, CMC, or both is required. The 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

Prior to Cisco TSP 4.1, the TSP allowed TAPI applications to open a CTI port device in first-party mode. First-party mode means either the application is terminating the media itself at the CTI port or the application is using the Cisco Wave Drivers to terminate the media at the CTI port. This action constitutes registering the CTI port device.

In all releases prior to Cisco TSP 4.1, no way existed for a TAPI application that was using the Cisco TSP to open a CTI port in third-party mode. Third party mode means that the application just opens the CTI port device, but it does not handle the media termination at the CTI port device. An example of this instance 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. 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.

In Cisco TSP 4.1, the TSP enhancements allow TAPI applications to open a CTI port device in third-party mode. This provides exposure to TAPI applications via a new lineDevSpecific() API. To use the new lineDevSpecific() API, the application must negotiate for at least extension version 5.0 and set the high order bit so, the extension version is set to at least 0x80050000.

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

QSIG Path Replacement

Cisco TSP 4.1(2) supports events that are generated because of the Cisco CallManager QSIG Path Replacement feature.


Note Call information on a tromboned call across a QSIG gateway does not act consistently. Due to the limitations in the protocol, the application would perceive inconsistent values for LINECALLINFO RedirectingID/name and CalledID/Name.


Progressing Call State

Cisco TSP 4.1(2) supports CtiProgressingCallState as a TAPI LINECALLSTATE_UNKNOWN | CLDSMT_CALL_PROGRESSING_STATE (0x01000000). This call state gets reported to the application if it has negotiated extension version 0x00050001 during lineOpen. Similar changes occur to report the callStatus when the application sends a query using lineGetCallStatus. Only LINE_DROP represents the call feature that is associated to this call state.

The current cause codes that are associated with ProgressingCallState comprise standard Q931 cause codes, and the application must be able to decode them if required. The cause codes get reported only when the application negotiated extension version 0x00050001 or greater.

Transfer/Conference Destination DN in Setup Request Support

The Cisco TSP 4.1(2) enhancement allows it to accept the consult DN for TAPI lineSetupTransfer and lineSetupConference requests through LINECALLPARAMS::devSpecificdata. The application must negotiate extension version 0x00050002 or greater to provide the destination DN in these requests. The support enables promptly dialing the consult destinations. The earlier TSP implementation allowed applications to dial the destination DN by using lineDial method, which introduces a dial delay for each digit and results in a delay in establishing a consult call.

Modified Cisco TSP 4.1(2) Entities

This version contains several enhanced Cisco TAPI device structures, functions, and messages. This table lists each modified entity and its type.

Entity
Type

LINE_DEVSPECIFIC

TAPI line message

LineDevSpecific

TAPI line function

lineSetupTransfer

TAPI line function

lineSetupConference

TAPI line function


Cisco TSP 4.0 Enhancements

The following sections describe the Cisco TSP 4.0 enhancements for Cisco CallManager 4.0.

Dynamic Port Registration

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

This feature allows an application to specify the IP address and UDP port number on a call-by-call basis.

An application that wants 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 gets set depending on when the media timeout occurs.

Media Termination at Route Point

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


Note The maximum number of lines supported for route points is 34.


The system supports the following features at route points:

Answer

Multiple Active Calls

Redirect

Hold

UnHold

Blind Transfer

DTMF Digits

Tones

Redirect Support for Blind Transfer

The Redirect support for the Blind Transfer feature eliminates problems that arise from the consult call that is created during a blind transfer in the earlier Cisco TSPs and also brings it in accordance with the TAPI specification. This means that lineBlindTransfer() now gets properly supported.

Redirect Set Original Called ID

The Redirect Set Original Called ID feature allows applications to redirect a call on a line to another destination while allowing the applications to set the OriginalCalledID to any value.

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

Multiple Calls per Line Appearance

Maximum Number of Calls

With the current Cisco CallManager 3.3, a limit of two applies for the maximum number of calls per line appearance (LA). In Cisco CallManager 4.0, the maximum number of calls per LA has been changed to be database configurable. This means that the Cisco TSP supports more than two calls per line on MCD (Multiple Call Display) devices. An MCD device represents a device that can display more than two call instances per DN at any given time. For non-MCD devices, the Cisco TSP will only support a maximum of two calls per line. The absolute maximum number of calls per line appearance equals 200.

Busy Trigger

In Cisco CallManager 4.0, a new setting, busy trigger, indicates the limit on the number of calls per line appearance before the Cisco CallManager will reject an incoming call. The busy trigger setting as database configurable, per line appearance, per cluster. Consider the busy trigger setting replaces the existing call waiting flag per DN. Because you cannot modify the busy trigger setting by using the Cisco TSP, no changes appear in the TAPI interface that the Cisco TSP exposes as a result of this feature, but busy trigger will have an effect on applications that use the existing call waiting flag per DN.

CFNA Timer

Prior to Cisco CallManager 4.0, you configured the Call Forward No Answer (CFNA) timer through a service parameter. Cisco CallManager 4.0 changes this to be database configurable, per DN, per cluster. Because this timer is not configurable by using the Cisco TSP, no changes to the Cisco TSP to support this feature occurred, but this change will have an effect on applications that use the CFNA feature of the Cisco CallManager.

Shared Line Appearance

In Cisco CallManager 3.3, the Cisco CallManager supports the ability of a line on a device to share the same directory number (DN) as a line on a different device. The Cisco TSP 3.3 did not support opening two different lines that share the same DN.

In Cisco CallManager 4.0, several changes occurred in the Cisco CallManager to the Shared Line Appearance feature. The Cisco TSP enhancements in Release 4.0 support Shared Line Appearances.

In Cisco CallManager 3.3, if more than one device exists that shares the same line appearance, only one of those devices can have an active (connected) call. Also, if one of those devices has an active call that is using this line appearance, then no other device can use this line appearance anymore.

In Cisco CallManager 4.0, the Cisco CallManager enhancements allow multiple active calls to exist concurrently on each different device that shares the same line appearance. The system still limits each device to at most one active call and multiple hold or incoming calls at any given time. Applications that use the Cisco TSP to monitor and control shared line appearances can support this functionality.

If a call is active on a line that is a shared line appearance with another line, then the call will appear on the other line with the dwCallState=CONNECTED and the dwCallStateMode=INACTIVE. Even though the call party information may not display on the actual IP Phone for the call at the other line, the TSP on the call at the other line the call party still reports the information. This means that the application the ability can decide whether it wants to block this information. Also, the system does not allow call control functions on a call that is in the CONNECTED INACTIVE call state.

The Cisco 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 DNs. This occurs because the Cisco TSP and the Cisco CallManager cannot resolve which of the shared DNs you are calling until the call is answered.


Note Cisco TSP does not support configurations that include devices with two or more lines with the same directory numbers (DN) in different partitions.


Select Calls

A new softkey, Select, on the IP phones allows a user to select call instances 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 any of the shared line appearances cannot select it. Pressing the "Select" key on a selected call will deselect the call.

The Cisco TSP does not support the ability to select calls. This applies because all the Transfer and Conference functions contain parameters indicating on which calls the operation should be invoked. No reason exists to support Select through the TSP.

The Cisco TSP supports the events that occur when a user selects a call on a line that the application is monitoring. When a call on a line is selected, all the other lines that share the same line appearance will see the call state change to dwCallState=CONNECTED, and dwCallStateMode=INACTIVE.

Transfer Changes

In Cisco CallManager 3.3, the "Transfer" softkey act in two different ways depending on the number of calls at that DN:

1. If only one active call existed at the DN, the first invocation of the "Transfer" softkey resulted in the active call being put on hold and a new call being initiated using the same DN. Once the new call was set up, the second invocation of the "Transfer" softkey would transfer the calls.

2. If two calls already existed in the line appearance, the first invocation of the "Transfer" softkey resulted in the active call being put on hold, but no new call was initiated. If the other call was not an incoming call, the system highlighted it. Then, the second invocation of the "Transfer" softkey would transfer the calls.

In Cisco CallManager 4.0, the "Transfer" softkey changed, so it always initiates a new consultation call. The preceding Number 1 describes this behavior. You can no longer use the "Transfer" softkey to perform behavior #2. You no longer need behavior #2, sometimes known as "Arbitrary Transfer," is with the addition of the Direct Transfer feature.

Because of these changes, the Cisco TSP removed the lineDevSpecific() - Swap Hold Setup Transfer function. The lineDevSpecific() - Swap Hold Setup Transfer function performs the functionality that is described in behavior #2, and you do not need it any more because of the addition of the "Direct Transfer" feature.

Direct Transfer

In Cisco CallManager 4.0, a new softkey, "Direct Transfer," transfers 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 will not initiate a consultation call and will not put the active call on hold.

The addition of the "Direct Transfer" feature makes the Cisco TSP function lineDevSpecific() - Swap Hold Setup Transfer obsolete. A TAPI application can invoke the "Direct Transfer" feature by 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 set up initially by using the lineSetupTransfer() function.

Conference Changes

In Cisco CallManager 3.3, the "Conference" softkey acted in two different ways depending on the number of calls at that DN.

1. If only one active call existed at the DN, the first invocation of the "Conference" softkey resulted in the active call being put on hold and a new call being initiated using the same DN. After the new call was setup, the second invocation of the "Conference" softkey created a conference call between all the parties that were connected on both calls.

2. If two calls already existed in the line appearance, the first invocation of the "Conference" softkey resulted in the active call being put on hold, but no new call was initiated. If the other call was not an incoming call, the system highlighted it. Then, the second invocation of the "Conference" softkey created a conference call between all the parties that were connected on both calls.

In Cisco CallManager 4.0, the "Conference" softkey changed so it always initiates a new consultation call. The preceding #1 describes this behavior. You can no longer use the "Conference" softkey to perform behavior #2. You no longer need behavior #2, sometimes known as "Arbitrary Conference," anymore with the addition of the "Join" feature that is described later in this document.

Call Join

In Cisco CallManager 4.0, a new softkey, "Join," joins all the parties of established calls, which must equal at least two, into one conference call. The "Join" feature will not initiate a consultation call and will not put the active call on hold. It also can include more than two calls, resulting in a call with more than three parties.

In Cisco CallManager 4.0, the Cisco TSP exposed the "Join" feature as a new device-specific function that will be known as lineDevSpecific() - Join. You can perform this function on two or more calls that are already in the established state. This also means that you do not have to set up the two calls initially by using the lineSetupConference() or linePrepareAddToConference() functions.

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

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

A feature interaction issue involves Join, Shared Lines, and the Maximum Number of Calls. The issue occurs when you have two shared lines and the maximum calls on one line is less than the maximum 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 goes beyond the maximum number of calls for the other shared line.

For example, 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:

1. A calls B. B answers. A puts the call on hold.

2. C calls A. A answers. C puts the call on hold.

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

3. D calls A. A answers.

At this point, the call gets presented to A, but it does not get presented to A'. This occurs because the maximum calls for A' is set to 2.

4. A performs a Join operation either through the phone or by using the lineDevSpecific - Join API to join all 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 does not get presented to A'. Both calls on A' will go to the IDLE state. As the end result, A' will not see the conference call that exists on A.

Privacy Release

In Cisco CallManager 3.2 and Cisco CallManager 3.3, a service-wide parameter, BargeEnabled, controlled the privacy feature. Cisco CallManager 4.0 removed this parameter.

Cisco CallManager 4.0 fully implemented the Privacy feature, which allows the user to dynamically alter the privacy setting. The privacy setting will affect all existing and future calls on the device.

In Cisco CallManager 4.0, the Cisco TSP does not get enhanced to support the Privacy Release feature.

Barge and cBarge

Cisco CallManager 3.3 currently supports the Barge feature. In Cisco CallManager 3.3, the Barge feature always uses the built-in conference bridge at the target device. The Cisco CallManager 3.3 version of the Cisco TSP did not support handling the events that were caused by the invocation of the Barge feature on the phones. The TSP also did not support an API that allows the invocation of the Barge feature.

In Cisco CallManager 4.0, changes in the Cisco CallManager allow the TSP to support the events that the Barge feature causes. Also in Cisco CallManager 4.0, the Cisco CallManager implemented a new feature, cBarge, which always uses the shared conference resource in the Cisco CallManager, that is also known as a conference bridge, as opposed to the built-in bridge on the phone. In Cisco CallManager 4.0, the TSP does not support an API to invoke either the Barge feature or the cBarge feature. The TSP only supports the events that invocation of the Barge and cBarge features caused.

TSP Auto Update Functionality

Cisco TSP supports auto update functionality, so 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 CallManager is upgraded to a higher version, and Cisco TSP auto update functionality is enabled, user will receive the latest compatible Cisco TSP, which will work with the upgraded Cisco CallManager. This ensures that the applications work as expected with the new release of Cisco CallManager (provided the new call manager interface is backward compatible with the TAPI interface). The Cisco TSP installed locally on the client machine allows the application to set the auto update options as part of the Cisco TSP configuration. You can opt for updating the Cisco TSP in the following different ways:

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

Update Cisco TSP whenever a QBE protocol version mismatch occurs between the existing Cisco TSP and the Cisco CallManager version.

Do not update Cisco TSP by using Auto Update functionality.

AutoInstall Behavior

As part of initialization of Cisco TSP, when the application does lineInitializeEx, Cisco TSP will query the current TSP plug-in version information that is available on the Cisco CallManager server. After this information is available, Cisco TSP will compare the installed Cisco TSP version with the plug-in version. If the user selected an option for auto update, Cisco TSP will trigger the update process. As part of Auto update, Cisco TSP will behave in following ways on different platforms.

On Windows 95, Windows 98, Windows ME

Because Cisco TSP is in use and locked when the application does lineInitializeEx, the auto update process will request user to close all running applications to install the new TSP version on the client setup. If the user closes all the running applications, Cisco TSP auto update process will succeed, and the user receives notice about the success. If user does not close running applications and still continues with the installation, the new version of Cisco TSP will not be installed and the corresponding error will get reported to applications.

On Windows NT

After Cisco TSP detects that an upgradeable version is available on the Cisco CallManager server and the user has chosen to auto update, Cisco TSP will report 0 lines to the application and will remove the Cisco TSP provider from the provider list. It will then try to stop the telephony service to avoid any locked files during auto upgrade. If the telephony service can be stopped, TSP auto updates silently, and the service restarts. You must reinitialize applications to start using the Cisco TSP. If the telephony service could not be stopped, then Cisco TSP will install the new version and notify the user to restart the system. The user must restart the system to use the new Cisco TSP.

On Windows 2000/XP

After Cisco TSP detects that an upgradeable version is available on the Cisco CallManager server and the user has chosen to auto update, Cisco TSP will report 0 lines to the application and will remove the Cisco TSP provider from the provider list. If a new TSP version is detected during reconnect time, the running applications will receive LINE_REMOVE on all the lines that are already initialized and are in OutOfService state. Cisco TSP will silently upgrade itself to new version that is downloaded from Cisco CallManager and will add back the provider to the provider list. All running applications receive LINE_CREATE messages.

Windows XP supports multiple user logon sessions (fast user switching); in Release 4.0, the system supports auto update only for the first logon user. If multiple active logon sessions occur, TSP will only support the auto update functionality for the first logged-on user.


Note When the user has multiple Cisco TSPs installed on the client machine, only the first Cisco TSP instance gets enabled to set up the auto update configuration. All Cisco TSPs upgrade to a common version upon version mismatch. See "Control Panel/Phone & Modem Options/Advanced/Cisco TSP001" - General page for the options for auto update.


The user can change the location of the plug-in to be a different machine than the Cisco CallManager server. The user can configure a CTI service parameter; the default specifies "//<CMServer>//ccmpluginsserver".

If Silent upgrade fails on any listed platforms due to any reason (for example, locked files encountered during upgrade on Win95/98/ME), the old Cisco TSP provider/s do not get added back to the provider list to avoid any looping of auto update process. The user needs to clear the update options and needs to add the providers back to the provider list manually. User can update the Cisco TSP manually or by fixing the problem/s encountered during auto update and reinitializing TAPI to trigger the auto update process.


Note TSPAutoInstall.exe includes UI screens and can these screens only when the telephony service enables the LocalSystem logon option with "Allow Service to interact with user". If the logon option is not set as LocalSystem or the logon option is LocalSystem but "Allow Service to interact with User" is disabled, TSP cannot launch the AutoInstall UI screens and will not continue with AutoInstall.


The user must ensure that the following logon options are set for the telephony service.

Logon as: LocalSystem

Enable check box: "Allow Service to interact with Desktop"

These telephony service settings, when changed, require the user to manually restart the service to take effect.

If the user does not restart the service after changing the settings to the preceding values, the TSP checks that "Allow Service to interact with user" is positive (as the configuration is updated for the service in the database), but the AutoInstall UI cannot be displayed. TSP will continue to put the entry for TSPAutoInstall.exe under Registry key RUNONCE. This will help autoinstall run when the machine reboots next time.

QoS Support

Cisco TSP 4.0 supports the Cisco baseline for quality of service. TSP marks the IP DSCP (Differentiated Services Code Point) for QBE control signals that flow from TSP to CTI with Class 3 DSCP marking as 0x18. The Cisco TAPI wave driver will mark the RTP packets with EF DSCP marking as 0x2E. TSP does not allow user to configure these values but instead defaults them to preceding values. No change occurs in the TAPI interface to support QoS. If the underlying network is enabled for DSCP, it makes use of the IP header DSCP bit marking and routes the traffic accordingly.

Forwarding Changes

A slight change in behavior occurs in Cisco TSP 4.0 in forwarding. The scenario follows. The user manually sets a line to FwdAll to the Voice Mail Pilot Number on the phone. An application then turns forwarding off on the same line. Prior to Cisco TSP 4.0 and Cisco CallManager 4.0, the calls that come into the line would still get forwarded to the voice-messaging system. In Cisco TSP 4.0 and Cisco CallManager 4.0, the calls that come into the line will no longer get forwarded to the voice-messaging system.

Presentation Indication Flag

A need exists 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 display on the IP phone, another system like, Cisco Unity, still needs the information. 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 display to the user.

You can set up this feature as follows:

On a Per Call Basis—Use Route Patterns and Translation Patterns 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 apply to the call information.

On a Permanent basis—You can configure 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.

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

Modified Cisco TSP 4.0 Entities

Several modified Cisco TAPI device structures, functions, and messages enhance overall functionality in this version. This table lists each modified entity and its type.

Entity
Type

LINE_CALLSTATE

TAPI Line Message

LINEADDRESSCAPS

TAPI Line Device Structure

LINECALLSTATUS

TAPI Line Device Structure

lineAddToConference

TAPI Line Function

lineCompleteTransfer

TAPI Line Function

lineDevSpecific

TAPI Line Function


Changes from Cisco TSP 3.3 to Cisco TSP 4.0

Line In Service or Out of Service

In Cisco TSP 3.0, the default places a line in service when it is opened. With cluster abstraction (the CTI Manager) in Cisco TSP 3.1, after an application successfully opens a line or phone, the line or phone could remain out of service. Immediately after opening the device, the application should check its status. If the device is out of service, the application should wait for an in-service message before initiating a TAPI request that results in Cisco CallManager interaction. If an application initiates such a request while the device is out of service, Cisco TSP responds with a resource unavailable message.

This behavior represents a change from the behavior in Cisco TSP 3.0. In Cisco TSP 3.0, a device successfully opened as always in-service.

This change does not present an issue for an application if the application checks the line or phone status immediately after the lineOpen or phoneOpen function call.

LINE_CALLINFO

Cisco TSP 3.0 added complete support for the fields of the LINE_CALLINFO message.

The LINE_CALLINFO parameter dwCalledID correctly reflects the OriginalCalledParty information.

User Deletion from Directory

In previous releases, when the TSP user was removed from the Cisco CallManager directory, the TSP would place all lines and phones OUTOFSERVICE/SUSPENDED indefinitely until the lines and phones are closed.

In Cisco TSP 3.3, when the TSP user gets removed, the TSP now closes all lines and phones and sends LINE_CLOSE/PHONE_CLOSE messages. After doing this, the TSP removes all lines and phones and sends LINE_REMOVE/PHONE_REMOVE messages.

Removal of lineDevSpecific() - Swap Hold Setup Transfer

Cisco TSP 4.0 removed the lineDevSpecific() - Swap Hold Setup Transfer function because of the changes made to the Transfer feature in the Cisco CallManager and because of the addition of the Direct Transfer feature.

Call Reason Enhancements

In Cisco TSP 3.3, the TSP did not properly support the TAPI call reason model. For example, in a lineRedirect() function, both the party that was redirected and the party to whom the call was redirected had the LINECALLREASON_REDIRECT set in the dwReason of LINECALLINFO. In TAPI, only the destination of the redirect should have LINECALLREASON_REDIRECT while the party that was redirected should maintain the same dwReason that it had before the redirect occurred. In Cisco TSP 4.0, the TSP properly supports call reasons as defined in the TAPI specification.

Changes to phoneSetDisplay()

In releases prior to Cisco CallManager 4.0, Cisco CallManager messages that passed to the phone would automatically overwrite any messages that were sent to the phone by using phoneSetDisplay(). In Cisco CallManager 4.0, the message that is sent to the phone in the phoneSetDisplay() API will remain on the phone until the phone is rebooted. If the application wants to clear the text from the display and see the Cisco CallManager messages again, a NULL string, not spaces, should pass in the phoneSetDisplay() API. In other words, ensure the lpsDisplay parameter is NULL and the dwSize is set to 0.

Cisco TSP 3.3 Enhancements

The following Cisco TSP 3.3 enhancements exist for Cisco CallManager 3.3:

Support for linePark and lineUnpark

Support for monitoring CallPark Directory Numbers using lineOpen

Support for Cisco IP Phones 7902, 7912, and 7935

Reporting TSP Initialization Problems or Errors to the Application

Cisco TSP now reports the initialization error code through a registry key that enables applications to better diagnose initialization problems. The newly added registry key is HKEY_LOCAL_MACHINE\SOFTWARE\Cisco Systems, Inc.\Cisco TSP\Cisco TSP001\TSPInitializationErrorCode.


Note Each TSP instance (in case of multiple TSP installation) includes its own TSPInitializationErrorCode in the respective registry key HKEY_LOCAL_MACHINE\SOFTWARE\cisco systems, Inc.\Cisco TSP\Cisco TSPXXX.


The following error codes get exposed to the user. CiscoLineDevspecificmsg.h provides the definitions.

#define TSP_WILL_RECONNECT 0x80000000

This high bit gets set when TSP performs reconnection to configured CTIManagers. Usually when TSP initialization with CTI fails due to temporary failure reasons, such as CTI not initialized or request timeouts, TSP reconnects to CTI. In those situations, TSP returns 0 devices for the initial TSPI_ProviderEnumDevices request and enumerates the devices when connection to CTI is reestablished. After enumeration, TSP informs the devices to TAPI applications through LINE_CREATE / PHONE_CREATE messages.

#define TSP_SUCCESS 0x00000000

#define TSPERR_INTERNAL 0x00000001

This error indicates that some Internal TSP error occurred. Collect the appropriate TSP traces and send it to TSP developer support to further diagnose the issue.

#define TSPERR_CONNECT_TO_CTI_FAILED 0x00000002

This error indicates socket connection to CTIManager failed; either the service is not up and running on the server, or configured CTIManager IPAddress is invalid or unreachable.

#define TSPERR_INIT_AUTHENTICATION_REQUEST_TIMEOUT 0x00000003

This error indicates username, password, and authentication request for CTI access timed out. TSP reconnects in this situation.

#define TSPERR_INIT_CTI_NOT_INITIALIZED 0x00000004

This error indicates CTI is not yet completely initialized, so TSP can reconnect within ReconnectInterval.

#define TSPERR_INIT_CTI_RESPONSE_TIMEOUT 0x00000005

This error indicates the request for initialization (providerOpen) timed out. User needs to configure or verify the settings for ProviderOpenCompletedTimeout, Synchronous message timeout, and CTI service parameter for Synchronous message timeout, so CTI gets more time to initialize the devices/lines and TSP can wait for some more time to get the successful response.

#define TSPERR_INIT_AUTHENTICATION_TEMPORARY_FAILED 0x00000006

This error indicates authentication failed temporarily. TSP reconnects to CTI within ReconnectInterval and can have a successful connection later.

#define TSPERR_INIT_AUTHENTICATION_FAILED 0x00000007

This error indicates authentication failure. User needs to verify the Username or Password. If multiple CTIManagers are configured, TSP attempts to connect to the remaining CTIManagers.

#define TSPERR_INIT_CTI_USE_NOT_ALLOWED_FOR_USER 0x00000008

This error indicates that CTI use for this user is not enabled through Cisco CallManager Administration. This indicates a permanent failure. If multiple CTIManagers are configured, TSP attempts to connect to remaining CTIManagers.

#define TSPERR_INIT_ILLEGAL_MESSAGE 0x00000009

This error indicates invalid message format (internal protocol error). TSP does not reconnect.

#define TSPERR_INIT_INCOMPATIBLE_PROTOCOL_VERSION 0x0000000a

This error indicates internal protocol error - as the QBE version mismatch. The TSP QBE protocol version does not match with the CTI protocol version; therefore, the initialization cannot proceed. TSP does not reconnect.

#define TSPERR_UNKNOWN 0x00000010

This error indicates some internal, unknown error. Do not report this error because this is the default case. This case occurs only when a new error is introduced in CTI-TSP QBE protocol and is not already mapped to new TSP error. Collect the appropriate TSP traces and send it to TSP developer support to further diagnose the issue.

New or Changed Cisco TSP 3.3 Entities

Several Cisco TAPI device structures, functions, and messages that have been added or changed in this version enhance overall functionality. This table lists each new or modified entity and its type.

Entity
Type

LINEDEVCAPS

TAPI Line Device Structure

linePark

TAPI Line Function

lineUnpark

TAPI Line Function


Changes from Cisco TSP 3.2 to Cisco TSP 3.3

This section describes two important changes in Cisco TSP version 3.3:

A change in the way that Cisco TSP behaves when the TSP user is deleted from the Cisco CallManager Directory

Changes that allow opening two lines on the same CTI port device

User Deletion from Directory

In previous releases, when the TSP user was removed from the Cisco CallManager directory, the TSP would place all the lines and phones OUTOFSERVICE/SUSPENDED indefinitely until the lines and phones are closed.

In Cisco TSP 3.3, when the TSP user is removed, the TSP now closes all the lines and phones and sends LINE_CLOSE/PHONE_CLOSE messages. After doing this, the TSP removes all the lines and phones and sends LINE_REMOVE/PHONE_REMOVE messages.

Opening Two Lines on One CTI Port Device

In previous releases, the Cisco TSP opened only one line at a time on CTI port devices that are configured with multiple lines.

In Cisco TSP 3.3, the TSP allows the simultaneous opening of all lines on the same CTI port device as long as the media parameters are matching for each lineOpen.

Media termination occurs two ways on CTI port devices:

Cisco Wave Drivers—The Cisco Wave Drivers set up the media parameters.

Media Termination Controlled by the Application—The application provides the media parameters.

Cisco TSP 3.3 allows applications to open all lines on the same CTI port device at the same time as long as all the lines are using the Cisco Wave Drivers or as long as all the lines are using custom media termination with the same media termination settings for each line.

Cisco TSP 3.2 Enhancements

The following Cisco TSP enhancements apply for Cisco TSP 3.2:

Support for multiple languages in the Cisco TSP installation program and in the Cisco TSP configuration dialogs

Support for ATA186 devices

Changes from Cisco TSP 3.1 to Cisco TSP 3.2

Cisco TSP enhancements for 3.1 include CTI Manager and support for fault tolerance and using Cisco CallManager Extension Mobility.

Cisco TSP 3.1 Enhancements

The following Cisco TSP enhancements apply for Cisco TSP 3.1:

CTI Manager and support for fault tolerance

Support for Cisco CallManager Extension Mobility

Support for Multiple Cisco TSP

Support for swap hold and setup transfer with the lineDevSpecific function

Support for lineForward

Support to Reset the Original Called Party upon Redirect with the lineDevSpecific function

Support for VG248 devices

Changes from Cisco TSP 3.0 to Cisco TSP 3.1

This section describes two important changes in Cisco TSP version 3.1: a change in the way Cisco TSP behaves when an application opens a line or phone and changes in the LINE_CALLINFO message.

Line In Service or Out of Service

In Cisco TSP 3.0, the default places a line in service when it is opened. With cluster abstraction (the CTI Manager) in Cisco TSP 3.1, after an application successfully opens a line or phone, the line or phone may be out of service. Immediately after opening the device, the application should check its status. If the device is out of service, the application should wait for an in-service message before initiating a TAPI request that results in Cisco CallManager interaction. If an application initiates such a request while the device is out of service, Cisco TSP responds with a resource unavailable message.

This change, from the behavior in Cisco TSP 3.0, does not present an issue for an application if the application checks the line or phone status immediately after the lineOpen or phoneOpen function call.

LINE_CALLINFO

A change added complete support for the fields of the LINE_CALLINFO message in Cisco TSP 3.1.

The LINE_CALLINFO parameter dwCalledID correctly reflects the OrigincalCalledParty information.

New or Changed Cisco TSP 3.1 Entities

Several Cisco TAPI device structures, functions, and messages that have been added or changed in this version enhance overall functionality. This table lists each new or modified entity and its type.

Entity
Type

LINE_ADDRESSSTATE

TAPI Line Message

LINE_REMOVE

TAPI Line Message

LINEADDRESSCAPS

TAPI Line Device Structure

LINEFORWARD

TAPI Line Device Structure

LINEFORWARDLIST

TAPI Line Device Structure

PHONE_REMOVE

TAPI Phone Message

lineForward

TAPI Line Function


Chapter
Description

Chapter 1 "Overview"

Outlines the key concepts for Cisco TAPI. Lists all functions that are available in the Cisco TAPI implementation for Cisco CallManager. Describes changes in and enhancements to Cisco TSP.

Chapter 2 "Cisco TAPI Implementation"

Describes the supported functions in the Cisco implementation of the standard Microsoft TAPI v2.1.

Chapter 3 "Cisco Device Specific Extensions"

Describes the functions that comprise the Cisco hardware-specific implementation classes.

Chapter 4 "Cisco TAPI Examples"

Provides examples that illustrate how to use the Cisco TAPI implementation.


Organization

Related Documentation

For more information about TAPI specifications, creating an application to use TAPI, or TAPI administration, see

Microsoft TAPI 2.1 Features:
http://www.microsoft.com/ntserver/techresources/commnet/tele/tapi21.asp

Getting Started with Windows Telephony
http://www.microsoft.com/NTServer/commserv/deployment/planguides
/getstartedtele.asp

Windows Telephony API (TAPI)
http://www.microsoft.com/NTServer/commserv/exec/overview
/tapiabout.asp

Creating Next Generation Telephony Applications:
http://www.microsoft.com/NTServer/commserv/techdetails/prodarch
/tapi21wp.asp

The Microsoft Telephony Application Programming Interface (TAPI) Programmer's Reference

"For the Telephony API, Press 1; For Unimodem, Press 2; or Stay on the Line" —A paper on TAPI by Hiroo Umeno a COMM and TAPI specialist at Microsoft.

"TAPI 2.1 Microsoft TAPI Client Management"

"TAPI 2.1 Administration Tool"

Required Software

Cisco TSP requires the following software:

Cisco CallManager Version 4.0(1) or later on the Cisco CallManager server

Microsoft Internet Explorer Version 4.01 or later

Supported Windows Platforms

All Windows operating systems support Cisco TAPI. Depending on the type and version of your operating system, you may need to install a service pack.

Windows 2003

Windows 2000

Windows 2000 includes TAPI 2.1.

Windows XP

Windows XP includes TAPI 2.1.

Windows Me

Windows Me includes TAPI 2.1.

Windows NT Server 4.0 or Windows NT Workstation 4.0

Service Pack 5 (SP5) includes TAPI 2.1.

SP5 is available via download from Microsoft.

Windows 98

Windows 98 includes TAPI 2.1.

Windows 95

Microsoft provides TAPI 2.1.


Note Check%SystemRoot%\system32 for these dynamically loaded library (.dll) files
and versions:
msvcrt.dll version: 6.00.8397.0
msvcp60.dll version: 6.00.8168.0
mfc42.dll version: 6.00.8447.0


Conventions

This document uses the following conventions:

Convention
Description

boldface font

Commands and keywords are in boldface.

italic font

Arguments for which you supply values are in italics.

[   ]

Elements in square brackets are optional.

{ x | y | z }

Alternative keywords are grouped in braces and separated by vertical bars.

[ x | y | z ]

Optional alternative keywords are grouped in brackets and separated by vertical bars.

string

An unquoted set of characters. Do not use quotation marks around the string or the string will include the quotation marks.

screen font

Terminal sessions and information that the system displays are in screen font.

boldface screen font

Information you must enter is in boldface screen font.

italic screen font

Arguments for which you supply values are in italic screen font.

This pointer highlights an important line of text in an example.

^

The symbol ^ represents the key labeled Control—for example, the key combination ^D in a screen display means hold down the Control key while you press the D key.

<   >

Nonprinting characters, such as passwords are in angle brackets.


Notes use the following convention:


Note Means reader take note. Notes contain helpful suggestions or references to material not covered in the publication.


Obtaining Documentation

Cisco documentation and additional literature are available on Cisco.com. Cisco also provides several ways to obtain technical assistance and other technical resources. These sections explain how to obtain technical information from Cisco Systems.

Cisco.com

You can access the most current Cisco documentation at this URL:

http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html

You can access the Cisco website at this URL:

http://www.cisco.com

You can access international Cisco websites at this URL:

http://www.cisco.com/public/countries_languages.shtml

Documentation DVD

Cisco documentation and additional literature are available in a Documentation DVD package, which may have shipped with your product. The Documentation DVD is updated regularly and may be more current than printed documentation. The Documentation DVD package is available as a single unit.

Registered Cisco.com users (Cisco direct customers) can order a Cisco Documentation DVD (product number DOC-DOCDVD=) from the Ordering tool or Cisco Marketplace.

Cisco Ordering tool:

http://www.cisco.com/en/US/partner/ordering/

Cisco Marketplace:

http://www.cisco.com/go/marketplace/

Ordering Documentation

You can find instructions for ordering documentation at this URL:

http://www.cisco.com/univercd/cc/td/doc/es_inpck/pdi.htm

You can order Cisco documentation in these ways:

Registered Cisco.com users (Cisco direct customers) can order Cisco product documentation from the Ordering tool:

http://www.cisco.com/en/US/partner/ordering/

Nonregistered Cisco.com users can order documentation through a local account representative by calling Cisco Systems Corporate Headquarters (California, USA) at 408 526-7208 or, elsewhere in North America, by calling 1 800 553-NETS (6387).

Documentation Feedback

You can send comments about technical documentation to bug-doc@cisco.com.

You can submit comments by using the response card (if present) behind the front cover of your document or by writing to the following address:

Cisco Systems
Attn: Customer Document Ordering
170 West Tasman Drive
San Jose, CA 95134-9883

We appreciate your comments.

Cisco Product Security Overview

Cisco provides a free online Security Vulnerability Policy portal at this URL:

http://www.cisco.com/en/US/products/products_security_vulnerability_policy.html

From this site, you can perform these tasks:

Report security vulnerabilities in Cisco products.

Obtain assistance with security incidents that involve Cisco products.

Register to receive security information from Cisco.

A current list of security advisories and notices for Cisco products is available at this URL:

http://www.cisco.com/go/psirt

If you prefer to see advisories and notices as they are updated in real time, you can access a Product Security Incident Response Team Really Simple Syndication (PSIRT RSS) feed from this URL:

http://www.cisco.com/en/US/products/products_psirt_rss_feed.html

Reporting Security Problems in Cisco Products

Cisco is committed to delivering secure products. We test our products internally before we release them, and we strive to correct all vulnerabilities quickly. If you think that you might have identified a vulnerability in a Cisco product, contact PSIRT:

Emergencies — security-alert@cisco.com

Nonemergencies — psirt@cisco.com


Tip We encourage you to use Pretty Good Privacy (PGP) or a compatible product to encrypt any sensitive information that you send to Cisco. PSIRT can work from encrypted information that is compatible with PGP versions 2.x through 8.x.

Never use a revoked or an expired encryption key. The correct public key to use in your correspondence with PSIRT is the one that has the most recent creation date in this public key server list:

http://pgp.mit.edu:11371/pks/lookup?search=psirt%40cisco.com&op=index&exact=on


In an emergency, you can also reach PSIRT by telephone:

1 877 228-7302

1 408 525-6532

Obtaining Technical Assistance

For all customers, partners, resellers, and distributors who hold valid Cisco service contracts, Cisco Technical Support provides 24-hour-a-day, award-winning technical assistance. The Cisco Technical Support Website on Cisco.com features extensive online support resources. In addition, Cisco Technical Assistance Center (TAC) engineers provide telephone support. If you do not hold a valid Cisco service contract, contact your reseller.

Cisco Technical Support Website

The Cisco Technical Support Website provides online documents and tools for troubleshooting and resolving technical issues with Cisco products and technologies. The website is available 24 hours a day, 365 days a year, at this URL:

http://www.cisco.com/techsupport

Access to all tools on the Cisco Technical Support Website requires a Cisco.com user ID and password. If you have a valid service contract but do not have a user ID or password, you can register at this URL:

http://tools.cisco.com/RPF/register/register.do


Note Use the Cisco Product Identification (CPI) tool to locate your product serial number before submitting a web or phone request for service. You can access the CPI tool from the Cisco Technical Support Website by clicking the Tools & Resources link under Documentation & Tools. Choose Cisco Product Identification Tool from the Alphabetical Index drop-down list, or click the Cisco Product Identification Tool link under Alerts & RMAs. The CPI tool offers three search options: by product ID or model name; by tree view; or for certain products, by copying and pasting show command output. Search results show an illustration of your product with the serial number label location highlighted. Locate the serial number label on your product and record the information before placing a service call.


Submitting a Service Request

Using the online TAC Service Request Tool is the fastest way to open S3 and S4 service requests. (S3 and S4 service requests are those in which your network is minimally impaired or for which you require product information.) After you describe your situation, the TAC Service Request Tool provides recommended solutions. If your issue is not resolved using the recommended resources, your service request is assigned to a Cisco TAC engineer. The TAC Service Request Tool is located at this URL:

http://www.cisco.com/techsupport/servicerequest

For S1 or S2 service requests or if you do not have Internet access, contact the Cisco TAC by telephone. (S1 or S2 service requests are those in which your production network is down or severely degraded.) Cisco TAC engineers are assigned immediately to S1 and S2 service requests to help keep your business operations running smoothly.

To open a service request by telephone, use one of the following numbers:

Asia-Pacific: +61 2 8446 7411 (Australia: 1 800 805 227)
EMEA: +32 2 704 55 55
USA: 1 800 553-2447

For a complete list of Cisco TAC contacts, go to this URL:

http://www.cisco.com/techsupport/contacts

Definitions of Service Request Severity

To ensure that all service requests are reported in a standard format, Cisco has established severity definitions.

Severity 1 (S1)—Your network is "down," or there is a critical impact to your business operations. You and Cisco will commit all necessary resources around the clock to resolve the situation.

Severity 2 (S2)—Operation of an existing network is severely degraded, or significant aspects of your business operation are negatively affected by inadequate performance of Cisco products. You and Cisco will commit full-time resources during normal business hours to resolve the situation.

Severity 3 (S3)—Operational performance of your network is impaired, but most business operations remain functional. You and Cisco will commit resources during normal business hours to restore service to satisfactory levels.

Severity 4 (S4)—You require information or assistance with Cisco product capabilities, installation, or configuration. There is little or no effect on your business operations.

Obtaining Additional Publications and Information

Information about Cisco products, technologies, and network solutions is available from various online and printed sources.

Cisco Marketplace provides a variety of Cisco books, reference guides, and logo merchandise. Visit Cisco Marketplace, the company store, at this URL:

http://www.cisco.com/go/marketplace/

Cisco Press publishes a wide range of general networking, training and certification titles. Both new and experienced users will benefit from these publications. For current Cisco Press titles and other information, go to Cisco Press at this URL:

http://www.ciscopress.com

Packet magazine is the Cisco Systems technical user magazine for maximizing Internet and networking investments. Each quarter, Packet delivers coverage of the latest industry trends, technology breakthroughs, and Cisco products and solutions, as well as network deployment and troubleshooting tips, configuration examples, customer case studies, certification and training information, and links to scores of in-depth online resources. You can access Packet magazine at this URL:

http://www.cisco.com/packet

Internet Protocol Journal is a quarterly journal published by Cisco Systems for engineering professionals involved in designing, developing, and operating public and private internets and intranets. You can access the Internet Protocol Journal at this URL:

http://www.cisco.com/ipj

World-class networking training is available from Cisco. You can view current offerings at this URL:

http://www.cisco.com/en/US/learning/index.html