Table Of Contents
SIP Service Handling and Feature Interworking Enhancements
Feature Overview
Benefits
Restrictions
Related Documents
Supported Standards, MIBs, and RFCs
Prerequisites for Using This Feature
XECfgParm.dat Configuration Tasks
Verifying the XECfgParm.dat Changes
Configuration Examples
Dial Plan Examples
Provisioning the FACILITY Result Within the B-Digit Tree
Backward Transition of Redirection Handling
Software Changes for this Feature
XECfgParm.dat Parameter
Billing Interface
Originating Remote SIP Host (Tag: 4201)
Originating Local SIP Host (Tag: 4202)
Terminating Remote SIP Host (Tag: 4242)
Terminating Local SIP Host (Tag: 4243)
Properties
Result Type Definitions
FACILITY
Call Processing Actions According to FACILITY Configuration
Cause Codes
Obtaining Documentation, Obtaining Support, and Security Guidelines
Glossary
SIP Service Handling and Feature Interworking Enhancements
Document Release History
Publication Date
|
Comments
|
March 20, 2008
|
Changed the default mode for the sipModeSelectionControl parameter.
|
March 12, 2007
|
Initial version of the document.
|
Feature History
Release
|
Modification
|
9.7(3)
|
The SIP Service Handling and Feature Interworking Enhancements feature was introduced on the Cisco MGC software.
|
This document describes the SIP Service Handling and Feature Interworking Enhancements feature.
This feature is described in the following sections:
•
Feature Overview
•Supported Standards, MIBs, and RFCs
•Prerequisites for Using This Feature
•XECfgParm.dat Configuration Tasks
•Configuration Examples
•Dial Plan Examples
•Software Changes for this Feature
•Obtaining Documentation, Obtaining Support, and Security Guidelines
•Glossary
Feature Overview
This feature introduces into the Cisco MGC, a Back to Back User Agent (B2BUA) mode of operation for SIP-to-SIP calls using the PGW 2200. It also enhances the existing mid-call service handling to better interwork SIP signaling for mid-call services. This feature allows PGW handling of SIP-to-SIP calls, including intrusive replacement of E.164 addresses appearing in various headers and configurable handling of REFER and 3xx redirect messaging. In addition, this feature enhances the PGW 2200 mid-call service handling for interworking of SIP redirection and transfers with SIP to SIP and SIP to other protocols.
The feature provides the following enhancements as well as consolidating the PGW 2200 call-processing infrastructure:
•Configurable selection of SIP-to-SIP call processing mode (B2BUA or Proxy).
•Introduction of B2BUA mode for SIP-to-SIP calls. This mode of operation allows you to align SIP call processing with the existing PGW call model.
•For SIP-to-SIP calls: intrusive modification of E.164 is addressed within various SIP headers.
•On calls involving SIP where rerouting is invoked, rerouting is supported to or from other protocols. Thus redirection scenarios function properly for calls that start as SIP to SIP and are redirected to SIP to H.323 or calls that start as SIP to H.323 calls and are redirected to SIP-to-SIP calls.
•SIP calls correctly use cause analysis.
•Improved CDR records for SIP-to-SIP calls.
•SIP-to-SIP calls can now be controlled by use of Intelligent Network Application Part (INAP).
•Control of redirection behavior is a dialplan configured option so that a service provider can configure the PGW 2200 to pass on or act locally on redirection requests. In addition, redirection is inter-worked correctly with QSIG and DPNSS diversion services.
•REFER inter-operates with QSIG Single Step Call Transfer (SSCT).
For calls involving DPNSS or QSIG, the following support is introduced for Redirection handling:
•Backward notification of redirection when calls are handled locally.
•Generation of redirection information at the originating side.
•Backward indication of call forwarding when a call is executed locally on the terminating side.
Benefits
This feature provides the following benefits:
•Adds flexibility to B2BUA support with enhanced mid-call service handling on the PGW 2200. A service provider can configure the PGW 2200 to pass or act on redirection requests based on dial plan provisioning.
•Allows redirection scenarios to function properly for calls that start as SIP to SIP and are redirected to SIP to H.323 or calls that start as SIP to H.323 calls and are redirected to SIP-to-SIP calls.
•Allows SIP and INAP to interwork for terminating leg manipulations.
•Allows the PGW 2200 to redirect SIP-to-ISUP calls to SIP-to-SIP calls for announcements and to normalize the A-number on SIP-to-SIP calls.
Restrictions
The B2BUA implementation on the PGW 2200 is a partial B2BUA solution when the sides are treated independently to a degree but certain information is kept relevant to both sides, that is, supporting SIP-SIP transparency via the call model. This is opposed to a full B2BUA solution when both call sides are treated completely independently with regard to CallID, routing information, and so on.
The PGW 2200 cannot support that SIP invokes hold/resume to TDM after a switchover or resumes the held call after a switchover; the PGW 2200 cannot support that SS7 invokes hold/resume to SIP after a switchover or resumes the held SIP call after a switchover.
Related Documents
This document contains information that is related strictly to this feature. The documents that contain additional information related to the Cisco Media Gateway Controller (MGC) are at the following url:
http://www.cisco.com/en/US/products/hw/vcallcon/ps2027/tsd_products_support_series_home.html
Supported Standards, MIBs, and RFCs
Standards
No new or modified standards are supported by this feature.
MIBs
No new or modified MIBs are supported by this feature.
For more information on the MIBs used in the Cisco MGC software, see the Cisco Media Gateway Controller Software Release 9.5(2) MIBs
RFCs
This feature supports the following RFCs:
•RFC 3261, SIP: Session Initiation Protocol (partial compliance)
•RFC 3265, SIP NOTIFY Method
•RFC 3311, SIP UPDATE Method
•RFC 3515, SIP REFER Method
•RFC 4028, Session Timers in the Session Initiation Protocol (SIP)
Prerequisites for Using This Feature
The Cisco PGW 2200 must be running Cisco MGC software Release 9.7(3). Prerequisites for this release can be found in the Release Notes for the Cisco Media Gateway Controller Software Release.
XECfgParm.dat Configuration Tasks
This section contains the steps necessary for configuration of the Cisco MGC software to support this feature. If you are installing and configuring the Cisco MGC software on your system for the first time, use the procedures in the Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide. Return to this section once you encounter the *.sipModeSelectionControl parameter in the XECfgParm.dat file.
Caution Configuration of the Cisco MGC software requires that the system software be shut down. In a simplex system, calls cannot be processed during system shutdown. In a continuous service system, your system loses the ability to maintain calls during a critical event if the system software on one of the PGW hosts is shut down.
To configure the sipModeSelectionControl value, perform the following steps:
Step 1 If you have not already done so, open the /opt/CiscoMGC/etc/XECfgParm.dat file on the active and standby Cisco PGW hosts using a text editor, such as vi.
Step 2 If you have not already done so, ensure that the pom.dataSync parameter is set to false on the active and standby Cisco PGW hosts.
Step 3 Search for the *.sipModeSelectionControl parameter and enter the desired value
(1—B2BUA/optional mode or 2—Fixed Proxy Mode) on the active and standby Cisco PGW hosts.
Step 4 Save your changes and close the text editor.
Verifying the XECfgParm.dat Changes
To verify the XECfgParm.dat settings for this feature, perform the following steps:
Caution Do not modify the other XECfgParm.dat parameters associated with this feature.
Step 1 Log in to the standby Cisco MGC as root and change directories to the etc subdirectory by entering the following UNIX command:
Step 2 Open XECfgParm.dat using a text editor, such as vi.
Step 3 Search for the *.sipModeSelectionControl parameter and verify that the displayed value (1—B2BUA/optional mode or 2—Fixed Proxy Mode) is correct.
If the value is correct, proceed to Step 4. Otherwise, correct the value and then proceed to Step 4.
Step 4 Save your changes and close the text editor.
Step 5 Manually stop the Cisco MGC software on the standby Cisco MGC by entering the following UNIX command:
/etc/init.d/CiscoMGC stop
Step 6 Once the software shutdown is complete, manually start the Cisco MGC software on the standby Cisco MGC by entering the following command:
/etc/init.d/CiscoMGC start
Step 7 Log in to the active Cisco MGC, start an MML session, and enter the following command:
Site alarms are automatically set until the out-of-service (OOS) Cisco MGC host is returned to an in-service (IS) state.
Step 8 Repeat steps 2 through 7 for the newly standby Cisco MGC host. Once you have verified the settings on both hosts, the procedure is complete.
Configuration Examples
This section provides a configuration example for the XECfgParm.dat parameter associated with this feature. Additional configuration examples for the Cisco MGC software can be found in the Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide.
Note Configuration of XECfgParm.dat parameters for this feature is required only when the Cisco PGW 2200 hosts are not in the same subnet.
*.sipModeSelectionControl = 1 # 1 - B2BUA mode, allow later selection of proxy mode
via the dialplan, 2 - Fixed Proxy mode, always work in proxy mode.
Dial Plan Examples
This section provides an example of dial plan provisioning for this feature. Additional examples of dial plan provisioning for the Cisco MGC software can be found in the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.
Provisioning the FACILITY Result Within the B-Digit Tree
The commands numan-add, numan-ed, and numan-dlt are used to provision dial plan result types and their associated data words. The following example illustrates the provisioning of the FACILITY result within the B-Digit tree:
Create the result within a result-set, in the dial plan result table:
mml>numan-add:resulttable:custgrpid="1111", name="fac01", resulttype="FACILITY", dw1="2",
dw2="2",setname="rset1"
Now assign the result-set at the required point in the B-Digit tree:
numan-add:bdigtree:custgrpid="1111",digitstring="612456",callside="originating",setname="r
set1"
Proxy mode is required for SIP-to-SIP calls and data word 2 is not allowed here.
mml>numan-add:resulttable:custgrpid="1111", name="fac01", resulttype="FACILITY",
dw1="1",setname="rset1"
With this combination of dataword1 and dataword 2, the backward transit of the Redirection is not supported so the existing redirection mechanism (that is, into Cause analysis) applies.
mml>numan-add:resulttable:custgrpid="1111", name="fac01", resulttype="FACILITY", dw1="2",
dw2="1",setname="rset1"
With this combination of dataword1 and dataword2, the backward transit of the redirection is always supported.
mml>numan-add:resulttable:custgrpid="1111", name="fac01", resulttype="FACILITY", dw1="2",
dw2="2",setname="rset1"
With this combination of dataword1 and dataword2, the backward transit of the Refer is conditionally supported if the received Refer-To header domain in the REFER message (term side) matches the domain in the From header received within the original INVITE on the OCC side.
mml>numan-add:resulttable:custgrpid="1111", name="fac01", resulttype="FACILITY", dw1="3",
Backward Transition of Redirection Handling
numan-add:resultset:custgrpid="1111",name="facrset"
numan-add:resulttable:custgrpid="1111",
name="fac01",resulttype="FACILITY",dw1="2",dw2="2",setname="facrset"
Software Changes for this Feature
The following section describes software changes related to this feature:
•XECfgParm.dat Parameter
•Billing Interface
•Properties
•Result Type Definitions
•Cause Codes
XECfgParm.dat Parameter
The XECfgParm.dat file configuration parameter added for this feature is described in Table 1. For information on the other XECfgParm.dat parameters, see the Cisco Media Gateway Controller Software Release 9 Installation and Configuration Guide.
Table 1 XECfgParm.dat Parameter
Configuration Parameter
|
Definition
|
sipModeSelectionControl
|
The XECfgParm parameter sipModeSelectionControl is the highest level means of governing SIP actions. This parameter lets you provision one system-level parameter and maintain your proxy mode functionality for SIP-to-SIP calls. If you are using proxy mode for SIP calls, you do not have to provision a dialplan result for all numbers handled simply to maintain your call processing capability.
At this level there is a choice of operating mode, either the B2BUA/optional mode using the new dial plan result FACILITY as described in the "FACILITY" section or the default Fixed Proxy Mode working. The parameter has two settings:
1 B2BUA/optional mode—With the parameter set to 1, default processing on SIP-to-SIP calls is B2BUA mode and you can select the proxy mode of operation later with the dial plan (A/B analysis).
2 Fixed Proxy Mode—With the parameter set to 2, handling of SIP-to-SIP calls is supported in proxy mode only. Any later selection of B2BUA mode with the dial plan becomes meaningless once you select this value. There is no means to select B2BUA mode in the FACILITY result, only Proxy mode. This means that if you set XECfgParm for proxy mode there is no point in defining FACILITY results for Proxy mode because all SIP-to-SIP calls will already be in proxy mode. This is the default setting for this parameter.
If there is no dialplan result FACILITY or if number analysis is not used, then the variable remains set at value 0 and default Fixed Proxy behavior results.
|
Billing Interface
This section identifies the call detail record (CDR) data added for this feature. For billing interface information for the rest of the Cisco MGC software, see the Cisco Media Gateway Controller Software Release 9 Billing Interface Guide.
Table 2 Originating Remote SIP Host (Tag: 4201)
Name: Originating Remote SIP Host
|
Tag: 4201
|
Source: MDL/Engine
|
Description/Purpose: Contains the remote host for the originating side of a SIP-originated call (this tag is present only if SIP appears on the originating side of the call). In a simple call, this host is taken out of the From header, but if a P-Asserted or Remote Party ID header is received and has influenced the calling line information, then the host is taken from the header that provides the resultant calling line information.
|
Format: IA5
|
Length in Octets: 1 to 256
|
Data Value: URL
|
Extended Data Value: No extended value.
|
General Information:
|
MGC Release: Release 9 and later.
|
|
Originating Local SIP Host (Tag: 4202)
Table 3 Originating Local SIP Host (Tag: 4202)
Name: Originating Local SIP Host
|
Tag: 4202
|
Source: MDL/Engine
|
Description/Purpose: Contains the local host (To Host received in a REQUEST on the originating side) of the originating side of a SIP call. This Tag is present only if the originating side of the call is SIP.
|
Format: IA5
|
Length in Octets: 1 to 256
|
Data Value: URL
|
Extended Data Value: No extended value.
|
General Information:
|
MGC Release: Release 9 and later.
|
|
Terminating Remote SIP Host (Tag: 4242)
Table 4 Terminating Remote SIP Host (Tag: 4242)
Name: Terminating Remote SIP Host
|
Tag: 4242
|
Source: MDL/Engine
|
Description/Purpose: Contains the remote host (To Host for a SIP call when sending a REQUEST from the PGW on the terminating side) for the terminating side of a call. This tag is present only if SIP appears on the terminating side of the call
|
Format: IA5
|
Length in Octets: 1 to 256
|
Data Value: URL
|
Extended Data Value: No extended value.
|
General Information:
|
MGC Release: Release 9 and later.
|
|
Terminating Local SIP Host (Tag: 4243)
Table 5 Terminating Local SIP Host (Tag: 4243)
Name: Terminating Local SIP Host
|
Tag: 4243
|
Source: MDL/Engine
|
Description/Purpose: Contains the local host (From Host for a SIP call when sending a REQUEST from the PGW on the terminating side) for the terminating side of a call. This Tag is present only if the terminating side of the call is SIP.
|
Format: IA5
|
Length in Octets: 1 to 256
|
Data Value: URL
|
Extended Data Value: No extended value.
|
General Information:
|
MGC Release: Release 9 and later.
|
|
Properties
The properties in this section are used for this feature. The parent objects for the properties involved in this feature are found in Table 6.
Table 6 Software Properties Related to This Feature
Property Name
|
Parent Object
|
AVM
|
DPNSS
|
EISUP
|
IOCC
|
ISDNPRI
|
MGCP
|
RLM
|
SESSION
|
SGCP
|
SS7-ANSI
|
SS7-China
|
SS7-ITU
|
SS7-Japan
|
SS7-UK
|
TALI-IOCC
|
TCAPOverIP
|
TrunkGroup
|
VSI
|
MaxSubscriptionDuration
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
X
|
|
MinEventSubscribeDuration
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
X
|
|
SubscribeNotifySupport
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
X
|
|
UnsolicitedNotifyMethod
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
X
|
|
The properties used for this feature are described in Table 7.
Note The four properties listed in Table 7 are existing properties whose definitions were modified for this feature. The valid values and default values have not changed.
Table 7 Modified Properties
Property
|
Definition
|
MaxSubscriptionDuration
|
Sets the maximum duration for which the subscription can exist before it needs a re-subscription. It is an integer value measured in milliseconds.
|
MinEventSubscribeDuration
|
Sets the minimum duration for which an event can be subscribed. It is an integer value measured in milliseconds.
|
SubscribeNotifySupport
|
Enables (1) or disables (0) SUBSCRIBE/NOTIFY method for solicited notification of SIP DTMF digits.
|
UnsolicitedNotifyMethod
|
Enables (1) or disables (0) Unsolicited NOTIFY method for unsolicited notification of SIP DTMF digits by the PGW.
|
Result Type Definitions
Table 8 shows the result type definition added for this feature. For information on other result type definitions for the Cisco MGC software, see the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.
Table 8 New Result Type Definitions
Result Number.
|
Result Type
|
Dataword1
|
Dataword2
|
Dataword3
|
Dataword4
|
Analysis Points
|
Result Type Valid For
|
Intermediate
|
End Point
|
A-digit analysis
|
B-digit analysis
|
Cause
|
Pre-analysis
|
7
|
FACILITY
|
type
|
treatment
|
0 (not used)
|
0 (not used)
|
|
|
X
|
X
|
|
|
FACILITY
The FACILITY result provides a means of setting originating and terminating redirection and call transfer behavior. It also can be used to define SIP call handling mode as proxy mode only for this call and can be configured for the source (A-number) or destination (B-number). As long as the parameter sipModeSelectionControl is set to permit selection of either B2BUA or Proxy mode, this FACILITY dialplan result type provides this "per-call" means of selection.
However, the use of this result is expanded beyond just selecting "Proxy-mode" for a call. It also includes provisioned data which indicates the PGW behavior with regard to redirection and SIP Refer handling.
The key thing is to know for which type of action you are provisioning and thus know the various dw1 and dw2 combinations required. Table 9 should help you to understand and determine this.
Dataword1: type
1 = Proxy Mode required
2 = Originating Redirection treatment action
3 = Originating Call Transfer treatment action
4 = Terminating Redirection treatment action
5 = Originating Redirection Rejection treatment action
Dataword2: treatment
This data word has values 1-4 and provides the actions required according to the type given in dw1. If dw1 is set to value 1 (Proxy mode), then this data word is not used.
Call Processing Actions According to FACILITY Configuration
Table 9 provides the call processing treatment applied according to the combinations of parameter sipModeSelectionControl and the dataword values from the FACILITY result-type. Unless otherwise stated, sipModeSelectionControl is set to value 1 (b2bua optional).
Table 9 SIP and Non SIP Call Processing Actions
FACILITY
Dw1 Value
|
FACILITY
Dw2 Value
|
PGW Call Processing Action
|
1
|
Any.
|
Action is according to the value of the XECfgParm parameter sipModeSelectionControl.
If sipModeSelectionControl=2, then the result-type is ignored because the main parameter is set for proxy mode.
If sipModeSelectionControl=1, then Set the PGW to indicate that Proxy mode is required for this call.
|
2
Originating Redirection treatment action
|
1
Backward transit of redirection to originating side not allowed.
|
This combination of dw1 and dw2 sets the originating side redirection action to indicate that backward transit of a redirection is not supported on the originating side of the PGW.
When PGW call control receives a redirection request from the PGW terminating side, it does not try to send back the redirection to the preceding switch. The existing local handling of redirection (that is, using cause analysis) applies.
(Applicable to SIP, DPNSS, and QSIG.)
|
2
Originating Redirection treatment action
|
2
Backward transit of redirection to originating side is supported unconditionally.
|
This combination of dw1 and dw2 sets the originating side redirection action to indicate that backward transit of a redirection is supported on the originating side of the PGW.
If PGW call control receives a redirection request from the terminating side, it transits the request back to the originating side for sending out to the preceding switch. The only limitation is if the PGW originating side protocol cannot support this handling.
(Applicable to SIP, DPNSS, and QSIG.)
|
2
Originating Redirection treatment action
|
3
Backward transit of redirection to originating side is conditionally supported on matching domains.
|
This combination of dw1 and dw2 is appropriate for a SIP B2BUA call (that is, SIP originating and SIP terminating).
If PGW call control receives a redirection request from the SIP terminating side, it transits the request back to the SIP originating side for sending out to the preceding network entity. This happens only if the domain in the From header received within the original INVITE on the OCC side matches the domain received within the Contact header received back in the 302 message on the SIP terminating side.
The redirection is transited back if the required domain of the redirected destination is the same as that of the originator of this call.
(Applicable to SIP.)
|
2
Originating Redirection treatment action
|
4
Backward transit of redirection to originating side is conditionally supported on nonmatching domains.
|
This combination of dw1 and dw2 is appropriate for a SIP-originated call and can be either a B2BUA mode call or an interworking call.
If PGW call control receives a redirection request from the PGW terminating side, it transits this back to the originating side for sending out to the preceding switch, provided that the domain received within the Contact header received back in the 302 message (terminating side) does not match the PGW domain.
In an interworking call, this provision is met because the Contact header domain is absent from the terminating side. If the call is SIP B2BUA, the provision is subject to the check as described.
The redirection is transited back if the required domain of the redirected destination is not the PGW domain. Otherwise, the PGW can deal with this redirection locally.
(Applicable to SIP originating side.)
|
3
Originating Call Transfer treatment action
|
1
Backward transit of call transfer to Originating side is not allowed.
|
This combination of dw1 and dw2 sets the originating side call transfer action to indicate that backward transit is not supported on the originating side of the PGW.
When PGW call control receives a call transfer request from the PGW terminating side, it does not try to send this back to the preceding switch. The local handling of call transfer is invoked.
(Applicable to SIP and QSIG terminating side.)
|
3
Originating Call Transfer treatment action
|
2
Backward transit of call transfer to originating side is supported unconditionally.
|
This combination of dw1 and dw2 sets the originating side call transfer action to indicate that backward transit of a call transfer request is supported on the originating side of the PGW.
If PGW call control receives a call transfer request from the terminating side, it transits the request back to the originating side for sending out to the preceding switch. The only limitation on this is if the PGW originating side protocol cannot support this handling.
(Applicable to SIP and QSIG.)
|
3
Originating Call Transfer treatment action
|
3
Backward transit of call transfer to originating side is conditionally supported on matching domains.
|
This combination of dw1 and dw2 is appropriate for a SIP originated B2BUA mode call where REFER actions have been requested on the PGW terminating side.
With this setting, the backward transit of a REFER request is conditionally supported on the originating side of the PGW. When the PGW terminating SIP side receives a REFER request and passes the request back to call control, PGW call control transits this request back to the PGW originating side provided that the received Refer-To header domain in the REFER message (terminating side) matches the domain in the From header received within the original INVITE on the OCC side.
The REFER back is transited if the required domain of the refer-to destination is the same as the originator of this call.
(Applicable to SIP.)
|
3
Originating Call Transfer treatment action
|
4
Backward transit of call transfer to originating side is conditionally supported on nonmatching domains.
|
This combination of dw1 and dw2 is appropriate for a SIP originated B2BUA mode call where REFER actions have been requested on the PGW terminating side.
With this setting, the backward transit of a REFER request is conditionally supported on the originating side of the PGW. When the PGW terminating SIP side receives a REFER request and passes this request back to call control, PGW call control transits this request back to the PGW originating side provided that the received refer-to header domain in the REFER message (terminating side) does not match the PGW domain.
The REFER back transits if the required domain of the refer-to destination is not the PGW domain. Otherwise, the PGW can deal with this locally.
(Applicable to SIP.)
|
4
Terminating Redirection treatment action
|
1
Unconditional SIP recursion.
|
This combination of dw1 and dw2 is specific to a SIP-terminated call and is designed to invoke SIP recursive redirection handling.
However, with this direct combination there is an inherent risk of looping. To avoid looping, the actual behavior associated with this combination is the same as the combination of dw1=4 and dw2=3.
(Applicable to SIP.)
|
4
Terminating Redirection treatment action
|
2
Unconditional passing of redirection request back to call control.
|
This combination of dw1 and dw2 is appropriate for the receipt of a redirection request on the PGW terminating side.
In this situation, the terminating side checks the FACILITY setting for the appropriate call processing action. The value 2 indicates that this request can be passed back to PGW call control for further handling.
Note The actual transit of the request back out on the PGW originating side depends on the FACILITY setting for that side.
(Applicable to SIP, DPNSS, QSIG, and SS7.)
|
4
Terminating Redirection treatment action
|
3
Conditional passing of redirection request back to call control on matching domains.
|
This combination of dw1 and dw2 is appropriate for a SIP-terminated call where the PGW SIP terminating side on receipt of a 3xx response provoking a redirection, checks the FACILITY setting for the appropriate call processing action.
The value 3 indicates that the request can be passed back into call control provided that the domain in the received Contact header within the 3xx message matches the PGW domain. If this is the case, then the PGW terminating side passes this request back to PGW call control for further handling.
Note The actual transit of the request back out on the PGW originating side depends on the FACILITY setting for that side.
The redirection request transits back to call control if the required domain of the redirected destination is the PGW domain where the PGW can deal with this request locally. If this is not the case, then SIP recursion is used.
|
4
Terminating Redirection treatment action
|
4
Conditional passing of redirection request back to call control on nonmatching domains.
|
This combination of dw1 and dw2 is appropriate for a SIP terminated call where the PGW SIP terminating side, on receipt of a 3xx response provoking a redirection, checks the FACILITY setting for the appropriate call processing action.
The value 4 indicates that the request can be passed back into call control if the domain in the received Contact header within the 3xx message does not match the domain in the To header sent in the outgoing INVITE (and received back in the 3xx message). If this is the case, then the PGW terminating side passes this request back to PGW call control for further handling.
Note The actual transit of the request back out on the PGW originating side depends the FACILITY setting for that side.
The redirection request passes back to call control if the required domain of the redirected destination is not the same domain as that previously attempted in the outgoing INVITE. If the domains are the same, then SIP recursion can be used (sending the new request out to the same domain it is already set up to use).
|
5
Originating Redirection Rejection treatment action
|
1
|
This combination of dw1 and dw2 is relevant only when the redirection request has been transitted to the originating side. This combination determines how a rejection for the request should be handled.
A value 1 for dw2 means that if PGW call control receives a REJECT from the originating side in response to a redirection request, it transits the REJECT to the terminating (that is, requesting) side.
(Applicable only to QSIG-QSIG calls.)
|
5
|
2
|
This combination of dw1 and dw2 is relevant only when the redirection request has been transitted to the originating side and determines how a rejection for the request should be handled.
A value 2 for dw2 means that if PGW call control receives a REJECT from the originating side in response to a redirection request, call control attempts to handle the redirection request locally by invoking cause analysis.
Note This is the default behavior in the absence of a provisioned originating redirection rejection treatment action.
|
none
|
none
|
Default behavior
On the PGW terminating side, the redirection or call transfer request behavior defaults to passing the request back to call control where it can be handled locally or, if there is an originating FACILITY result, propagated backwards to the previous network entity.
On PGW Originating side, the behavior defaults to local handling by call control and cause analysis or half-call handling rather than transiting the request back out on the Originating side.
|
Note The sigpath property siprediranalysismethod affects the 302 handling by the PGW. This property defines how the PGW handles the SIP redirection. The valid value for this property is any integer from 0 to 2. The default value for this property is 0.
0—Only analyze the target whose domain matches with the PGW domain
1—Always analyze
2—Never analyze
Cause Codes
SIP response codes are now saved in the event that backward transit is required on a B2BUA call. For information on other cause and location codes for the Cisco MGC software, see the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.
Obtaining Documentation, Obtaining Support, and Security Guidelines
For information on obtaining documentation, obtaining support, providing documentation feedback, security guidelines, and also recommended aliases and general Cisco documents, see the monthly What's New in Cisco Product Documentation, which also lists all new and revised Cisco technical documentation at
http://www.cisco.com/en/US/docs/general/whatsnew/whatsnew.html
Glossary
Table 10 contains definitions of acronyms and technical terms used in this feature module.
Table 10 Acronyms and Definitions
Acronym
|
Definition
|
B2BUA
|
Back to Back User Agent
|
DPNSS
|
Digital Private Network Signaling System. A PBX standard developed in the United Kingdom.
|
INAP
|
Intelligent Network Application Part. SS7 architectural protocol layer.
|
MGC
|
Cisco Media Gateway Controller
|
PGW
|
PSTN Gateway
|
QSIG
|
Q Signaling. Signaling standard. Common channel signaling protocol based on ISDN Q.931 standards and used by many digital PBXs.
|
SC
|
Signaling Controller
|
SIP
|
Session Initiation Protocol
|
This document is to be used in conjunction with the documents listed in the Related Documents section.
CCDE, CCENT, Cisco Eos, Cisco StadiumVision, the Cisco logo, DCE, and Welcome to the Human Network are trademarks; Changing the Way We Work, Live, Play, and Learn is a service mark; and Access Registrar, Aironet, AsyncOS, Bringing the Meeting To You, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, CCVP, Cisco, the Cisco Certified Internetwork Expert logo, Cisco IOS, Cisco Press, Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Collaboration Without Limitation, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Event Center, Fast Step, Follow Me Browsing, FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study, IronPort, the IronPort logo, LightStream, Linksys, MediaTone, MeetingPlace, MGX, Networkers, Networking Academy, Network Registrar, PCNow, PIX, PowerPanels, ProConnect, ScriptShare, SenderBase, SMARTnet, Spectrum Expert, StackWise, The Fastest Way to Increase Your Internet Quotient, TransPath, WebEx, and the WebEx logo 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. (0803R)
Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.
© 2008 Cisco Systems, Inc. All rights reserved.
