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, page 2
•
Supported Platforms, page 12
•
Supported Standards, MIBs, and RFCs, page 13
•
Prerequisites, page 13
•
Provisioning, page 13
•
Reference Information, page 15
•
Glossary, page 18
Corporate Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
Copyright © 2007–2009 Cisco Systems, Inc. All rights reserved.
Overview
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.
Take Back and Transfer (Phase 2)
2
Overview
Figure 1 shows the call flow for DTMF Blind Transfer under INAP Control.
Figure 1
DTMF Blind Transfer under INAP Control
Take Back and Transfer (Phase 2)
3
Overview
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.
Take Back and Transfer (Phase 2)
4
Overview
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.
Take Back and Transfer (Phase 2)
5
Overview
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.
Take Back and Transfer (Phase 2)
6
Overview
Figure 2 shows the call flow for Network Blind Transfer Under INAP Control.
Figure 2
Network Blind Transfer under INAP Control
Take Back and Transfer (Phase 2)
7
Overview
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.
Take Back and Transfer (Phase 2)
8
Overview
Figure 3 shows the call flow for NCT.
Figure 3
Network Consultation Transfer
Take Back and Transfer (Phase 2)
9
Overview
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.
Take Back and Transfer (Phase 2)
10
Overview
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.
Take Back and Transfer (Phase 2)
11
Supported Platforms
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.
Take Back and Transfer (Phase 2)
12
Supported Standards, MIBs, and RFCs
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",
repeat="2", interval="3", locationstring="xyz.aud"
playDuration="60",
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"
Take Back and Transfer (Phase 2)
13
Provisioning
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"
Take Back and Transfer (Phase 2)
14
Reference Information
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
MidCallServiceCustID
X
X
GatewayAnnouncementPackageSupport
X
VSI
TrunkGroup
TCAPOverIP
TALI-IOCC
SS7-UK
SS7-Japan
SS7-ITU
SS7-China
SS7-ANSI
SIP
SGCP
SESSION
RLM
MGCP
ISDNPRI
IOCC
EISUP
Property Name
DPNSS
AVM
Parent Object
X
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.
Take Back and Transfer (Phase 2)
15
Reference Information
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.
Take Back and Transfer (Phase 2)
16
Reference Information
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
Take Back and Transfer (Phase 2)
17
Glossary
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
Take Back and Transfer (Phase 2)
18
Glossary
CCVP, the Cisco Logo, and the Cisco Square Bridge logo are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn
is a service mark of Cisco Systems, Inc.; and Access Registrar, Aironet, BPX, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, Cisco,
the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity,
Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step, Follow Me Browsing, FormShare, GigaDrive, GigaStack, HomeLink, Internet
Quotient, IOS, iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, LightStream, Linksys, MeetingPlace, MGX,
Networking Academy, Network Registrar, Packet, PIX, ProConnect, RateMUX, ScriptShare, SlideCast, SMARTnet, StackWise, The Fastest Way
to Increase Your Internet Quotient, and TransPath are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain
other countries.
All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply
a partnership relationship between Cisco and any other company. (0612R)
Copyright © 2007 Cisco Systems, Inc. All rights reserved.
Take Back and Transfer (Phase 2)
19
Glossary
Take Back and Transfer (Phase 2)
20