Guest

Cisco PGW 2200 Softswitch

SIP Service Handling and Feature Interworking Enhancements

  • Viewing Options

  • PDF (476.3 KB)
  • Feedback
SIP Service Handling and Feature Interworking Enhancements

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:

cd /opt/CiscoMGC/etc 

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:

mml> sw-over::confirm

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", 
dw2="3",setname="rset1" 

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.

Originating Remote SIP Host (Tag: 4201)

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.