Guest

Cisco PGW 2200 Softswitch

Take Back and Transfer Phase 2

  • Viewing Options

  • PDF (165.9 KB)
  • Feedback
Take Back and Transfer (Phase 2)

Table Of Contents

Take Back and Transfer (Phase 2)

Overview

DTMF Blind Transfer Under INAP Control

Provisioning DTMF Blind Transfer under INAP Control

Network Blind Transfer Under INAP Control

Network Consultation Transfer Under INAP Control

Consultation Transfer Processing

Benefits

Restrictions and Limitations

Related Features and Technologies

Related Documents

Supported Platforms

Supported Standards, MIBs, and RFCs

Prerequisites

Provisioning

Provisioning Procedures

Provisioning Mid-call Dial-plan for DTMF Blind Transfer

Reference Information

Properties

Parameters

CustSpecificINAPHandling

maxSsnNum and avgInvokePerDialog

Alarms

Tones and Announcements

Glossary


Take Back and Transfer (Phase 2)



Note This document provides information for early field trials and technical reviews. A final version will be made available when the product releases.


Document Release History

Publication Date
Comments

September 27, 2009

Updated the maximum TCAP dialog number per subsystem number (SSN).

March 12, 2007

Initial version of the document.


Feature History

Release
Modification

9.7(3)

This feature will be introduced on the Cisco PGW 2200.


This document describes the introduction to the Cisco PGW 2200 software of the Take Back and Transfer (Phase 2) feature and includes the following sections:

Overview

Supported Platforms

Supported Standards, MIBs, and RFCs

Prerequisites

Provisioning

Reference Information

Glossary

Overview

The Take Back and Transfer (Phase 2) feature follows the introduction of the Phase 1 feature, Blind Take Back and Transfer replacement. Phase 1 of the Take Back and Transfer service (see the Blind Take Back and Transfer Replacement feature document) introduced the PGW's ability to request the interception of midcall DTMF digits from a called attendant and process them as a new routing destination address within the dial plan.

Take Back and Transfer (Phase 2) enables the PGW to perform a variety of call transfers upon request from a service control point (SCP). For example, this feature on the PGW enables Cisco Intelligent Contact Management (ICM) to support the capabilities defined by the Intelligent Network Application Protocol's (INAP) CS-1 (ITU Q.1218 Capability Set 1)/CS-2 (ITU Q.1228 Capability Set 2) to support different contact centers.

The Take Back and Transfer (Phase 2) feature supports three new operations:

DTMF Blind Transfer Under INAP Control

Network Blind Transfer Under INAP Control

Network Consultation Transfer Under INAP Control

DTMF Blind Transfer Under INAP Control

The DTMF Blind Transfer Under INAP Control operation pertains to non-ICM-controlled agents that are interconnected by a PRI or SS7 interface.

The caller (PSTN user) always uses either SS7 or PRI signaling. The destination to which the call is transferred can be operating any of the protocols currently supported by the PGW, including H.323 and SIP.

The DTMF Blind Transfer under INAP Control operation extends the capability of the preceding feature by offering the received DTMF digits to the ICM over a Transaction Capability Application Protocol (TCAP) dialogue, when the MidCall event detection point (EDP) is armed against the terminating leg.

After analyzing the received digits, the ICM instructs the PGW to disconnect the transferring attendant and establish a new outbound call to another attendant group. The attendant to which the call is transferred can be either ICM or non-ICM controlled. There is no signaling restriction on the new terminating call leg. Any protocol supported by the PGW can be used. However, the PGW supports additional call transfers caused by the reception of DTMF digits (or any other method) only if the new destination is TDM (not H.323 or SIP).

The DTMF Blind Transfer under INAP Control operation can be used in a multi-PGW environment in which the PGW nodes are interconnected by the EISUP protocol. In this case, the TCAP dialogue is invoked on the PGW that receives the incoming PSTN call.

If the terminating attendant resides on another PGW, the incoming ICM-controlled PGW sends messages to the terminating PGW that instruct it to monitor midcall DTMF digits and report them to the ICM-controlled PGW.

The terminating PGW collects DTMF digits if it is provisioned to do so and reports them, over EISUP, to the originating PGW when the collection criteria are matched and if the incoming PGW has requested DTMF event reporting. If the originating PGW receives a request to report the DTMF event, it reports to the ICM.

Figure 1 shows the call flow for DTMF Blind Transfer under INAP Control.

Figure 1 DTMF Blind Transfer under INAP Control

Provisioning DTMF Blind Transfer under INAP Control

To support the DTMF Blind Transfer under INAP Control operation, you must provision a midcall dial plan on the appropriate outgoing trunk group. If properly provisioned, the PGW requests the media gateway to detect and report the reception of DTMF digits.

The PGW accesses the midcall dial plan to determine the number-length and end-of-dialing criteria.

If there is an active TCAP dialogue and the MidCall is armed against the terminating leg, collected digits are reported to the ICM in an EventReportBCSM (ERB) operation. (oMidCall EDP is a detection point that detects DTMF digits.) If the incoming protocol is EISUP and the remote originating PGW requests DTMF reporting, the terminating PGW reports these digits over EISUP when the criteria are matched. After reporting the received DTMF digits to ICM, the originating PGW awaits further instructions from the ICM at this stage. The calling party remains in conversation with the agent. If the PGW receives additional digits, it ignores them.

Upon determining that the received DTMF digits represent a valid target, the ICM instructs the PGW to release the transferring agent by sending a DisconnectLeg. When the PGW completes the release of the outbound call leg, a result indication is sent back to the ICM. The ICM requests the PGW to connect to a new destination (the dialogue can be continued or closed at this stage). The address digits in the connect request are used as dial plan input to determine a new egress trunk group and to establish a call to the required destination.

The ICM can keep the dialogue open to receive further DTMF digits if the new attendant is not ICM controlled. The dialogue can also be kept open for cases in which the new attendant is ICM controlled to handle a consultation transfer initiated by the new attendant.

Co-existing TCAP-controlled and PGW-controlled Blind Transfer

It is possible to provision a dial plan that can be used both in PGW standalone mode (that is, without a TCAP dialogue) and under INAP control. However, we do not recommend enabling the PGW to execute a Blind Transfer autonomously while processing a TCAP dialogue. Such an occurrence could cause state mismatching between the ICM and PGW. Preferably, the PGW should execute a blind transfer by performing a route analysis of the dial plan when no TCAP dialogue is open.

To perform a blind transfer, the PGW behaves according to the following rules:

The presence of a midcall dial plan indicates DTMF collection.

The presence of route results within the midcall dial plan indicates the capability for Blind Transfer Phase 1 (PGW initiated rerouting) to occur.

The presence of an active TCAP dialogue disables any route result that might be returned from the midcall dial plan.

If the TCAP dialogue has the oMidCall EDP armed, the digits are reported to the ICM; otherwise, the digits are discarded (the PGW does not act on the digits when a TCAP dialogue is open).

PGW-Initiated Release and Error Handling

If, according to the provisioned dial plan or interdigit timeout, the PGW determines that received digits are insufficient or inappropriate for delivery to the ICM, the PGW can connect the attendant to an announcement or tone. (An applicable announcement or tone can be provisioned in the dial plan.) Additional digits received while the announcement or tone is playing are ignored. This is the same functionality provided by the Blind Take Back and Replacement (Phase 1) feature.


Note If the agent resides on a remote PGW, DTMF digits are collected and announcements are played by the remote PGW. These actions are not initiated by the PGW that is controlled by the ICM.


When no TCAP dialogue is active, if the routing number returned by the ICM in the connect request is not included after generic analysis, or if the call leg setup fails to complete due to a cause such as circuit congestion, called party busy, or called party not answering, the call is released or reattempted, depending on the results of the cause analysis.

When a TCAP dialogue is active, failure conditions are reported as events to the ICM if the event is armed. If the event is armed in "Interrupt" mode, the PGW waits for a response before continuing. A typical response might be a new connect request, a release call, or a request to play an announcement.

Similarly, if the new outbound call leg setup fails due to circuit congestion, user busy, or for some other reason, the PGW connects the controlling agent to the appropriate tone or announcement and reports the event to the ICM (for example, routeSelectFailure, oBusy , oNoAnswer). The PGW does not report RouteSelectFailure EDP to ICM until it exhausts all the resources.


Note The preceding description of PGW-initiated release and error handling is for only one possible method. The precise method used by an ICM to release calls and handle errors depends on the particular ICM system.


ICM-initiated Release and Error Handling

If the ICM determines that the DTMF digits received do not correspond to a valid destination, it sends a request to the PGW to play an announcement.

When the announcement completes, the gateway automatically reestablishes the conversation between the attendant and the calling party. If the agent is connected on a remote PGW, the Announcement ID to be played is passed via EISUP to the remote PGW.


Note The preceding description of ICM-initiated release and error handling is for only one possible method. The precise method used by an ICM to release calls and handle errors depends on the particular ICM system.


Network Blind Transfer Under INAP Control

The Network Blind Transfer Under INAP Control operation is available only to ICM-controlled agents.

To execute blind transfer under the control of ICM, an operator can input a new target number by using the Agent Desktop. After analyzing the number it receives from Agent Desktop, the ICM instructs the PGW to disconnect the transferring attendant and establish a new outbound call to another attendant group. The attendant to which the call is transferred can be either ICM controlled or non-ICM controlled. There is no signaling restriction on the new terminating call leg. Any protocol supported by the PGW can be used.

The caller (PSTN user) always uses either SS7 or PRI signaling. The destination to which the call is transferred can be operating any of the protocols currently supported by the PGW, including H.323 and SIP.

The Network Blind Transfer under INAP Control operation can be used in a multi-PGW environment in which the PGW nodes are interconnected by the EISUP protocol. Unlike the DTMF Blind Transfer operation, for Network Blind Transfer under INAP Control, there is no in-band DTMF signal involved, and no special provisioning (such as mid-call dial-plan) is required.

Figure 2 shows the call flow for Network Blind Transfer Under INAP Control.

Figure 2 Network Blind Transfer under INAP Control

Network Consultation Transfer Under INAP Control

The Network Consultation Transfer (NCT) Under INAP Control operation is available only to ICM-controlled agents.

Operator requests to hold, to initiate a new call attempt, to alternate between connections, and to execute a call transfer are received by the ICM through Computer Telephony Integration (CTI) and translated into INAP CS2 operations sent to the PGW. ICM performs the translation.

Because MGCP gateways are not capable of conferencing, the conference operation is not supported.


Note For the Take Back and Transfer (Phase 2) feature, only TDM attendants can conduct a consultation transfer.


The NCT can span multiple PGWs. Typically, the TCAP dialogue that is active in the PGW, and is associated with the incoming PSTN call leg, manipulates call legs attached to remote PGWs by means of EISUP signaling links that interconnect the PGWs.

Figure 3 shows the call flow for NCT.

Figure 3 Network Consultation Transfer

Consultation Transfer Processing

A call that receives consultation transfer processing is sent from the PSTN to a PGW that is managed by an ICM-controlled agent running INAP. When the ICM-controlled agent contacts another agent to initiate a dialogue prior to a call transfer, the ICM starts a SplitLeg operation. If a SplitLeg is requested for a call leg that is not controlled by MGCP (perhaps by SIP, H.323, or EISUP), a TCAP Reject message bearing the error, Task Refused, is returned to the ICM.

The ICM must determine whether to provide an indication of failure to the requesting attendant. A SplitLeg operation can be executed only on a call that has not already been transferred by consultation transfer. If a call has already been transferred, a request for SplitLeg is rejected. However, a blind transfer can be executed after a consultation transfer.

When the PGW verifies that the call state and signaling requirements are satisfied, it returns a successful result to the ICM. The ICM then requests the PGW to connect the attendant call leg with a new destination identified by the address digits in the connect request. The ICM also requests the PGW to connect the calling party to a hold tone or announcement using the CTR/Play Announcement operation.

The PGW requests the media gateway(s) that control the two MGCP endpoints to idle the RTP stream that passes between them. A new call instance is created. The connect address digits and calling-party information, including Session Description Protocol (SDP), are passed to the newly created instance. This action enables the PGW to process the connect address through route analysis. If routing analysis is successful, a new outbound call setup is made from the new call instance. A progress acknowledgment indication is returned to the "master" call instance. SDP information is returned during a later stage in the call, usually when the termination is alerting.


Note For a SIP or H.323 destination, the progress acknowledgment could arrive later in the call and the requesting attendant hears progress tones (ringback) from the local application on the MGCP endpoint.


The calling party is connected to the hold tone or announcement specified in the CTR/Play Announcement operation (if present). The controlling call instance connects the attendant's MGCP endpoint to the newly-received SDP from the new call instance as a "bothway" connection, which normally occurs in the call establishment phase. Similarly, the absence of SDP data combined with a user alert signaling indication results in local ringback tone application being requested, which occurs for H.323 and SIP terminations.

When the call is answered, the signal passes from a new call instance to the master call instance, at which point the speech path is cut through in the normal manner (if required). Events are reported to the ICM as requested in the RR-BCSM message sent to the PGW.

The controlling attendant is now in conversation with the new destination agent and the calling party is on hold (with or without audio indication as requested by the ICM). A number of continuations are possible, the most common being:

The controlling attendant shuttles between the two parties. For this continuation, the ICM issues a MoveLeg request to switch the controlling party connection to the held call leg and a CTR/Play announcement request to provide a hold tone or announcement to the previously connected party.

The controlling attendant transfers the call and drops out of the connection. For this continuation, the ICM issues a Disconnect Leg request to the PGW. The media stream between the controlling attendant and the currently connected party becomes inactive and the controlling attendant is released. The PGW then reports the successful result of this operation to the ICM which, by issuing a Merge Call segments request, establishes a conversation between the two remaining parties.

Codec Negotiation

Codec selection across the three call legs is established by the current, simplified, "best fit" practice of using the codec list provided from the A party, which is offered to the C party for the B to C call leg setup. When the call is transferred, this same codec is used for the A to C setup.

PGW-Initiated Release and Error Handling

A SplitLeg request is denied if it is requested for a SIP or H.323 endpoint. A SplitLeg request is also denied if the incoming call type is SIP, H.323, or EISUP, or if the call state spans two call instances due to a previous consultation transfer. In any of these cases, a TC-Reject (Task refused) is returned.

If the connect address does not result in valid routing, the agent call leg is connected to an informational tone, such as congestion or reorder, and an ER-BCSM event is sent to the ICM. The announcement is timed in the gateway.


Note If a Cisco VXSM is involved, tone timing is performed by the PGW because there is no MGCP-announcement package support.


The ICM pauses for a short period (typically, 2 seconds) before issuing a Merge Call Legs request to reestablish a conversation between the attendant and the calling party.

Similarly, if the new outbound call leg setup fails due to circuit congestion, user busy, or for some other reason, the PGW connects the controlling agent to the appropriate tone/announcement and reports the event to the ICM (for example, routeSelectFailure, tBusy, tNoanswer).

After a 2-second pause, the ICM issues a Merge Call segments request to the PGW to reestablish a conversation between the agent and the calling party. If the new call leg setup goes to another PGW, the behavior of the call setup in the remote PGW is identical to the call setup of any incoming inter-PGW call; that is, call rerouting or redirection might occur. If the call setup fails, the remote PGW releases the call with an appropriate cause code, which is received by the slave call instance and passed to the master call instance. The master call instance applies a local tone/announcement and an event report (for example, route congestion) is passed to the ICM.

After successful execution of consultation transfer, if the destination user attempts to transfer the call (using Refer), the attempt is rejected by the Slave call instance.


Note The preceding description of PGW-initiated release and error handling is for only one possible method. The precise method used by an ICM to release calls and handle errors depends on the particular ICM system.


Attendant (Controlling Party) Initiated Call Release

If the controlling party releases the call after the second call leg of the consultation transfer is established, the Disconnect EDP is reported to the ICM. The subsequent behavior of ICM and PGW depends on the ICM's script. ICM might send a MergeCallSegments request to connect the calling party with the newly established call leg, which completes the call transfer.


Note The preceding description of attendant-initiated release and error handling is for only one possible method. The precise method used by an ICM to release calls and handle errors depends on the particular ICM system.


Benefits

The Take Back and Transfer (Phase 2) feature augments the INAP CS-1 capability of the PGW by providing a limited subset of the ITU-T Q.1228-INAP CS-2 specification. This subset of the INAP CS-2 functionality supports call transfer services by interacting with the ICM. The Take Back and Transfer (Phase 2) feature also expands the Phase 1 feature (Blind Take Back and Transfer Replacement), which included only midcall event reporting of DTMF digits to the ICM.

The Take Back and Transfer (Phase 2) feature supports the blind transfer and consultant transfer of calls under ICM's control.

Restrictions and Limitations

The Take Back and Transfer (Phase 2) feature has the following limitations:

1. TCAP dialogues are not failed over. Calls in the connected state are failed over and remain in conversation, but the TCAP dialogue is lost. Calls are released from this state in the normal manner upon user request.

2. Only two-party connected calls are preserved if a call failover occurs. In the absence of a TCAP controlling dialogue after failover (see the first restriction), the PGW cannot receive further instructions in order to progress the call.

3. Only MGCP-controlled endpoints can initiate consultation transfer. This removes any protocol interworking limitations that can arise with interworking VoIP protocols.

4. A call that was subjected to consultation transfer cannot be serially resubjected to TCAP-controlled consultation transfer. If the original agent releases from the call, a subsequent consultation phase might be required if the new destination agent also requests a consultation transfer call. If this should occur, the PGW rejects the request. However, in this case, the agent can initiate a blind transfer call.

5. There is no conferencing capability. Conferencing can be supported when a gateway that supports conference capability over MGCP becomes available.

6. Only an MGCP-controlled endpoint can be the calling party in consultation transfer.

Related Features and Technologies

The Take Back and Transfer (Phase 2) feature is related to the Phase 1 feature, Blind Take Back and Transfer Replacement.

Related Documents

To access the Cisco Media Gateway Controller Software guides, start at the following URL:

http://www.cisco.com/en/US/products/hw/vcallcon/ps2027/tsd_products_support_series_home.html

Supported Platforms

The hardware platforms supported for the Cisco MGC software are described in the Cisco Media Gateway Controller Hardware Installation Guide.

Supported Standards, MIBs, and RFCs

This section identifies the new or modified standards, MIBs, or RFCs that are supported by this feature.

Standards

ITU-T Q1228 09/1997—INAP CS-2

MIBs

No new or modified MIBs are supported by this feature.

For more information on the MIBs used by the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Management Information Base Guide.

RFCs

No new or modified RFCs are supported by this feature.

Prerequisites

The Take Back and Transfer (Phase 2) feature requires the presence of its predecessor feature, Blind Take Back and Transfer Replacement.

Also, when you apply the patch for this feature, the file trigger.dat does not migrate automatically. You must copy the trigger.dat file from /opt/CiscoMGC/etc/CONFIG_LIB/new/trigger.dat to the directory /opt/CiscoMGC/etc/active_link/.

Provisioning

There are no additional provisioning requirements associated with this feature. However, the CS2 capability is enabled by a single system property, MidCallServiceCustID. (See the "Properties" section for more information about properties associated with the Take Back and Transfer (Phase 2) feature.)

The following sections describe provisioning tasks related to this feature.

Provisioning Procedures

If you want to provision the ToneAndAnnouncement database table to add announcements associated with the Take Back and Transfer (Phase 2) feature, use the following MML command options as a guide. For more information on the ToneAndAnnouncement database table, see the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.

To add an announcement, enter the MML command:

mml> Numan-add:announcement:annid=123, gwtype="AS5400",  playDuration="60", 
repeat="2", interval="3", locationstring="xyz.aud"

To edit an announcement, enter the MML command:

mml> Numan-ed:announcement:annid=123, gwtype="AS5400",  locationstring="welcome.aud"

To delete an announcement, enter the MML command:

mml> Numan-dlt:announcement:annid=123, gwtype="AS5400"

To retrieve an announcement, enter the MML command:

mml> Numan-rtrv:announcement:annid=123, gwtype="AS5400"

To reference an announcement from the dial plan, you can use the following MML commands.

To add a remote announcement result:

mml> announceId=123, remote, RoutelistId=dulles: Numan-add :resulttable:custgrpId 
="T002", name="result59",resulttype="ANNOUNCEMENT", dw1="123", dw2="1",dw3="dulles", 
setname="set1"

To add a local announcement result:

mml> announceId=123, local, Final_on for playing announcement: 
Numan-add:resulttable:custgrpId="T002", name="result60", resulttype="ANNOUNCEMENT", 
dw1="123", dw2="0",dw4="1", setname="set1"

To associate a b-digit number to the result set:

mml> Numan-add: bdigtree:custgrpid="T002",digitstring="7034843375", 
callside="originating",setname="set1"


Note When the ICM requests an announcement, the same announcement ID values that are populated in the PGW announcement table and dial plan are applicable. You must ensure that the values are provisioned consistently across platforms.


Provisioning Mid-call Dial-plan for DTMF Blind Transfer

This section presents examples of the commands required for provisioning a mid-call dial-plan for DTMF Blind Transfer (intelligent Blind Transfer).

In the following command examples, the result-type BMODDIG is optional. It should be included if you want to do some digit modification.

numan-add:resultset:custgrpid="tr01",name="rset-tnt1"

numan-add:resulttable:custgrpid="tr01",name="tnt1-bmod",resulttype="BMODDIG",dw1="1",dw2="
2",setname="rset-tnt1"

In the following command examples, the result-type INC_NUMBERING is mandatory. The dw2 should be equal to dw3 (fixed length), and the length value should be the length of the number after digit modification if the result-type BMODDIG is present. For example, if a user dials the correct target number *811111 and the operator wants to remove *8, the value of dw2 and dw3 should be 5 instead of 7.

numan-add:resulttable:custgrpid="tr01",name="tnt1-len",resulttype="INC_NUMBERING",dw1="0",
dw2="12",dw3="12",setname="rset-tnt1"

In the following command examples, the result-type ROUTE is mandatory. However, it establishes a dummy ROUTE, which is used only to indicate that GA analysis is successful for intelligent Blind Transfer (iTNT).

numan-add:resulttable:custgrpid="tr01",name="tnt1-rte",resulttype="ROUTE",dw1="v40z4icmrte
lst",setname="rset-tnt1"
numan-add:bdigtree:custgrpid="tr01",callside="originating",digitstring="B8111",setname="rs
et-tnt1" 

Reference Information

This section contains reference material related to this feature.

Properties

The properties identified in this section are used for the Take Back and Transfer (Phase 2) feature. For information on other properties of the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.

Table 1 identifies the parent objects for the properties used for the Take Back and Transfer (Phase 2) feature.

Table 1 Software Properties Related to this Feature

Property Name
Parent Object
AVM
DPNSS
EISUP
IOCC
ISDNPRI
MGCP
RLM
SESSION
SGCP
SIP
SS7-ANSI
SS7-China
SS7-ITU
SS7-Japan
SS7-UK
TALI-IOCC
TCAPOverIP
TrunkGroup
VSI

MidCallServiceCustID

 

X

   

X

         

X

 

X

           

GatewayAnnouncementPackageSupport

 

 

 

 

 

X

 

 

 

 

 

 

 

 

 

 

 

 

 


The properties used for the this feature are described in Table 2.

Table 2 Properties Used for the Take Back and Transfer (Phase 2) Feature 

Property
Definition

MidCallServiceCustID

A customer ID associated with mid-call service.

GatewayAnnouncementPackageSupport

Indicates that the gateway supports the MGCP Announcement package.


Parameters

The parameters identified in this section must be set to enable the Take Back and Transfer (Phase 2) feature. For information on other parameters for the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide.

CustSpecificINAPHandling

You must add the parameter CustSpecificINAPHandling to the XECfgParm.dat file to determine INAP behavior, including the advertised application context.

Currently, four string values can be used for the CustSpecificINAPHandling parameter:

tinap

finap

rinap

sinap

The parameter CustSpecificINAPHandling must be set to sinap to enable the network transfer and DTMF transfer services. The following new CS2 application context is populated in the dialogue body of the INAP message:

itu-t(0) recommendation(0) q(17) q1228(1228) cs2(2) ac(3) id-ac-cs2-ssf-scfGenericAC(4) urn:oid:0.0.17.1228.2.3.4

maxSsnNum and avgInvokePerDialog

To support the Take Back and Transfer (Phase 2) feature, the PGW 9.7(3) adds the TCAP IOCC subsystem parameters maxSsnNum and avgInvokePerDialog:

The parameter maxSsnNum (default = 10) enables you to set the maximum number of SSNs for the entire TCAP IOCC subsystem.

The parameter avgInvokePerDialog (default = 1) sets the average number of Invokes for a TCAP dialog. A single dialog does not necessarily correspond to a single Invoke. The number of Invokes depends on the call flow for the TCAP dialog.

The PGW IOCC allocates resources and tracks the TCAP dialogs until the dialog ends. The PGW can support 200000 dialogs and (200000/maxSsnNum) dialogs per SSN. The PGW can support (200000*avgInvokePerDialog) Invokes and (200000*avgInvokePerDialog/maxSsnNum) Invokes per SSN.

If the PGW detects repeated NCT/NBT, NoAnswer, RouteSelectFailure, or CalledPartyBusy messages, which then result in a follow-on call, there will be many Invokes for the same TCAP dialog. Therefore, to support higher feature capability, the maximum number of Invokes can be much larger than the maximum number of TCAP dialogs.

If you provision the maxSsnNum and avgInvokePerDialog parameters, the maximum number of simultaneous outgoing Invokes per SSN is calculated as (200000* avgInvokePerDialog)/maxSsnNum.

Alarms

To support this feature, a new alarm indicates when an inconsistency occurs between received midcall DTMF digits and provisioned midcall dial plan data. The new alarm applies to the Take Back and Transfer (Phase 2) feature when the PGW receives an instruction from ICM to monitor DTMF digits for a VoIP trunk. In such cases, a TCAP dialogue is always present.

The new alarm reports when the PGW receives a request to perform midcall (DTMF) event reporting against an H.323 or SIP user.


Note This type of event reporting is not supported on VoIP interfaces.


Alarm—Lightspeed call model (LCM): Take Back and Transfer, Invalid target for DTMF collection

Description—The request to collect midcall DTMF events cannot be performed because the target user has an incompatible protocol such as H.323 or SIP.

Severity—Information.

Cause—This alarm is reported by LCM when the ICM erroneously requests midcall event reporting against an H.323 or SIP user.

Type—2.

Action—Verify that the data provisioned in the PGW and ICM is consistent with the configured agent interfaces.

Tones and Announcements

Tones and announcements are applied at the gateway through the use of the MGCP announcement package. For gateways that do not support the MGCP announcement package (for example, VXSM), a tone is requested instead. To support the Take Back and Transfer (Phase 2) feature, anew MGCP sigpath property, GatewayAnnouncementPackageSupport, is introduced to indicate to the PGW whether or not the gateway supports the required announcement package.

The specific tones are:

it = Intercept Tone as Hold tone (Tone Id: 2)

cg = Network Congestion Tone (Tone Id: 3)

To enable the MGCP announcement package, set the MGCP sigpath property GatewayAnnouncementPackageSupport to 1.

prov-add:sigsvcprop:NAME="mgcp-5400-301",GatewayAnnouncementPackageSupport="1"

To disable the MGCP announcement package, set the MGCP sigpath property GatewayAnnouncementPackageSupport to 0.

If the media gateway supports announcements, provision the audio file for the specific
announcement ID as follows:

Numan-add:announcement:annid=2, gwtype="AS5400",  locationstring="hold.aud"

If the media gateway does not support an announcements received from ICM, the PGW requests the media gateway to play the specific tone instead:

Q931_INTERCEPT_TONE = 2

Q931_NET_CONJ_TONE = 3

Glossary

Table 3 contains definitions of acronyms and technical terms used in this feature module.

Table 3 Acronyms and Definitions

Acronym
Definition

BCSM

Basic Call State Model

CS 2

ITU Q.1228 Capability Set 2

CTI

Computer telephony Integration

CTR

ConnectToResource operation

DTMF

dual-tone multifrequency

EDP

event detection point

EISUP

Extended-ISUP

ICM

Intelligent Contact Management

INAP

Intelligent Network Application Protocol

IOCC

input/output channel controller

iTNT

intelligent blind transfer (DTMF blind transfer under INAP control)

ITU-T

International Telecommunication Union Telecommunication Standardization Sector. International body that develops worldwide standards for telecommunications technologies.

LCM

Lightspeed Call Model

MGC

(Cisco) Media Gateway Controller

MML

Man-Machine Language

NBT

network blind transfer

NCT

network consultation transfer

PA

PlayAnnouncement operation

PGW

PSTN Gateway

PRI

Primary Rate Interface

PSTN

public switched telephone network

SCP

service control point

SDP

Session Definition Protocol

SIP

Session Initiation Protocol

SSN

Subsystem Number

TCAP

Transaction Capability Application Protocol