Guest

Cisco PGW 2200 Softswitch

Multiple IP Addresses in SIP Contact Header Support

  • Viewing Options

  • PDF (564.7 KB)
  • Feedback
Multiple IP Addresses in SIP Contact Header Support

Table Of Contents

Multiple IP Addresses in SIP Contact Header Support

Feature Overview

Example

Benefits

Limitations

Related Features and Technologies

Related Documents

Supported Platforms

Supported Standards, MIBs, and RFCs

Prerequisites for Using This Feature

Provisioning Procedures

Provisioning This Feature

Provisioning the ContactListOrder Property

Provisioning the SipRedirAnalysisMethod Property

Creating Dial Plan Data

Dial Plan Prerequisites

Preparing Trunk Data

Dial Plan Basics

Dial Plan Procedures

Adding the RETRY_ACTION Result Type

Modifying the RETRY_ACTION Result Type

Modifying the RETRY_ACTION Result Type and the Internal Cause Code

Deleting the RETRY_ACTION Result Type

Command Reference

Modified MML Commands

PROV-ED:sigsvcprop:ContactListOrder—Indicates the contact list order

PROV-ED:sigsvcprop:SipRedirAnalysisMethod—Indicates the SIP redirect analysis method

Reference Information

Planning for Provisioning

Collecting Provisioning Data

Provisioning Basics

Starting a Provisioning Session

Saving and Activating Your Provisioning Changes

Ending a Provisioning Session Without Activating Your Changes

Retrieving Provisioning Data

Properties

Obtaining Documentation, Obtaining Support, and Security Guidelines

Glossary


Multiple IP Addresses in SIP Contact Header Support


Document Release History

Publication Date
Comments

October 9, 2007

Added limitation concerning proxy mode to the document.

October 26, 2006

Initial version of the document.


Feature History

Release
Modification

9.5(2)

This feature was introduced on the Cisco PGW 2200 software Release 9.5(2)


This document describes the Multiple IP Addresses in SIP Contact Header Support feature.

This feature is described in the following sections:

Feature Overview

Supported Platforms

Supported Standards, MIBs, and RFCs

Prerequisites for Using This Feature

Provisioning Procedures

Command Reference

Reference Information

Obtaining Documentation, Obtaining Support, and Security Guidelines

Glossary

Feature Overview

The Multiple IP Addresses in SIP Contact Header Support feature supports multiple IP addresses in the SIP Contact header.

This feature allows the PGW 2200 to handle the received redirection (302) response messages from the User Agent (UA) /Proxy or any other network device with one or more contacts in one or more Contact headers (for example, Contact: a@cisco.com, b@cisco.com). The PGW 2200 uses the Uniform Resource Identifiers (URIs) in the Contact header, which could be one per Contact header; or one Contact header could have multiple URIs in it, to formulate one or more new outbound call requests.

The PGW 2200's Generic Analysis Module performs the following:

Subscriber Profile Retrieval; call screening in particular, makes use of the TimesTen main memory database (MMDB). This is done by the Engine via a function call.

A&B Number pre-analysis (e.g. for operator assisted or Equal Access calls)

A&B Number full analysis

Cause Analysis (New Route, Treatment, Cause Mapping)

Route Selection

During Generic analysis, this feature modifies the way the PGW 2200 performs re-analysis of the contacts contained from the 302 response, whether or not the domain is the MGC domain.

The PGW 2200 constructs three target lists of URIs (Target List, Used Target List, and Requested Target List) after receiving the 302 response containing the contact information. The Target List is preserved and is available for a subsequent request. The Target List contains a list of URIs with their respective address digits extracted into an additional data field, which is used by analysis for dial plan operation. Each time the 302 response message is received by the PGW 2200, the URI(s) contained in the message are added to the Target List, if it is not already in the list to prevent creating a loop condition.

If the received 302 message contains multiple URIs, the order in which the URIs are added into the list is as follows:

If the URIs received in the Contact header are accompanied by a "q" value, the order in which they are added to the Target List is defined by the q value. Where q is a value from 0 through 1, with the higher value indicating the higher preference.If no q value is present in the Contact header, a value of 1 is assumed.

The following is an example of a 302 message with a q-value.

SIP/2.0 302 Moved temporarily  
Via:SIP/2.0/UDP 
sipgw01.bmcag.com:5060;received=62.206.6.140;branch=z9hG4bKterm-8ad-04027805638-+49406
68610656  
From:"Anonymous"<sip:04027805638@sipgw01.bmcag.com;user=phone>;tag=292402270  
To:"+4940668610656"<sip:+4940668610656@62.206.3.30;user=phone>  
Call-ID:335f73eb-7a1a1b8a-7ed90676-5@sipgw01.bmcag.com  
CSeq:1 INVITE  
Contact:<sip:40668610656@62.206.3.10:5060;user=phone>;q=0.5,<sip:40668610656@212.105.2
16.10:5060;user=phone>;q=0.25 
Content-Length:0 

If no q-value exists for the URIs, the order in which the contacts are added to the Target List is determined by the order in which they are received by the PGW 2200.

If some Contact headers have a q value and some Contact headers do not have a q value, set the q value to 1 for the Contact headers without a q value; also, the order in which the Contact headers is added to the list is also defined by the q value.

When a new 302 response message is received, the ContactListOrder sigPath property defines how the new Contact headers URI in the new 302 response are appended to the existing Target List, which was constructed by the previously received 302 responses.

1-At the beginning of the list,

2-At the end of the list,

3-Replace the existing list with the new list

In addition to the Target List, the PGW 2200 also constructs a Used Target List and a Requested Target List to prevent creating a loop condition and to handle load share scenario.

All the Contact URIs in the Target List that have been used for re-analysis and then routing the call are removed from the Target List and added to the Used Target List to prevent inserting the same Contact URIs into the Target List to prevent a loop condition.

The new SIP destination URI obtained from Generic analysis (which may be different from the URI in the Target List) is inserted into the Requested Target List to help ensure successful SIP proxy 302 load sharing. For example, if the original INVITE message is sent to proxy1 according to the called number and routing analysis (INVITE A@proxy1); and then receive the response 302 (contact: A@proxy2, A@proxy3). Normally, the re-analysis for the redirection A-number also resolves to the same SIP route trunk group with the same URI A@proxy1. If it is found that the URI already exists in the Requested Target List, then the PGW 2200 replaces the destination URI with the URI in the Target List, that is, replacing the A@proxy1 with A@proxy2, so the new call is routed to A@proxy2 as the expected server.

When the PGW 2200 receives a 302 response message, a cause IC_RE_ANALYSIS_REQUESTED is sent indicating Cause analysis is required. As part of Cause analysis, the start of the Target List is retrieved, while also performing Cause analysis in the case where a redirection result is found to be set, where Cause analysis generates the result of RSLT_RETRY_ACTION. If the RETRY_ACTION dataword1 is "Redirect". Cause analysis retrieves the first unused URI in the Target List, and the resultant re-analysis procedure uses the URI as input. The maximum number of new re-requests that can be sent by the PGW 2200 is 5, or the RedirMax property value set on the incoming signaling service.

Generic analysis maintains a list of URIs that have been returned during analysis and routed. This list is used when comparing previous destination routes against the latest result returned to prevent routing to the same SIP destination.

The PGW 2200 then creates a new Terminating Call Control (TCC) module.This is the instance of the terminating protocol's state machine which updates/retrieves the call context structures. This module is allocated dynamically by the Engine, depending on the signaling path yielded by Number and Route Analysis.ThePGW 2200 sends the generated request to the UA. Each time the call is redirected the existing TCC is released and torn down.

The PGW may receive one of the following response codes to the new request:

Provisional response 100-Trying: Indicates that the INVITE request has been received by the UA/Proxy. If a session timeout occurs, the cause code is IC_NO_USER_RESPONDING, the TGAdvance is required to be set on this cause code.

Provisional response 18x responses: Indicates that call is being processed. The handling is the same as for the original INVITE request. If, after getting 18x responses, the call fails to be established, the call is considered as final failure and the call is terminated and no more new INVITE requests are sent based on the target list.

Redirection 302 response: If the new 302 response contains a new Contact header, and if the contact is unique, the contact is added to the list as defined by the ContactListOrder signaling service property value, only if PGW has not reached the limit for number of re-request.

Request Failure 4xx: It is considered as a final failure and regardless of whether or not the limit is reached, the call is handled as a non-redirected call.

Server Failure 5xx: Some times response 503 indicates the service is congested and should move to the next available URI in the Target List to generate a new request, if it has not reached the limit for the number of requests. The cause code for 503 is changed from IC_TEMPORARY_FAILURE to IC_SERVICE_UNAVAILABLE. The TGAdvance property is required to be set for cause code 503. For other 5xx response cause code, there is no need to provision TGAdvance.

Global Failure 6xx: The Target List is removed and the call is handled as the initial request.

No Response: If the PGW 2200 does not receive any response for a new request, resulting in a session timeout, the PGW processes the next available URI in the Target List to generate a new request if it has not yet reached the limit for the number of requests. The cause code for this response is changed from IC_RECOVERY_ON_TIMER_EXPIRY to IC_NO_USER_RESPONDING.

Example

The example illustrated in Figure 1 shows how the PGW 2200 handles a 302 message with multiple IP addresses in the Contact header:

Figure 1 Receiving Multiple IP Addresses in the Contact Header of a 302 Redirect Response

When a caller on a PSTN network makes a call to a callee via a SIP network:

1. The PGW 2200 sends an INVITE message to the callee.

2. The PGW 220 receives a 302 message from a SIP Redirect Server that contains two contact headers, one is to SIP Proxy1, and the other is to SIP Proxy2.

3. The PGW 2200 sends the new INVITE to SIP Proxy1.

4. Assuming the message was not received successfully, the PGW 2200 either receives the 503 response from SIP Proxy1, or no response at all.

5. The PGW 2200 sends a new INVITE request (INVITE2) to SIP Proxy2.

Benefits

This feature provides the following benefit:

Supports multiple IP addresses in the SIP Contact header

The Cisco PGW 2200 can perform digit analysis and modification, if required, before initiating a new INVITE request to the first IP address and subsequent IP addresses in the Contact header. If the INVITE request sent to the first IP address fails to get a response and the following three retries also fail, the PGW 2200 then sends the INVITE request to the second IP address in the list. After all of the IP addresses in the contact list are tried, the PGW 2200 returns to digit analysis or releases the call back though the PSTN.

Enhancement of Network Redundancy

This feature improves the reliability of the network by enabling access to other network devices when a SIP server fails. For example, you can provision the TGadvance cause analysis result for IC_NO_USER_RESPONDING and IC_SERVICE_UNAVAILABLE cause codes to re-route the call serially to the target list get from the Contact head of the SIP 302 response, until a successful termination is found or until the target list is exhausted.

For Multiple IP Addresses in SIP Contact Header Support feature requirement, if the TGadvance result is set for the cause code IC_NO_USER_RESPONDING and IC_SERVICE_UNAVAILABLE, the PGW 2200 can continue to re-route the call to the remaining target list URIs when INVITE timeout occurs, or when no final response after 100 trying, or it receives 503. Even if the target list is exhausted, the PGW 2200 can use an alternative trunk group to route the call if available.

Limitations

This feature does not work in the proxy mode. In proxy mode, the PGW 2200 just transits the 302 503 response of INVITE to the ingress side.

Related Features and Technologies

The following feature is related to this feature:

Redirection number modification and advanced A-Number(s) normalization

Route advance based on cause code.

Related Documents

This document contains information that is related to MML commands. 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 Platforms

The hardware platforms supported for the Cisco MGC software Release 9.5(2) are described in the Cisco Media Gateway Controller Hardware Installation Guide.

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, refer to the Cisco Media Gateway Controller Software Release 9 Management Information Base Guide.

RFCs

The PGW 2200 performs handling of the 302 messages in compliance with RFC 3261. No new or modified RFCs are supported by this feature.

Prerequisites for Using This Feature

You must have Cisco Media Gateway Controller (MGC) software Release 9.5(2). Prerequisites for this release can be found in the Release Notes for the Cisco Media Gateway Controller Software Release 9.5(2).

Provisioning Procedures

You must modify the provisioning data of your system to enable this feature. Before you begin provisioning this feature, we recommend that you plan your provisioning changes as described in the "Planning for Provisioning" section.


Tip You can find information on starting and ending provisioning sessions and retrieving provisioning data in the "Provisioning Basics" section.


The following section describes the provisioning tasks related to this feature:

Provisioning This Feature

Provisioning This Feature

Provision the ContactListOrder signaling service property to determine the order of sending new INVITES.

This section covers the following provisioning topics:

Provisioning the ContactListOrder Property

Modifying the RETRY_ACTION Result Type

Provisioning the ContactListOrder Property

The ContactListOrder setting defines the order in which the target list is appended, once a new Contact header is received in another 302 response message.

This section contains the procedures that you must perform to determine the order of sending new INVITES.

To set the order of sending new INVITES, perform the following steps:


Step 1 Start a provisioning session, as described in the "Starting a Provisioning Session" section.

Step 2 Enter the following command to set the order of sending new INVITES:

mml> prov-ed:sigsvcprop:name="sip-path",ContactListOrder=x 

Where:

name—MML name of a previously configured SIP service property.

ContactListOrder—The order in which the target list is appended for sending INVITES. With x being a value of 1 through 3.

1 (default)-At the beginning of the list

2-At the end of the list

3-Replace the list with the new contact list.

Step 3 Repeat Step 2 for each signaling path you want to set the order of sending new INVITES.

Step 4 If there are no other components that you need to provision, end your provisioning session as described in the "Saving and Activating Your Provisioning Changes" section.


Provisioning the SipRedirAnalysisMethod Property

The SipRedirAnalysisMethod setting defines how the PGW handles the SIP redirection target, once a 302 response message is received.

This section contains the procedures that you must perform to determine how the PGW handles the SIP redirection target.

To set how the PGW handles the SIP redirection target, perform the following steps:


Step 1 Start a provisioning session, as described in the "Starting a Provisioning Session" section.

Step 2 Enter the following command to determine how the PGW handles the SIP redirection target:

mml> prov-ed:sigsvcprop:name="sip-path",SipRedirAnalysisMethod=x 

Where:

name—MML name of a previously configured SIP service property.

SipRedirAnalysisMethod—Defines how the PGW handles the SIP redirection target. With x being a value of 0 through 2.

0 (default)-Conditional analysis, which performs digit analysis if the host in the 302 response message is the PGW domain; otherwise route the call directly to the 302 address.

1-Always perform digit analysis.

2-Never perform digit analysis.

Step 3 Repeat Step 2 for each signaling path you want to set how the PGW handles the SIP redirection target.

Step 4 If there are no other components that you need to provision, end your provisioning session as described in the "Saving and Activating Your Provisioning Changes" section.


Creating Dial Plan Data

The following sections describe the tasks related to creating a dial plan for this feature:

Dial Plan Prerequisites

Dial Plan Procedures

Dial Plan Prerequisites

This section lists the data that you must gather to successfully create a dial plan as part of this feature. For more information on planning dial plans for other functions of the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.

Preparing Trunk Data

During the provisioning process, all the bearer trunks that connect remote switches to all the media gateways attached to the Cisco MGC were defined. Each remote switch is identified by its destination point code (DPC), and each trunk is identified by its trunk ID or Circuit Identification Code (CIC).

You need the following information for your trunks:

Trunk ID—Designation assigned to a trunk.

Source Signaling Service—MML name of the previously defined source signaling service.
Valid signaling services are ISDN PRI, DPNSS, or any SS7 signaling service.

Source Span—Number of circuits assigned to the source span (range 0 through 65535).

Source Span ID—Identification assigned to the source span (range 0 through 65535).

Source Time Slot/CIC—Time slot or Circuit Identification Code (CIC) (range 0 through 31).

Destination Signaling Service—MML name of a previously defined destination signaling service.
Valid signaling services are ISDN PRI, DPNSS, or any SS7 signaling service.

Destination Span—Number of circuits assigned to the destination span (range 0 through 65535).

Destination Span ID—Identification assigned to the destination span (range 0 through 65535).

Destination Time Slot/CIC—Time slot or Circuit Identification Code (CIC) (range 0 through 31).

Line Type—T1 or E1.

Multiple Trunk Field—Number of trunks per span (greater than 0, but less than or equal to 31).

The ingress and egress trunk IDs must match the corresponding trunk IDs used on the remote switches. The circuit identification codes (CIC) are the SS7 values representing the trunks and must also match the CIC values defined at the remote switches.

The destination span ID and destination time slot must match the trunk configuration values defined during Cisco MGC configuration. The destination span ID is defined when configuring T1 and E1 controllers and must match the value of the nfas_int parameter. T1 spans use channels (time slots) 1-24 and E1 spans use time slots (channels) 0-31.

To save space, you might want to specify ranges of trunk IDs for each T1 or E1 connection. For large installations, you should make copies of this table or create your own worksheet with these columns.

Dial Plan Basics

The procedures in this section describe how to add, modify, and delete dial plan data and how to retrieve that data.

Adding Dial Plan Data

Modifying an Element of your Dial Plan Data

Ending a Provisioning Session Without Activating Your Changes

Retrieving Dial Plan Data

For more detailed information about creating a dial plan for your Cisco PGW 2200, refer to the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.

Adding Dial Plan Data

The order in which you provision dial plan tables is important. Many tables refer to other tables that must be defined first. The following list identifies the recommended sequence for dial plan provisioning:

1. Create the dial plan file (unique CustGrpID)

2. Provision Digit Modification

3. Provision the Service

4. Provision the Result and Result Sets

5. Provision the A-numbers and B-numbers

6. Provision CPC

7. Provision TMR analysis

8. Provision B-number NOA and NPI analysis

9. Provision TNS

10. Provision NANP B-number normalization

11. Provision the Location value

12. Provision the Cause value

13. Provision the A and B Whitelist and Blacklist screening files

To begin the process of creating a dial plan, log into the active Cisco PGW 2200, start an MML session, and enter the following command:

mml> numan-add:component:custgrpid=cust_groupID,param_name="param_value",...

Where:

component—The name of the component type you want to add to your dial plan. A complete list of the valid dial plan component types can be found in the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.

cust_groupID—Customer group ID number associated with your dial plan.

param_name—The name of the parameter you want to configure for the selected component in your dial plan. A complete list of the valid parameters for each dial plan component type can be found in the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.

param_value—The value of the parameter you want to configure for the selected component in your dial plan. A complete list of the valid values for the parameters of each dial plan component type can be found in the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.

For example, to provision a route result type called resultone, you would enter the following command:

mml> numan-add:resulttable:custgrpid="t777",resulttype="route",setname="setone", 
name="resultone",dw1="rtlistone" 

Modifying an Element of your Dial Plan Data

To modify an existing dial plan, log into the active Cisco PGW 2200, start an MML session, and enter the following command:

mml> numan-ed:component:custgrpid="cust_groupID",param_name="param_value",...

Where:

component—The name of the component type you want to modify in your dial plan. A complete list of the valid dial plan component types can be found in the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.

cust_groupID—Customer group ID number associated with your dial plan.

param_name—The name of the parameter you want to configure for the selected component in your dial plan. A complete list of the valid parameters for each dial plan component type can be found in the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.

param_value—The value of the parameter you want to configure for the selected component in your dial plan. A complete list of the valid values for the parameters of each dial plan component type can be found in the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.

For example, to modify a result table, you would enter the following command:

mml> numan-ed:resulttable:custgrpid="t777",resulttype="route",setname="setone", 
name="resulttwo",dw1="rtlistone" 

Deleting an Element from your Dial Plan Data

To delete an element from your dial plan, log into the active Cisco PGW 2200, start an MML session, and enter the following command:

mml> numan-dlt:component:custgrpid="cust_groupID",name="MML_name" 

Where:

component—The name of the component type you want to delete from your dial plan. A complete list of the valid dial plan component types can be found in the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.

cust_groupID—Customer group ID number associated with your dial plan.

MML_name—The MML name of the selected component you want to delete from your dial plan.

For example, to delete a result set called setone, you would enter the following command:

mml> numan-dlt:resultset:custgrpid="t001",name="setone" 

Retrieving Dial Plan Data

You can use the numan-rtrv MML command to retrieve information about your current dial plan settings. The ways in which you can use this command to retrieve dial plan data are described in the following sections:

Retrieving Data for an Individual Component

Retrieving Data for All Components of a Particular Type


Note You can verify dial plans using the translation verification viewer on the Cisco PGW 2200 toolbar. For information on using the translation verification viewer, refer to the Cisco Media Gateway Controller Software Release 9 Operations, Maintenance, and Troubleshooting Guide.


Retrieving Data for an Individual Component

You can retrieve dial plan data on any individual component on your system. To do this, log in to the active Cisco PGW 2200, start an MML session, and enter the following command:

mml> numan-rtrv:component:custgrpid="cust_groupID",name="MML_name" 

Where:

component—The name of the component type you want to retrieve from your dial plan. A complete list of the valid dial plan component types can be found in the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.

cust_groupID—Customer group ID number associated with your dial plan.

MML_name—The MML name of the selected component you want to retrieve from your dial plan.

For example, to retrieve the settings for a result set called setone, you would enter the following command:

mml> numan-rtrv:resultset:custgrpid="t001",name="setone" 

Retrieving Data for All Components of a Particular Type

You can retrieve dial plan data on all components of a particular type on your system. To do this, log in to the active Cisco PGW 2200, start an MML session, and enter the following command:

mml> numan-rtrv:component:custgrpid="cust_groupID","all" 

Where:

component—The name of the component type you want to retrieve from your dial plan. A complete list of the valid dial plan component types can be found in the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.

cust_groupID—Customer group ID number associated with your dial plan.

For example, to retrieve the settings for all result sets in your dial plan, you would enter the following command:

mml> numan-rtrv:resultset:custgrpid="t001","all" 

Dial Plan Procedures

This section contains the procedures required for provisioning the dial plan data for this feature. For more information on creating dial plans for other functions of the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Dial Plan Guide.

Adding the RETRY_ACTION Result Type

The retry action capability is used during Cause analysis. You can use the numan-add MML command to add the desired retry action capability.

To add the retry action capability, complete the following steps:


Step 1 Log into the active Cisco PGW 2200, start an MML session, and enter the following command to add a dial plan:

mml> numan-add:dialplan:custgrpid="dpl1",overdec="yes" 

Step 2 Enter the following command to add a result set:

mml> numan-add:resultset:custgrpid="dpl1",name="set1" 

Step 3 Enter the following command to add a result table:

mml> numan-add:resulttable:custgrpid="dpl1",resulttype="RETRY_ACTION",dw1="Reattempt", 
setname="ra1",name="ra1" 

Where:

custgrpid—Customer group ID. A 4-digit alphanumeric string (enclosed in straight quotes) to identify the dial plan.

overdec—Overdecadic. A 2- or 3-character string that identifies the overdecadic dial plan status. Valid values are: yes (overdecadic) or no (decadic).

resulttype—Result type. Indicates the result type being provisioned. Any valid result type name is allowed. The result type for this feature is RETRY_ACTION.

dw1—Dataword1. Indicates the dataword1 value being provisioned, where dw1 can be: Reattempt, TGAdvance, or Redirect. Dataword values vary depending on the result type being provisioned.

setname—Result set name. The name you give to the result set. The name can be as many as 20 alphanumeric characters enclosed in straight quotes. The name should begin with a letter.

name—Name. The name you give to the component. The name can be as many as 20 alphanumeric characters enclosed in straight quotes. The name should begin with a letter.

Step 4 To verify the command was executed successfully, enter the command:

mml> numan-rtrv:dialplan:"all" 

Step 5 Repeat Step 3, as necessary, to add new rows and new RETRY_ACTION result types to the result table.


Modifying the RETRY_ACTION Result Type

This section contains the procedures that you must perform to modify the RETRY_ACTION to TGAdvance for cause analysis result for the cause code IC_NO_USER_RESPONDING(35) and IC_SERVICE_UNAVAILABLE(78), perform the following steps:


Step 1 Start a provisioning session, as described in the "Starting a Provisioning Session" section.

Step 2 Enter the following commands to set the RETRY_ACTION result type to TGAdvance:

mml> numan-ed:resulttable:custgrpid="1111",name="CSCOADRST3",resulttype="RETRY_ACTION", 
dw1="Tgadvance",setname="CSCOADRST3" 
mml> numan-ed:cause:custgrpid="1111",causevalue=35,setname="CSCOADRST3" 
mml> numan-ed:cause:custgrpid="1111",causevalue=78,setname="CSCOADRST3" 

Step 3 If there are no other components that you need to provision, end your provisioning session as described in the "Saving and Activating Your Provisioning Changes" section.


Modifying the RETRY_ACTION Result Type and the Internal Cause Code

To modify the RETRY_ACTION to Redirect for cause analysis result for the cause code IC_REANALYSIS_REQUESTED (145) of your dial plan, perform the following steps:


Step 1 Start a provisioning session, as described in the "Starting a Provisioning Session" section.

Step 2 Enter the following commands to set the RETRY_ACTION result type to Redirect and the cause value to 145:

mml> numan-ed:resulttable:custgrpid="1111",name="CSCOADRST2",resulttype="RETRY_ACTION", 
dw1="Redirect",setname="CSCOADRST2" 
mml> numan-ed:cause:custgrpid="1111",causevalue=145,setname="CSCOADRST2" 

Step 3 If there are no other components that you need to provision, end your provisioning session as described in the "Saving and Activating Your Provisioning Changes" section.


Deleting the RETRY_ACTION Result Type

The retry action capability selection is used during Cause analysis. You can use the numan-dlt MML command to delete the desired retry action capability.

To delete the retry action capability, complete the following steps:


Step 1 Log into the active Cisco PGW 2200, start an MML session, and enter the following command to delete the MAP capability:

Step 2 Enter the following command to delete the result set from the result table:

mml> numan-dlt:resulttable:custgrpid="dpl1",setname="set1",name="rt1" 

Where:

custgrpid—Customer group ID. A 4-digit alphanumeric string (enclosed in straight quotes) to identify the dial plan.

setname—Result set name. The name you give to the result set. The name can be as many as 20 alphanumeric characters enclosed in straight quotes. The name should begin with a letter.

name—Name. The name you give to the component. The name can be as many as 20 alphanumeric characters enclosed in straight quotes. The name should begin with a letter.

Step 3 To verify the command was executed successfully, enter the command:

mml> numan-rtrv:dialplan:"all" 

Step 4 Repeat step 2, as necessary, to delete the RETRY_ACTION capability from each result set.


This example illustrate PGW handle the 302 message with multiple IP address in contact header.

Command Reference

This section documents modified Man-Machine Language (MML) commands. All other MML commands are documented in the Cisco Media Gateway Controller Software Release 9 MML Command Reference Guide.

Modified MML Commands

This section contains the MML commands that were modified for this feature.

PROV-ED:sigsvcprop:ContactListOrder—Indicates the contact list order

Purpose:

This MML command sets the contact list order for sending new INVITES.

Syntax:

prov-ed:sigsvcprop:name="sip-path",ContactListOrder=x 
prov-rtrv:sigsvcprop:name="sip-path"

Input Description:

ContactListOrder—The ContactListOrder defines the order in which the target list is appended, once a new Contact header is received in another 300, 301, 0r 302 response message. Values are 1 (default)-At the beginning of the list, 2-At the end of the list, or 3-Replace the list with the new list.

name—MML name of a previously configured SIP path.

Output Description:

name—MML name of the specified SIP path.

Example:

The MML commands shown in the following example sets and retrieves the state of the ContactListOrder:

sh-bamboo mml> prov-ed:sigsvcprop:name="sip-path",contactlistorder="2" 
MGC-01 - Media Gateway Controller 2005-11-01 09:56:29.916 EST 
M COMPLD 
"sigsvcprop" 
; 
sh-bamboo mml> prov-rtrv:sigsvcprop:name="sip-path" 
MGC-01 - Media Gateway Controller 2005-11-01 09:56:42.654 EST 
M RTRV 
"session=chgcontac:sigsvcprop" 
/* 
ContactListOrder = 2 
*/ 


Comments:

Performance Impact Category: A


PROV-ED:sigsvcprop:SipRedirAnalysisMethod—Indicates the SIP redirect analysis method

Purpose:

This MML command sets the SIP redirect analysis method for digit analysis.

Syntax:

prov-ed:sigsvcprop:name="sip-path",SipRedirAnalysisMethod=x 
prov-rtrv:sigsvcprop:name="sip-path"

Input Description:

SipRedirAnalysisMethod—Defines how the PGW handles the SIP redirection target. Values are: 0(default)-Conditional analysis, which performs digit analysis if the host in the 302 response message is the PGW domain; otherwise route the call directly to the 302 address; 1-Always perform digit analysis; 2-Never perform digit analysis.

name—MML name of a previously configured SIP path.

Output Description:

name—MML name of the specified SIP redirect analysis method.

Example:

The MML commands shown in the following example sets and retrieves the state of the SipRedirAnalysisMethod:

sh-bamboo mml> 
prov-ed:sigsvcprop:name="sip-path",SipRedirAnalysisMethod="2" 
MGC-01 - Media Gateway Controller 2005-11-01 09:56:29.916 EST 
M COMPLD 
"sigsvcprop" 
; 
sh-bamboo mml> prov-rtrv:sigsvcprop:name="sip-path" 
MGC-01 - Media Gateway Controller 2005-11-01 09:56:42.654 EST 
M RTRV 
"session=chgcontac:sigsvcprop" 
/* 
SipRedirAnalysisMethod = 2 
*/ 


Comments:

Performance Impact Category: A


Reference Information

The following sections contain reference material related to this feature. Information is included on the following areas:

Planning for Provisioning

Provisioning Basics

Properties

Planning for Provisioning

This section lists the data that you must gather to successfully provision this feature. For more information on planning the provisioning for the rest of the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.

Collecting Provisioning Data

Collect the following data to set the order of sending new INVITES.

MML name of the specified signaling service property

Contact list order

RedirMax setting (sigPath)

Reattempt setting (rttrnkgrp)

TGAdvance setting (sigPath)

Provisioning Basics

Use the procedures in this section to start a provisioning session, save, and activate the changes you have made.

Starting a Provisioning Session

Saving and Activating Your Provisioning Changes

Ending a Provisioning Session Without Activating Your Changes

Retrieving Provisioning Data

For more detailed information about provisioning your Cisco PGW 2200, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.

Starting a Provisioning Session

You might need to start a provisioning session as part of your system operations. To do this, log in to the active Cisco PGW 2200, start an MML session, and enter the following command:

prov-sta::srcver="curr_ver",dstver="mod_ver"

Where:

curr_ver—The name of the current configuration version. In place of the name of the current configuration version, you can also enter:

new—A new default session configuration; no existing source configuration is available.

active—Selects the active configuration as the source for configuration changes.


Note If you do not know the name of your current configuration session, you can use the procedure described in the "Retrieving Data on the Current Provisioning Session" section on page 7.


mod_ver—A new configuration version name that contains your provisioning changes.

For example, to use a configuration version called ver1 as the basis for a version to be called ver2, you would enter the following command:

prov-sta::srcver="ver1",dstver="ver2"

Once a provisioning session is underway, you may use the prov-add, prov-ed, and prov-dlt MML commands to add, modify, and delete components on your system. This document describes how to provision this feature. For more information on provisioning other components on your Cisco PGW 2200, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.

There are two ways to close your provisioning session: saving and activating your provisioning changes, as described in the "Saving and Activating Your Provisioning Changes" section or ending your provisioning session without saving and activating your changes, as described in the "Ending a Provisioning Session Without Activating Your Changes" section.

Saving and Activating Your Provisioning Changes

When you have completed making provisioning changes in your session, you must enter a command to save and activate your changes. There are two different provisioning MML commands that do this: prov-cpy and prov-dply.


Caution Using the prov-cpy or prov-dply MML command can severely impact your system's call processing performance, depending on the extent of your provisioning changes. We recommend that these commands be issued during a maintenance window when traffic is minimal.

The prov-cpy MML command is used to save and activate your changes on simplex Cisco PGW 2200 (single-host) systems.


Note When you enter the prov-cpy command, your provisioning session is also automatically ended. If you want to make additional provisioning changes, you must start a new provisioning session, as described in the "Starting a Provisioning Session" section.



Caution Do not use the prov-cpy command to save and activate your changes on a continuous-service Cisco PGW 2200 (active and standby hosts) system. Saving and activating using prov-cpy on such a system would require using the prov-sync MML command to synchronize the provisioning data on the active and standby hosts. The system does not indicate when the synchronization process fails, which would create problems when a switchover operation occurs.

The prov-dply MML command is used to save and activate your changes on the active and standby
Cisco PGW 2200s in a continuous-service system. This command should not be used on a Cisco PGW 2200 in a simplex configuration.


Note When you enter the prov-dply command, your provisioning session is also automatically ended, unless an error occurs during execution. If you want to make additional provisioning changes, you must start a new provisioning session, as described in the "Starting a Provisioning Session" section.


Ending a Provisioning Session Without Activating Your Changes

If you want to end a provisioning session without saving and activating the changes you have entered, enter the prov-stp MML command. This command ends your current provisioning session and your changes are not entered.

Retrieving Provisioning Data

You can use the prov-rtrv MML command to retrieve information about your current provisioning settings. The ways you can use this command to retrieve provisioning data are described in the following sections:

Retrieving Data for an Individual Component

Retrieving Data for All Components

Retrieving Data for All Components of a Particular Type

Retrieving Data on the Current Provisioning Session

Retrieving Data on Supported Signaling Protocols

Retrieving Data for an Individual Component

You can retrieve provisioning data for any individual component on your system. To do this, log in to the active Cisco PGW 2200, start an MML session, and enter the following command:

prov-rtrv:component:name=MML_name

Where:

component—The MML component type associated with the desired component. You can find a complete list of MML component types in the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.

MML_name—The MML name for the desired component. You can determine the MML names for the various components using the prov-rtrv:all MML command.

For example, to view the provisioning data for a SS7 signaling service called ss7svc1, you would enter the following command:

prov-rtrv:ss7path:name="ss7svc1"

The response to the command is dependent upon the component type associated with the desired component. For example, to view the properties for an Signaling Control Connection Part (SCCP) User Adaptation (SUA) routing key called suakey1, you would enter the following command:

prov-rtrv:suakey:name="suakey1"

Retrieving Data for All Components

You can retrieve data for all of the components provisioned on your system. To do this, log in to the active Cisco PGW 2200, start an MML session, and enter the following command:

prov-rtrv:all

Retrieving Data for All Components of a Particular Type

You can retrieve provisioning data for all components of a particular type on your system. To do this, log in to the active Cisco PGW 2200, start an MML session, and enter the following command:

prov-rtrv:component:"all"

Where: component is the MML component type associated with the desired component group. You can find a complete list of MML component types in the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.

For example, to view the provisioning data for all SS7 signaling services, you would enter the following command:

prov-rtrv:ss7path:"all"

Retrieving Data on the Current Provisioning Session

You can retrieve data on the current provisioning session. To do this, log in to the active Cisco PGW 2200, start an MML session, and enter the following command:

prov-rtrv:session

The system returns a response similar to the following:

MGC-02 - Media Gateway Controller 2005-01-13 13:39:19
M  RTRV
   "session=jtest:session"
   /*
Session ID = mml1
SRCVER = active
DSTVER = jtest
   */

Retrieving Data on Supported Signaling Protocols

You can retrieve protocol data for the current provisioning session. To do this, log in to the active Cisco PGW 2200, start an MML session, and enter the following command:

prov-rtrv:variants

Properties

The properties in this section are used for this feature. For information on other properties for the Cisco MGC software, refer to the Cisco Media Gateway Controller Software Release 9 Provisioning Guide.

The parent object for the properties involved in this feature are found in Table 1.

Table 1 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
LI
CTI-QBE
SIP

ContactListOrder

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

X

SipRedirAnalysisMethod

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

X


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

Table 2 Added Properties

Property
Definition

ContactListOrder

Defines the order in which the target list is appended, once new Contact headers are received in a 300, 301, or 302 response message. Values are 1 (default)-At the beginning of the list, 2-At the end of the list, or 3-Replace the list with the new list. Valid values: 1 through 3.

Default value:1

SipRedirAnalysisMethod

Defines how the PGW handles the SIP redirection target. Values are: 0(default)-Conditional analysis, which performs digit analysis if the host in the 302 response message is the PGW domain; otherwise route the call directly to the 302 address; 1-Always perform digit analysis; 2-Never perform digit analysis.

Valid values: 1 through 2.

Default value: 0


Table 3 lists the properties that can be provisioned and indicates if the modified property value takes effect without stopping and restarting the MGC software.

Table 3 Provisionable Properties 

Property
Modified Value Takes Effect Without Restart

ContactListOrder

Yes

SipRedirAnalysisMethod

Yes


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 4 contains expansions of acronyms used in this feature module.

Table 4 Expansions 

Acronym
Expansion

B2BUA

Back-to-back User Agent

MGC

Cisco Media Gateway Controller

PGW

PSTN Gateway

SIP

Session Initiation Protocol

UA

User Agent

URI

Uniform Resource Identifier