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, page 2
•
Supported Platforms, page 5
•
Supported Standards, MIBs, and RFCs, page 6
•
Prerequisites for Using This Feature, page 6
•
Provisioning Procedures, page 6
•
Command Reference, page 14
•
Reference Information, page 16
•
Obtaining Documentation, Obtaining Support, and Security Guidelines, page 21
•
Glossary, page 21
Americas Headquarters:
Cisco Systems, Inc., 170 West Tasman Drive, San Jose, CA 95134-1706 USA
© 2007 Cisco Systems, Inc. All rights reserved.
Multiple IP Addresses in SIP Contact Header Support
Feature Overview
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: [email protected], [email protected]). 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:[email protected];user=phone>;tag=292402270
To:"+4940668610656"<sip:[email protected];user=phone>
Call-ID:[email protected]
CSeq:1 INVITE
Contact:<sip:[email protected]:5060;user=phone>;q=0.5,<sip:[email protected]
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.
Multiple IP Addresses in SIP Contact Header Support
2
Multiple IP Addresses in SIP Contact Header Support
Feature Overview
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.
Multiple IP Addresses in SIP Contact Header Support
3
Multiple IP Addresses in SIP Contact Header Support
Feature Overview
•
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
SIP Redirect Server
(1) INVITE
PGW
PSTN network
(2) 302 with two Contact headers
SIP Proxy2
SS7
(5) INVITE to SIP Proxy 2
SIP
SIP Proxy1
(3) INVITE to SIP Proxy 1
(4) 503 or no response
170977
SS7
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.
Multiple IP Addresses in SIP Contact Header Support
4
Multiple IP Addresses in SIP Contact Header Support
Supported Platforms
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.
Multiple IP Addresses in SIP Contact Header Support
5
Multiple IP Addresses in SIP Contact Header Support
Supported Standards, MIBs, and RFCs
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 on page 16.
Tip
You can find information on starting and ending provisioning sessions and retrieving provisioning data
in the “Provisioning Basics” section on page 17.
The following section describes the provisioning tasks related to this feature:
•
Provisioning This Feature, page 6
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, page 7
•
Modifying the RETRY_ACTION Result Type, page 13
Multiple IP Addresses in SIP Contact Header Support
6
Multiple IP Addresses in SIP Contact Header Support
Provisioning Procedures
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 on page 17.
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 on page 18.
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 on page 17.
Multiple IP Addresses in SIP Contact Header Support
7
Multiple IP Addresses in SIP Contact Header Support
Creating Dial Plan Data
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 on page 18.
Creating Dial Plan Data
The following sections describe the tasks related to creating a dial plan for this feature:
•
Dial Plan Prerequisites, page 8
•
Dial Plan Procedures, page 12
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.
Multiple IP Addresses in SIP Contact Header Support
8
Multiple IP Addresses in SIP Contact Header Support
Creating Dial Plan Data
•
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, page 9
•
Modifying an Element of your Dial Plan Data, page 10
•
Ending a Provisioning Session Without Activating Your Changes, page 18
•
Retrieving Dial Plan Data, page 11
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
Multiple IP Addresses in SIP Contact Header Support
9
Multiple IP Addresses in SIP Contact Header Support
Creating Dial Plan Data
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"
Multiple IP Addresses in SIP Contact Header Support
10
Multiple IP Addresses in SIP Contact Header Support
Creating Dial Plan Data
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:
Note
•
Retrieving Data for an Individual Component, page 11
•
Retrieving Data for All Components of a Particular Type, page 12
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"
Multiple IP Addresses in SIP Contact Header Support
11
Multiple IP Addresses in SIP Contact Header Support
Creating Dial Plan Data
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.
Multiple IP Addresses in SIP Contact Header Support
12
Multiple IP Addresses in SIP Contact Header Support
Creating Dial Plan Data
Step 4
•
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.
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 on page 17.
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 on page 18.
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 on page 17.
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 on page 18.
Multiple IP Addresses in SIP Contact Header Support
13
Multiple IP Addresses in SIP Contact Header Support
Command Reference
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:
Step 3
•
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.
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.
Multiple IP Addresses in SIP Contact Header Support
14
Multiple IP Addresses in SIP Contact Header Support
Command Reference
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:
Output
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.
name—MML name of the specified SIP redirect analysis method.
Multiple IP Addresses in SIP Contact Header Support
15
Multiple IP Addresses in SIP Contact Header Support
Reference Information
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, page 16
•
Provisioning Basics, page 17
•
Properties, page 20
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)
Multiple IP Addresses in SIP Contact Header Support
16
Multiple IP Addresses in SIP Contact Header Support
Reference Information
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, page 17
•
Saving and Activating Your Provisioning Changes, page 18
•
Ending a Provisioning Session Without Activating Your Changes, page 18
•
Retrieving Provisioning Data, page 18
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 on page 18 or ending
your provisioning session without saving and activating your changes, as described in the “Ending a
Provisioning Session Without Activating Your Changes” section on page 18.
Multiple IP Addresses in SIP Contact Header Support
17
Multiple IP Addresses in SIP Contact Header Support
Reference Information
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 on page 17.
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 on page 17.
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, page 19
•
Retrieving Data for All Components, page 19
•
Retrieving Data for All Components of a Particular Type, page 19
Multiple IP Addresses in SIP Contact Header Support
18
Multiple IP Addresses in SIP Contact Header Support
Reference Information
•
Retrieving Data on the Current Provisioning Session, page 19
•
Retrieving Data on Supported Signaling Protocols, page 20
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
Multiple IP Addresses in SIP Contact Header Support
19
Multiple IP Addresses in SIP Contact Header Support
Reference Information
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
SIP
CTI-QBE
LI
VSI
TrunkGroup
TCAPOverIP
TALI-IOCC
SS7-UK
SS7-Japan
SS7-ITU
SS7-China
SS7-ANSI
SGCP
SESSION
RLM
MGCP
ISDNPRI
IOCC
EISUP
Property Name
DPNSS
AVM
Parent Object
ContactListOrder
X
SipRedirAnalysisMethod
X
The properties used for this feature are described in Table 2.
Multiple IP Addresses in SIP Contact Header Support
20
Multiple IP Addresses in SIP Contact Header Support
Obtaining Documentation, Obtaining Support, and Security Guidelines
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.
Multiple IP Addresses in SIP Contact Header Support
21
Multiple IP Addresses in SIP Contact Header Support
Glossary
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
CCVP, the Cisco logo, and the Cisco Square Bridge logo are trademarks of Cisco Systems, Inc.; Changing the Way We Work, Live, Play, and Learn is a servic
Inc.; and Access Registrar, Aironet, BPX, Catalyst, CCDA, CCDP, CCIE, CCIP, CCNA, CCNP, CCSP, Cisco, the Cisco Certified Internetwork Expert logo
Cisco Systems, Cisco Systems Capital, the Cisco Systems logo, Cisco Unity, Enterprise/Solver, EtherChannel, EtherFast, EtherSwitch, Fast Step
FormShare, GigaDrive, HomeLink, Internet Quotient, IOS, iPhone, IP/TV, iQ Expertise, the iQ logo, iQ Net Readiness Scorecard, iQuick Study
MeetingPlace, MGX, Networking Academy, Network Registrar, PIX, ProConnect, ScriptShare, SMARTnet, StackWise, The Fastest Way to Increase Yo
TransPath are registered trademarks of Cisco Systems, Inc. and/or its affiliates in the United States and certain other countries.
All other trademarks mentioned in this document or Website are the property of their respective owners. The use of the word partner does not imply a
between Cisco and any other company. (0709R)
Multiple IP Addresses in SIP Contact Header Support
22