SIP Feature and Provisioning Guide
Chapter 3 - SIP Trunks
Download this chapter
Chapter 3 - SIP TrunksChapter 3 - SIP Trunks
Download the complete book
SIP Feature and Provisioning Guide - Book Length PDFSIP Feature and Provisioning Guide - Book Length PDF (PDF - 3 MB)
give_us_feedback

Table Of Contents

SIP Trunks

General Characteristics and Usage of SIP Trunks

SIP Trunk Provisioning Example

CLI Provisioning Example

Additional Options

Call Processing on SIP Trunks

Validation of Source IP Address for Incoming SIP Messages

Loop Detection

Locating SIP Servers Using DNS Queries

Locating SIP Servers from an Incoming Request

Locating SIP Servers from an Outbound Request

Provisioning Commands

Reliable Provisional Responses

Signaling for Reliable Provisionable Responses

Provisioning Procedure for Reliable Provisional Responses

Provisioning Session Timers for SIP Trunks

SIP Timer Values for SIP Trunks

SIP Route Advance

SIP Status Monitoring and SIP Element Audit

Status Monitoring of SIP Elements

Status Monitoring Functions

Using the Status and Control Commands

Troubleshooting with Alarm Reports

SIP Trunk Group States

Internal SIP Audit

SIP Element Audit

Audit Occurrence

Provisioning

Alarms

OPTIONS Message

SIP Triggers

Call Redirection

Call Redirection Process

Call Redirection Provisioning

Support for Sending 302 on Call Forwarding

Sending 302 Feature Description

SIP 302 Provisioning

Diversion Indication for SIP Trunks

Signaling for Diversion Indication

Provisioning Procedure for Diversion Indication

Number Portability Information and Carrier Identification Code

Number Portability

Carrier Identification Code over SIP

SIP Trunk Subgroups

Description of SIP Trunk Subgroups Feature

Proprietary TGID Parameter

Standards-Based TGID Parameter

Example of an INVITE Message

SIP-T, ISUP Version, ISUP Transparency, and GTD

Description of SIP-T, ISUP Version, ISUP Transparency, and GTD

Provisioning Procedures for SIP-T, ISUP Version, ISUP Transparency, and GTD

DTMF SIP Signaling

Feature Description

Exceptions and Limitations

Provisioning Procedure for DTMF SIP Signaling

Asserted Identity and User-Level Privacy

Signaling for Asserted Identity and User-Level Privacy

Provisioning Procedure for Asserted Identity and User-Level Privacy

Calling Name Delivery on Terminating SIP Trunks

Third-Party Call Control

ANI-Based Routing

ANI Screening on Incoming Calls

T.38 Fax Relay CA Controlled Mode Across SIP Trunk Interface

SIP Call Transfer with REFER and SIP INVITE with Replaces

SIP REFER Message Processing

Replaces Header Processing

Referred-By Header Processing

Provisioning Procedure for SIP REFER and SIP INVITE with Replaces

SIP Trunk to Voice-Mail Server

Cluster Routing

CMS-to-MGC Routing

SIP Server Groups

Purpose of the SIP Server Groups Feature

Provisionable Parameters Affecting SIP Server Groups

Understanding SIP Server Group Operations

Tree Model Approach to SIP Element Selection

Blacklisting SIP Endpoints That Are Not Reachable

SIP Element Advance On 5XX SIP Responses

Server Groups for Established Dialog Requests

Outbound SIP Messages That Apply to SIP Server Groups

Server Groups for Sending Initial Invite Request

Server Groups for Sending Established Dialog Requests

Server Groups for Sending Response Retransmissions

SIP Element Selection Algorithm

Example 1—Server Groups Provisioned to Advance to Next SIP Element in the SG, Initial INVITE

Example 2—Server Group Provisioned to Advance to Next Server Group

Transport Type for SIP Element Selection

Applications and Use Cases for SIP Server Groups

Basic SIP Network Domain

Server Groups for Outbound SIP Calls to a Proxy Farm

Server Groups for SIP Requests to SBC Endpoints

Server Groups for Response Retransmissions to a Proxy Farm

Limitations on SIP Server Groups

Server Groups and CANCEL/ACK Messages

Server Group Provisioning Limits

Server Groups and SIP Element TSAP-ADDR Provisioning

Server Groups and Call Redirection

Server Groups and Call Transfer

Server Groups and Expires Header

Server Groups and Status Monitoring

Provisioning SIP Server Groups

Provisioning a SIP Trunk Group without Server Groups

Provisioning a SIP Trunk Group with Server Groups

Troubleshooting SIP Server Groups


SIP Trunks

Revised: July 17, 2008, OL-12397-14

This chapter describes SIP trunk features on the Cisco BTS 10200 Softswitch, and how to use them. SIP trunks service SIP calls between the BTS 10200 and external SIP entities other than local SIP subscribers, such as voice-mail servers, remote call agents, and SIP proxies.

The information in this chapter includes

•General Characteristics and Usage of SIP Trunks

•SIP Trunk Provisioning Example

•Call Processing on SIP Trunks

•Validation of Source IP Address for Incoming SIP Messages

•Loop Detection

•Locating SIP Servers Using DNS Queries

•Reliable Provisional Responses

•Provisioning Session Timers for SIP Trunks

•SIP Timer Values for SIP Trunks

•SIP Route Advance

•SIP Status Monitoring and SIP Element Audit

•SIP Triggers

•Call Redirection

•Support for Sending 302 on Call Forwarding

•Diversion Indication for SIP Trunks

•Number Portability Information and Carrier Identification Code

•SIP Trunk Subgroups

•SIP-T, ISUP Version, ISUP Transparency, and GTD

•DTMF SIP Signaling

•Asserted Identity and User-Level Privacy

•Third-Party Call Control

•ANI-Based Routing

•T.38 Fax Relay CA Controlled Mode Across SIP Trunk Interface

•SIP Call Transfer with REFER and SIP INVITE with Replaces

•SIP Trunk to Voice-Mail Server

•Cluster Routing

•CMS-to-MGC Routing

•SIP Server Groups

General Characteristics and Usage of SIP Trunks

The BTS 10200 can be configured to use User Datagram Protocol (UDP) or Transmission Control Protocol (TCP) transport for communications over a SIP trunk. A SIP trunk is configured in the BTS 10200 with the following:

•IP address or Fully Qualified Domain Name (FQDN) and port for address information of external SIP entity

•Dial plan and dialed digit string entries for routing of calls received on the trunk

•Profile to define the feature set and SIP protocol properties for the trunk

Following are the general usage guidelines and limitations for SIP trunks:

•Typically, one trunk is defined for each external SIP entity communicating with the BTS 10200 over SIP.

•Multiple trunks can be associated with a provisioned route set providing route advance functionality.

•SIP trunks have OAM state and status, and can be set in service and out of service by the administrator.

•SIP trunks set themselves operationally out of service if the remote SIP entity does not respond. You can enable or disable the monitoring for this function through the status_monitoring field in the sip-element table.

•Trunks can be defined as trunk types SIP or SIP-T.

•External SIP entities are addressed as follows:

–SIP-T trunks must communicate with the BTS 10200 using the SIP-T protocol.

–SIP trunks must communicate with the BTS 10200 using the standard SIP protocol.

•A regular SIP call can be received on a SIP-T trunk.

•The system imposes limits on the decoding of incoming SIP messages. These limits are intended to protect the system from decoding extremely large messages, which in turn could overload the system and cause performance problems. See the "Limitations on Number of URLs, Parameters, and Headers (Release 5.0, Maintenance Release 1 and Later)" section on page 4-9.

SIP Trunk Provisioning Example

The following example, a local BTS 10200 subscriber makes a call out from a SIP trunk to a SIP proxy serving an NPA-NXX domain.

The example shows how to create a trunk group and associate it with the IP address of the proxy. It also shows how to provision the originator's dial plan with the dialed digits associated with the trunk.

Note Before provisioning, identify the following:
1. The first 6 dial digits of the SIP proxy NPA-NXX domain: in this example, 469-555.
2. Provisioned dial plan ID of the originator in BTS 10200: in this example, dp1.
3. IP address of the SIP proxy: in this example, 192.168.3.3.

CLI Provisioning Example 

add softsw_tg_profile id=<profile_id>; protocol_type=SIP;

add pop id=<pop_id>; state=tx; country=usa; timezone=CST;

add sip-element; tsap-addr=192.168.3.3;

add trunk_grp id=<trunk_group_id>; tg_type=SOFTSW; softsw_tsap_addr=192.168.3.3; 
dial_plan_id=dp1; tg_profile_id=<profile_id>; call_agent_id=<ca_id>; 
pop_id=<pop_id>;

add route id=<route_id>; tgn1-id=<trunk_id>;

add route-guide id=<route_guide_id>; policy_type=ROUTE; policy_id=<route_id>;

add destination dest-id=<dest_proxy_id>; call-type=LOCAL; route-type=ROUTE; 
route_guide_id=<route_guide_id>;

add dial-plan id=dp1; digit-string=469-555; dest-id=<dest_proxy_id>;

control trunk-grp id=<trunk_group_id> target-state=INS; mode=forced:

control sip-element tsap-addr=192.168.3.3; target-state=INS;

Additional Options

•You can provision the system to send the +CC (country code) format. See the note in the "Call Processing on SIP Trunks" section for further details.

•The TSAP address in the outbound SIP trunk group can be provisioned with a static IP address. The inbound SIP trunk group must be provisioned to match the domain name in the incoming INVITE message top-most Via header. If you do not provision the TSAP address field this way, the call is rejected with 403 Forbidden message. If you prefer to avoid DNS lookups and use the static IP address, we suggest using at least three SIP trunk groups: two for outbound with the IP addresses of two remote softswitches, and one for inbound with the domain name of one remote softswitch.

Call Processing on SIP Trunks

Outbound calls on the BTS 10200 are processed by the BTS 10200 routing system. The routing system selects an outbound SIP trunk based on the digits dialed and the dial plan of the originating entity. The SIP call is then transmitted out a TCP or UDP socket toward the IP address associated with the trunk selected by routing. SIP call features and characteristics are applied to the outbound call based on the feature selections in the trunk profile associated with the trunk.

Note RFC 3398 states that any outbound SIP number with NOA=NATIONAL must be prefixed with "+CCnumber" which is an international format, and any number with NOA=subscriber must be given an international format. The sending of the full E.164 format is enabled by a flag (send-full-e164) in the softsw-tg-profile table to enable interworking with downstream devices that require this number format.

For inbound calls, the SIP call is received on a TCP or UDP socket. To determine a SIP trunk associated with a the call, the BTS 10200 compares the address of the previous-hop SIP entity in the VIA header of a request with the IP addresses associated with the provisioned SIP trunks, looking for a match. The system uses the domain name or IP address of the top-most VIA header of the received INVITE to identify the inbound SIP trunk group, unless the sip-inbound-policy-profile table is provisioned.

If the previous-hop SIP entity is represented by an FQDN, the BTS 10200 compares it with SIP trunks associated with this FQDN. If the SIP call is not associated with any trunk, the call is refused, unless it is identified as coming from a local BTS 10200 subscriber. The SIP call is then sent to the routing system with the trunk identification. The routing system uses the dial plan associated with the inbound trunk and the dialed digits to make routing decisions for the outbound direction.

SIP inbound policy parameters are not defined by default, but if you provision them, these parameters enable the system to determine the incoming SIP trunk. The policy defines specific SIP message headers the system should look for to identify the incoming SIP trunk when a dialog-initiating request is received. The starting policy is normally specified in the SIP-INBOUND-POLICY-PROFILE-ID of the Call Agent Profile table. However, if this value is unspecified, the system applies the trunk-group identification technique of matching the sent-by in the VIA of a request to the TSAP address of a trunk group. Finally, if that does not identify a trunk group, the system attempts to route the call based on subscriber identification.

Validation of Source IP Address for Incoming SIP Messages

The system can perform source IP address validation of incoming messages received on SIP trunks. This validation process is intended to reduce the risk of security attacks, which can occur if a packet is sniffed in the network and then sent from a different or rogue IP address, or domain (information that can be read from the Via header). By default, IP address validation is disabled on the Cisco BTS 10200 Softswitch. The service provider can enable this capability using the SIA-TG-VALIDATE-SOURCE-IP token in the ca-config table. This is a switch-wide parameter, and applies to all SIP trunk groups.

You can enable IP address validation using the following command: 

add ca-config type=SIA-TG-VALIDATE-SOURCE-IP; datatype=BOOLEAN; value=Y;

Note By default, SIA-TG-VALIDATE-SOURCE-IP is set to N, and IP address validation is disabled.

Loop Detection

The system supports provisionable parameters in the softsw-tg-table. The parameters, which allow control of the maximum-forwards and hop-counter fields of the SIP Invite message, are as follows:

•HOP-COUNTER-MAX

•HOP-COUNTER-SUPP

•MAX-FORWARDS

•SCALE-FACTOR

Note The hop count between SIP and SS7 networks is scaled appropriately in the BTS 10200 based on the provisioning of the SCALE-FACTOR token.

The description and relationship of these parameters are provided in the Softswitch Trunk Group Profile table in the Cisco BTS 10200 Softswitch CLI Database.

Locating SIP Servers Using DNS Queries

This section explains how the system can locate SIP servers based on inbound and outbound requests.

Locating SIP Servers from an Incoming Request

The system can locate SIP servers based on information in the inbound request.

The BTS 10200 can request and accept TCP connections. The system provides for the selection of TCP or UDP on trunk groups with or without SRV support. When accepting connections, the BTS 10200 listens for and accepts TCP connection requests. It also listens for incoming requests on UDP. Once a request is received, the system sends SIP responses using the same transport type as the associated request. If this occurs over a TCP connection and the connection still exists, the system reuses that connection. If the connection is gone, the system attempts to establish a new connection to the same address.

Locating SIP Servers from an Outbound Request

The system can locate SIP servers based on SIP trunk provisioning applicable to the outbound request.

The NAPTR and SRV DNS functions allow the BTS 10200 SIP interface to correctly interoperate with proxy farms and find proxies and redirect servers. Operators can designate some service hosts as primary servers, and others as backup. When provisioned to support NAPTR and SRV functions, the BTS 10200 discovers the most preferred transport protocol of the locally supported destination, and obtains an SRV query string to locate a server supporting that protocol. The system follows the procedures described in RFC 2782 and RFC 3263 to determine the transport, IP address, and port for the next hop.

Note To provision NAPTR and SRV support, set the DNS-SRV-SUPP field in the SIP-ELEMENT table to RFC2782_LABELS, and provision the element ID as a NAPTR or SRV name.

The NAPTR lookup procedure depends on the size of the message compared to the path maximum transmission unit (MTU) size stated in RFC 3261 and RFC 3263 (typically 1300 bytes). The implementation in the Cisco BTS 10200 Softswitch is based on the SIP Working Group Document Issue 760 (http://bugs.sipit.net/show_bug.cgi?id=760). That document provides guidance regarding the conflicting directives between RFC 3261 and RFC 3263 when a message size exceeds the MTU limit and NAPTR lookups are involved. The system processes the lookup as described in this section.

Figure 3-1 shows the transport selection procedure for sending SIP requests based on NAPTR and SRV records, that is, when the value of the DNS-SRV-SUPP token is provisioned as RFC 2782_LABELS.

Figure 3-1 Transport Selection for Sending SIP Requests Based on NAPTR and SRV

Following is an explanation of the logic shown in Figure 3-1.

•If the message size is less than the path MTU limit (1300 bytes), the sequence is as follows:

a. The system looks up a NAPTR record, and chooses a transport protocol based on the priority of the NAPTR record. Only that chosen transport protocol is used to route the message, and servers associated with other protocols are not contacted.

b. If no NAPTR record is found, the system performs a best-effort lookup by assuming that an SRV record exists that has the same name as the NAPTR record. The procedure continues as follows:

–A UDP SRV record is looked up first, using the _sip._udp prefix. If it is resolved, the servers on the resulting list are contacted and the UDP transport is used to send the message.

–If no UDP SRV record is found, a TCP SRV record is searched, using the _sip._tcp prefix. If it is resolved, the servers on the resulting list are contacted and TCP transport is used to send the message.

•If the message size is greater than the path MTU limit (1300 bytes), the sequence is as follows:

a. The system performs a NAPTR lookup for records supporting TCP transport only. The resulting query string from the NAPTR lookup is used to perform an SRV lookup. If it is resolved, the servers on the resulting list are contacted and TCP transport is used to send the message.

b. If no NAPTR record is found, the system performs a best-effort lookup by assuming that an SRV record exists. the procedure continues as follows:

–A locally generated query string is used to query SRV records, using TCP as preferred transport and the _sip._tcp prefix. If such a record is found, servers on the resulting list are contacted and TCP transport is used to send the message.

–If no TCP SRV record is found, a UDP SRV record for the same TSAP address (prefixed with _sip._udp) is searched. If such a record is found, all servers on the resulting list are contacted and UDP transport is used to send the message.

The following details apply to all DNS queries described above:

•The above procedure (selecting only a single transport) applies only to NAPTR or SRV provisioning, that is, when the following are both true:

–The SIP trunk profile is provisioned with SRV support enabled.

–The TSAP address is provisioned with either a NAPTR or SRV name.

•After the system selects a transport type, only that type is used for signaling. If the chosen transport does not work, the system does not attempt any other transport mechanism, and the call fails.

•If the NAPTR and SRV queries fail, the system attempts a best-effort A-record query and uses UDP to send the message.

Tip These steps add overhead to the process of resolving an address. Therefore, SRV should be enabled only if the benefits of the address resolution procedure are required. A an alternative, you can consider using SIP Server Groups, an efficient procedure that does not involve a DNS query.

Traversing the SRV List for Failure Responses and Retransmission Timeouts

This section describes how the BTS 10200 traverses the SRV list.

•503 Response—When the BTS 10200 receives a 503 response (service unavailable) from the server in the SRV list that was last attempted, it resubmits the same request as a new transaction (with a new branch ID) to the next IP address in the SRV list.

•Retransmission timer expires—If an SRV server receiving the INVITE does not respond within the retransmission timer period, the BTS 10200 can send the next retransmission of the same request to the same server (as recommended in RFC 3263), or to the next server in the SRV list (legacy BTS 10200 behavior). This is controlled using a provisionable flag, DNS_SRV_ADV_ON_RETRANS_TIMEOUT on the SIP-ELEMENT table.

–If DNS_SRV_ADV_ON_RETRANS_TIMEOUT is set to N, all retransmissions of a message are exhausted sending to a single address before attempting to send to the next address. Keep in mind that some calls might not complete if one of the nodes in an SRV list returns a 503 message, even though other nodes in the list are capable of handling the request successfully.

–If the flag is set to Y (the default value), the system retransmits the same request as a new transaction (with a new branch ID) to the next IP address in the SRV list.

A-Record DNS Queries for Outgoing Messages

The system can use A-record DNS queries to locate SIP servers. The system selects the DNS query and the transport mechanism based on the value of the DNS-SRV-SUPP field in the SIP-ELEMENT table. If this field is set to NONE, the transport is selected based on the NON-SRV-TRANSPORT field of the SIP-ELEMENT table. Possible values for this field are as follows:

–UDP (default)—If the message size is less than 1300 bytes as described in RFC 3261 and RFC 3263, the system uses UDP. If the message size is greater than 1300 bytes, the system uses TCP; however, if TCP fails, the system attempts to use UDP.

–UDP-ONLY—The initial outbound request uses UDP regardless of the message size. However, the transport used for subsequent outbound requests is based on the negotiated transport type exchanged in the Contact header during dialog establishment.

–TCP—Use TCP only.

Note If the value of DNS-SRV-SUPP is set to RFC 2782_LABELS, the system ignores the NON-SRV-TRANSPORT field.

When performing an A-record DNS query, the system tries each IP address to which the FQDN resolves, (in succession) when there is a failure to communicate with the destination SIP endpoint. The system does this for both UDP and TCP transport mechanisms.

Figure 3-2 shows the transport selection procedure for sending SIP requests based on A-Record queries, that is, when the value of the DNS-SRV-SUPP token is provisioned as NONE.

Figure 3-2 Transport Selection for Sending SIP Requests Based on A-Record Lookup

Provisioning Commands

This section explains how to provision the system to locate SIP servers through NAPTR and SRV DNS queries, and through A-Record DNS queries.

Provisioning the System to Use NAPTR and SRV DNS Queries

Follow these steps to provision the system to use NAPTR and SRV DNS queries.

Step 1 Enable NAPTR and SRV DNS queries. 

change sip-element tsap-addr=<TSAP address, such as host.server.com>; 
dns-srv-supp=RFC2782_LABELS;

Step 2 Provision the TSAP address in the trunk group for the SIP server. 

change trunk_grp id=<trunk group id>; softsw_tsap_addr=<see list of values below>;

Either of the following can be provisioned for softsw-tsap-addr:

–NAPTR name

–SRV name

The use of either NAPTR or SRV names requires correctly configured DNS servers. We recommend the following options when you are provisioning NAPTR and SRV in the DNS servers:

•When you are using SRV, if a host name is provisioned in the TSAP address, include a port. This allows the application to identify the address as a host name and skip NAPTR and SRV queries.

•If an SRV name is required, provision NAPTR entries to provide SRV replacement strings instead of waiting for a failure on the NAPTR query to make an SRV query.

Provisioning the System to Use A-Record DNS Queries

Follow these steps to provision the system to use A-record DNS queries.

Step 1 Verify that NAPTR and SRV DNS queries are disabled. If necessary, disable NAPTR and SRV DNS queries. 

show sip-element tsap-addr=<TSAP address, such as host.server.com>;

Note Read the system response to verify that dns-srv-supp is set to NONE (this is the default value).

If it is not already set to NONE, use the following command: 

change sip-element tsap-addr=<TSAP address, such as host.server.com>; 
dns_srv_supp=NONE;

Step 2 Provision the transport type. 

change sip-element tsap-addr=<TSAP address, such as host.server.com>; 
non-srv-transport=<see list of values below>;

Any one of the following can be provisioned for non-srv-transport:

–UDP (default)—If the message size is less than 1300 bytes as described in RFC 3261 and RFC 3263, the system uses UDP. If the message size is greater than 1300 bytes, the system uses TCP; however, if TCP fails, the system attempts to use UDP.

–UDP-ONLY—The initial outbound request uses UDP regardless of the message size. However, the transport used for subsequent outbound requests is based on the negotiated transport type exchanged in the Contact header during dialog establishment.

–TCP—Use TCP only.

Step 3 Provision the TSAP address in the trunk group for the SIP server. 

change trunk-grp id=<trunk group id>; softsw_tsap_addr=<see list of values below>;

The value of softsw_tsap_addr must match the tsap_addr that is provisioned for an existing sip_element or sip_server_grp. Any one of the following can be provisioned for softsw-tsap-addr:

–Host name

–Host name and port

–IP address

–IP address and port

Note The use of host names requires correctly configured DNS servers.

Reliable Provisional Responses

SIP defines two types of responses, provisional and final. Final responses convey the result of the request processing and are sent reliably. Provisional responses provide progress information about the request processing but are not sent reliably in the base SIP protocol. The reliable provisional responses feature provides end-to-end reliability of provisional responses across BTS 10200 SIP trunks.

Signaling for Reliable Provisionable Responses

Provisional responses in SIP telephony calls represent backward alerting and progress signaling messages, which are important for interoperation with PSTN networks. Therefore, for SIP-T calls on the Cisco BTS 10200, reliable provisional responses are mandatory. They are optional for regular SIP calls.

Cisco BTS 10200 support for this feature follows the specifications described in RFC 3262. A provisioning flag is provided to enable or disable this feature, and the feature is disabled by default. For SIP trunks provisioned as SIP-T trunk type, the system internally ignores the flag and always enables the feature. In such cases, the feature is mandatory. Therefore, the ability to enable or disable the feature applies to regular SIP trunks only. There is one exception: SIP-T trunks receiving SIP-T calls (calls with ISUP attachments) can also receive incoming regular SIP calls. In this case, the feature (enabled or disabled) for the regular SIP call is determined by the provisioning flag on that SIP-T trunk.

The provisioning flag (PRACK-FLAG) is a parameter in the Softswitch Trunk Group Profile table. For provisioning details, see the "If the remote endpoint does not support the feature, the remote endpoint refuses the call." section.

For calls received on a BTS 10200 regular SIP trunk, or regular SIP (non-SIP-T) calls received on a SIP-T trunk, the following feature behavior applies:

•If the received INVITE indicates this feature is required, all provisional responses are sent reliably, regardless of the provisioned feature setting on the trunk.

•If the received INVITE indicates this feature is supported, all provisional responses are sent reliably if the feature is enabled on the trunk.

•If the received INVITE indicates the feature is not supported, the call is refused if the feature is enabled on the trunk.

•If the received INVITE indicates the feature is not supported, the call is accepted if the feature is disabled on the trunk. Provisional responses are not sent reliably.

For calls sent out a Cisco BTS 10200 regular SIP trunk, the following feature behavior applies:

•If the feature is enabled on the trunk, the SIP Invite message sent contains a Required header with a tag value of 100rel.

•If the feature is enabled on the trunk and the remote endpoint supports or requires the feature, all provisional responses are sent reliably to the BTS 10200.

•If the feature is enabled on the trunk, and the remote endpoint does not support the feature, the remote endpoint refuses the call.

•If the feature is disabled on the trunk, the SIP Invite message that is sent contains a Supported header with a tag value of 100rel.

•If the feature is disabled on the trunk and the remote endpoint supports the feature, the remote endpoint controls which provisional response sent requires reliability.

•If the feature is disabled on the trunk and the remote endpoint does not support the feature, provisional responses are not received reliably.

For SIP-T calls received on a BTS 10200 SIP trunk provisioned as SIP-T, the following feature behavior applies:

•If the received INVITE indicates this feature is required or supported, all provisional responses are sent reliably.

•If the received INVITE indicates the feature is not supported, the call is refused.

For all calls sent out a BTS 10200 SIP trunk provisioned as SIP-T, the following feature behavior applies:

•The SIP-T INVITE message sent contains a Required header with a tag value of 100rel.

•If the remote endpoint supports or requires the feature, all provisional responses are sent reliably to the BTS 10200.

•If the remote endpoint does not support the feature, the remote endpoint refuses the call.

Provisioning Procedure for Reliable Provisional Responses

The following commands control the Reliable Provisional Response feature for regular SIP calls on all trunks associated with the SIP trunk profile <profile_id>.

Step 1 The default for making reliable provisional responses not required for regular SIP calls sent or received over a SIP trunk is 

change softsw-tg-profile id=<profile_id>; prack-flag=N;

Step 2 To make reliable provisional responses required for regular SIP calls sent or received over a SIP trunk, use the following command: 

change softsw-tg-profile id=<profile_id>; prack-flag=Y;

Note When reliable provisional responses are not required, the BTS 10200 does not make them required on remote SIP entities. However, the reliable provisional responses might still occur if a remote SIP entity requires it of the BTS 10200.

The prack-flag parameter applies only to SIP calls on regular SIP trunks, and regular SIP calls received on SIP-T provisioned trunks.

Provisioning Session Timers for SIP Trunks

Use the commands in the following procedure to provision session timers for SIP trunks. Session timers can be enabled or disabled for all SIP trunks (switch-wide) or for individual SIP trunks; they are disabled by default.

The session timer values are provisioned through the MIN-SE and SESSION-EXPIRES-DELTA-SECS tokens in the sip-timer-profile table. The id of the sip-timer-profile table record is then specified as the Value for the ca-config record of Type=sip_timer_profile_id. The id of the sip-timer-profile table can also be associated with a softsw-tg-profile record for SIP trunks. If you provision the timer values for a specific trunk, that overrides the ca-config default.

Note For a detailed description of session timers, see "SIP Session Timers" section on page 4-7

Step 1 Adjust the session timer values in the sip-timer-profile table if necessary.

Note The session duration field value is in seconds with a range of 100 to 7200. The minimum session duration field value is in seconds with a range of 100 to 1800.

We recommend a value of at least 1800 for each of these fields. 

add sip-timer-profile id=<timer_profile_id>; session-expires-delta-secs=7200; 
min-se=1800;

Step 2 Enable session timers on the applicable softswitch trunk group profile, and assign the sip-timer-profile-id. 

add softsw-tg-profile id=<profile_id>; session-timer-allowed=Y; 
sip-timer-profile-id=<timer_profile_id>

Tip Session timers are disabled by default (session-timer-allowed=N), so you must enable them as shown in the above command if you want this capability.

Step 3 Assign a TSAP address in the sip-element table: 

add sip-element tsap-addr=<TSAP address, such as host.server.com>;

Step 4 Assign the TG; use the same TSAP address as in the applicable sip-element table. 

add trunk-grp id=101; call-agent-id=CA146; tg-type=softsw; dial-plan-id=tg-dp; 
tg-profile-id=SIP123PROFILE; softsw-tsap-id=<TSAP address>;

Step 5 For a switch-wide default for SIP trunks (if the trunk is not specifically provisioned), add a default sip-timer-profile-id to the ca-config table as follows: 

add ca-config type=SIP_TIMER_PROFILE_ID; datatype=string; 
value=<sip_timer_profile_id>;

Tip If you provision the timer values for a specific trunk (by pointing to a sip-timer-profile in the softsw-tg-profile), that overrides the ca-config default.

SIP Timer Values for SIP Trunks

Note This section describes how to provision SIP timer values for SIP trunks. For a comprehensive listing of SIP timers, see Chapter 4, "SIP System Features."

SIP timer values are provisioned in the sip-timer-profile table. The id of the sip-timer-profile table record is then specified as the Value for the ca-config record of Type=sip_timer_profile_id. The id of the sip-timer-profile table can also be associated with a softsw-tg-profile record for SIP trunks. If you provision the timer values for a specific trunk, that overrides the ca-config default. The default values are adequate for many installations. If customization is required, then a sip-timer-profile table can be provisioned and associated with all calls, or with calls on specific trunks.

The following steps provision the SIP timer values.

Step 1 Adjust the session timer values in the sip-timer-profile table if necessary (example shown). 

add sip-timer-profile id=<timer_profile_id>; timer-t1-milli=500;

Step 2 Enable session timers on the applicable softswitch trunk group profile and assign a sip-timer-profile-id that the system uses for call processing. 

add softsw-tg-profile id=<profile_id>; session-timer-allowed=Y; 
sip-timer-profile-id=<timer_profile_id>;

Step 3 Assign a TSAP address in the sip-element table. Also assign a sip-timer-profile-id that the system uses for OPTIONS-based auditing. 

add sip-element tsap-addr=<TSAP address, such as host.server.com>; 
sip-timer-profile-id=<timer_profile_id>;

Step 4 Assign the TG; use the same TSAP address as in the applicable sip-element table. 

add trunk-grp id=101; call-agent-id=CA146; tg-type=softsw; dial-plan-id=tg-dp; 
tg-profile-id=SIP123PROFILE; softsw-tsap-id=<TSAP address>;

Step 5 For a switch-wide default for SIP trunks (if the trunk is not specifically provisioned), add a default sip-timer-profile-id to the ca-config table. 

add ca-config type=SIP_TIMER_PROFILE_ID; datatype=string; 
value=<sip_timer_profile_id>;

Note If you provision the timer values for a specific trunk (in the softsw-tg-profile table), this takes precedence over the switch-wide default value provisioned for sip-timer-profile-id in the ca-config table.

SIP Route Advance

When a SIP trunk is marked operationally OOS by the SIP element audit feature, the system automatically performs a route advance for subsequent calls, provided that there are additional routes provisioned to the called party.

SIP Status Monitoring and SIP Element Audit

This section describes the status-monitoring process and two types of SIP audits performed by the BTS 10200. It includes the following topics:

•"Status Monitoring of SIP Elements" section

•"Internal SIP Audit" section

•"SIP Element Audit" section

Status Monitoring of SIP Elements

Status monitoring is a feature of the SIP element that can be enabled or disabled on the element by provisioning the STATUS-MONITORING flag. When status monitoring is enabled (which is the default), the SIP element sends out SIP OPTIONS requests using the SIP element during quiet times (no SIP message activity on element) to check the operational status of the associated remote SIP endpoint.

The status monitoring feature of the SIP element is independent of the server groups feature. The status monitoring feature functions the same for a SIP element regardless if the element is provisioned under a server group, or rather under a SIP trunk, under both, or neither.

Figure 3-3 shows the SIP element state diagram. It illustrates the SIP element states when the STATUS-MONITORING flag is enabled or disbaled.

Status Monitoring Functions

We recommend that you leave status monitoring enabled on SIP elements used in server groups. This allows a SIP element to be placed operationally out of service (OOS) on a SIP transaction timeout. In this case, subsequent SIP transactions and SIP calls avoid choosing this SIP element until the audit mechanism restores the element back into service. See Figure 3-3 for details on the SIP element state when the STATUS-MONITORING flag is enabled (set to Y).

Figure 3-3 SIP Element States Diagram

If status monitoring is disabled on a SIP element, the SIP element operational state will not be placed operationally OOS due to a SIP request (sent) timeout (see Figure 3-3). If a SIP element is previously operational OOS when status monitoring is disabled, the operational state is forced automatically in service (INS). The 162 alarm for this SIP element is cleared.

If the SIP element is operational INS with status monitoring disabled when a SIP request timeout occurred, the SIP element remains operational INS. The 162 alarm is not raised. Although the SIP element remains in service, the SIP element is marked unavailable for the current SIP transaction and another SIP element is chosen if possible. Subsequent SIP transactions and calls may continue to select this SIP element. This may result in SIP messages and retransmissions towards this SIP endpoint.

The SIP element operational state of OOS due to transient congestion (indicated by a response with a Retry-After duration) is unaffected by the status monitoring feature (see Figure 3-3). In this case, the SIP element will be set operational OOS for the specified duration of the transient congestion and return back in service once the duration is complete regardless of the status monitoring feature setting. The 162 alarm will be cleared once the duration has ended.

When the administration state of the SIP element is OOS, the status monitoring feature is internally forced disabled regardless of the provisioning for the feature. The feature is controlled by the provisioned setting when the administration state of the SIP element is INS. When the SIP element is initially provisioned with default values, the administration state is OOS. Once placed into service, the status monitoring feature will automatically enable and OPTIONS messages may be sent since the default for status monitoring is enabled. If the administrator switched the administrative state of the SIP element to OOS, it also internally switches status monitoring to disabled (if enabled), and the behavior of this switch is the same as described previously in this section. Only the SIP element administration state changes can affect the status monitoring feature. Trunk group and Server group administration state changes do not affect the status monitoring feature provisioned setting.

Using the Status and Control Commands

Note All of the IP addresses used in this document are examples, and are used for illustration purposes only.

Status Commands

Enter the following CLI command to display the status of a SIP element: 

status sip-element tsap-addr=10.10.10.1;

The following examples illustrate the system responses to this command:

•If the SIP element is operationally in service (INS):

SIP Element TSAP Addr : 10.10.10.1

Oper Status : INS

•If the SIP element is operationally out of service (OOS), that is, a SIP request sent through this SIP element occurred a timeout:

SIP Element TSAP Addr : 10.10.10.1

Oper Status : OOS

•The SIP element is operationally OOS. A SIP request was sent through this SIP element and a response was received with a Retry-After header containing a duration value. The SIP element is currently OOS for this duration. The timestamp indicates what time the SIP element will return into service.

SIP Element TSAP Addr : 10.10.10.1

Oper Status : OOS (Congested until 2006-04-05 12:05:32)

Control Commands

Enter the following CLI commands to control the administrative state of a SIP element of SIP SG: 

control sip-element tsap-addr=10.10.10.1; target-state=<INS | OOS>;


control sip-server-group id=PROXY-FARM; target-state=<INS | OOS>;

When a server group is set administratively OOS, this server group and all SIP elements linked to it are not available for use even if these SIP elements are administratively and/or operationally INS. If a SIP element that is INS is linked under two different server groups, and one server group is administratively OOS, the SIP element is still available for use by the server group that is INS'.

An administrator may wish to set just an individual SIP element administratively OOS. When this is set, the SIP element is not available for use under any server group it is linked to. When a server group is selected to send a SIP message, SIP elements in the server group are available for selection except those that are administratively or operationally OOS.

Switching a server group or SIP element administrative state from INS to OOS is handled as a graceful shutdown. This means that current SIP calls remain active until they clear on their own. The BTS 10200 continues to send in-dialog requests such as RE-INVITE and BYE and response retransmissions. Subsequent SIP calls using server groups will not have these server groups or SIP elements available for selection. If these elements are the only ones possible for selection, the call is failed towards the originator.

When the administrative state of a SIP element is set OOS, it gracefully stops SIP call traffic sent from the BTS 10200 SIP interface towards the associated remote SIP endpoint. However, this also forces status monitoring to be internally disabled for that SIP element. This will immediately stop the issue of any SIP OPTIONS requests from the BTS 10200 SIP interface if the status monitoring feature was provisioned enabled.

Troubleshooting with Alarm Reports

Use the information in this section to help with troubleshooting procedures.

The specific fields for each signaling event and alarm are listed in the Cisco BTS 10200 Softswitch Troubleshooting Guide.

Signaling Alarm 162

The signaling alarm 162 is raised when a SIP element goes operationally OOS. The alarm is cleared when the SIP element goes operationally back INS. The SIP element goes OOS for one of two reasons:

•A SIP request sent using this element incurred a retransmission timeout.

•A SIP request sent using this element returned a SIP response with a Retry-After header indicating transient congestion for a given duration.

Alarm information contains the identification of the SIP element (the TSAP address field), and the reason why it is operationally OOS, either because of timeout or transient congestion.

The operational state and administrative state of a SIP element operate independently of each other. While the SIP trunk administrative state is OOS, the 162 alarm is never raised on this element regardless of operational state. The alarm might clear while its administrative state is OOS.

Signaling Alarm 142

The signaling alarm 142 is raised when a SIP trunk group goes operationally OOS. The alarm is cleared when the SIP trunk group goes operationally back INS.

If the SIP trunk group is provisioned with a single SIP element in the TSAP-ADDR address field, the SIP trunk operational state will follow the SIP element operational state. If a SIP trunk is provisioned with a server group, all SIP elements in that server group (and in sub-groups of this group) must all be operationally OOS for the 142 alarm to be issued for the trunk. If at least one SIP element in the server group (or sub-groups) becomes operationally INS, the 142 alarm is cleared.

Alarm information contains the identifier of the SIP element or server group provisioned for the trunk.

The operational state and administrative state of a SIP trunk group operate independently of each other. While the SIP trunk administrative state is OOS, the 142 alarm is never raised on this trunk regardless of operational state. The alarm might clear while its administrative state is OOS.

SIP Trunk Group States

A SIP trunk group references either a SIP element or a server-group (collection of SIP elements). A reference for a SIP trunk group is said to be available, if the SIP trunk group is both administratively and operationally INS.

When a SIP trunk group is initially added, the administrative status is OOS. Once the references become available, the operational state becomes INS (see Figure 3-4). You can control the administrative status of the trunk group, once the operational state becomes INS. If the references are not available, due to a negative event in one of the SIP elements of the trunk group, the operational state remains in OOS. For server-groups, at least one SIP element must be available for the collection to be available.

Figure 3-4 SIP Trunk Group States

Internal SIP Audit

The internal audits check the resources for call processing and call registration, and help to maintain those resources. There are two types of auditing:

•Periodic audit (hourly)—If a call is connected to a remote endpoint (such as a trunk) and terminates abnormally, or if call connectivity is lost, the BTS 10200 recovers the resources on a periodic basis (approximately every 1 to 2 hours) by running an audit. During the audit, if no signalling has occurred on a call for more than an hour, the system checks the liveness of the call by sending a re-INVITE or an UPDATE message to the SIP parties in the call.

•Scheduled audit (daily)—The scheduled audit runs daily, and checks any contacts registered with SIP subscribers to ensure that they have been refreshed. The SIP phone subscriber registry is expected to refresh regularly; however, if it is not, the BTS 10200 runs a scheduled audit once a day to reclaim stale resources associated with those registrations.

Note The feature requires no provisioning; use the audit default values. If you do want to change the values, consult with your Cisco representative before doing so.

SIP Element Audit

The SIP element audit mechanism verifies an element's operational status on a periodic basis. The audit mechanism is also triggered if communication problems are detected for the element.

The feature is enabled through the STATUS-MONITORING parameter in the sip-element table. The number of failures needed to classify an element as operationally out of service (OOS) is configured through the AUDIT-THRESHOLD parameter in the sip-element table, and the quiet interval before an audit is launched is controlled by the TRUNK-AUDIT-INTERVAL in the CA-CONFIG table.

When not explicitly configured, the default values are as follows:

•STATUS-MONITORING flag (Y)

•AUDIT-THRESHOLD (3)

•TRUNK-AUDIT-INTERVAL (3 minutes)

The audit mechanism utilizes the SIP protocol. The SIP OPTIONS method, with a Max_Forwards header value of 1, detects whether a remote SIP end device is reachable. The response that the OPTIONS receives from the remote device might be an error message, but as long as a response is received, the element is deemed operationally in service (oper-INS).

An element is deemed operationally in service when any of the following occurs:

1. An initial INVITE message is received for the element.

2. A final response is received for an initial INVITE request that was sent to the element.

3. A final response is received for a SIP OPTIONS message sent to the element.

The first item, above restricts messages to initial INVITEs because RE-INVITEs may be sent directly to the BTS 10200 from an end-point proxied by a trunk. In the second item, unless the trunk end-point performs a Record-Route, responses to mid-dialog requests are sent directly from the remote user agent client (UAC), when the trunk is playing a proxy role. If the trunk is playing the role of a back-to-back user agent, every response indicates that the trunk is in service (INS). Because the role of the trunk is unknown, the restriction above is applied. In this way, the BTS 10200 monitors the next adjacent hop.

An element is marked operationally out of service (oper-OOS) when any of the following occurs:

1. An OPTIONS request sent for the purpose of audit yields no response (assuming the trunk is not provisioned SRV).

In this case, the OPTIONS message was transmitted to the hosts that the trunk's TSAP resolved to 11 times in 32 seconds. There are probably only a few hosts, and the message was transmitted more than once to each host, which is enough for the trunk to be considered out of service.

SRV trunks are excluded from this because SRV potentially translates to more than 11 hosts, so a single OPTIONS message is not sufficient for the trunk to be considered out of service.

2. A communication failure increments the count of such failures over a provisioned AUDIT-THRESHOLD in the sip-element table. Possible communication failures include:

•A transport-level send failure (over UDP or TCP) for an initial INVITE, CANCEL of an initial INVITE, ACK of a failure response to an initial INVITE, or an OPTIONS sent to audit the element. This includes DNS resolution failures.

•A timeout on an initial INVITE, CANCEL of an initial INVITE, or OPTIONS.

•No ACK received for a failure response sent to an initial INVITE that was received.

A SIP trunk's operational state is maintained in the trunk-group record and is based on communication between the BTS 10200 and the trunk. The trunk is monitored only when status-monitoring is enabled, through provisioning, on the sip-element record, and if the trunk is administratively in service.

When status-monitoring is turned on and the trunk is administratively in service, the BTS 10200 sends an OPTIONS message periodically on the trunk if it is operationally out of service, or has had a long quiet period while in service. When status-monitoring is turned off, an operationally out of service trunk is brought back into service only by the reception of a message on the trunk, or by the use of the command line interface (CLI) Control command to first put it administratively out of service and then put it back administratively in service.

The SIP element audit facilitates the route-advance function of the BTS 10200. When a SIP trunk is marked operationally OOS by the audit feature, a route advance is automatically performed for subsequent calls by the BTS 10200, provided that there are additional routes provisioned to the called party.

Audit Occurrence

If an element is both administratively INS and STATUS-MONITORING=Y in the sip-element table, an audit occurs under the following conditions:

•A communication error is reported on the trunk; for example, a request out a trunk yields no response, or a final error response to an INVITE sent on the trunk yields no ACK, and the number of failures has reached the provisioned threshold. The provisioned threshold is the AUDIT-THRESHOLD parameter in the sip-element table.

•No communication has occurred on the sip-element for the provisioned TRUNK-AUDIT-INTERVAL, specified in minutes, in the ca-config table.

•A previous audit failed to establish communication with the SIP element in the network.

Provisioning

When you are provisioning the Trunk Group audit mechanism, we recommend that you provision only the STATUS-MONITORING flag in the sip-element table.

The following fields should be left at the default settings:

•In the sip-element table, AUDIT-THRESHOLD

•In the ca-config table, TRUNK-AUDIT-INTERVAL

Alarms

The SIGNALLING (142) alarm, SIP Softswitch Trunk Out Of Service, is defined for the SIP element audit feature. The alarm is issued for one of two reasons:

1. The Cisco BTS 10200 is unable to communicate with a remote SIP party (Call-Agent or Proxy) over a SIP or SIP-T trunk.

2. A remote SIP party is not operational.

When the alarm is issued for the first reason and the TSAP address of the remote entity is a domain name, the BTS 10200 verifies that the DNS resolution exists. The BTS 10200 verifies that the remote entity is reachable by ICMP ping, using the Trunk TSAP address from the event report.

If the same alarm is reported on all Softswitch trunk groups, the BTS 10200 verifies that the network connection is operational.

If the remote SIP party is not operational and the ping is not successful, the BTS 10200 diagnoses the issue that prevents the TSAP address from being reached. It then verifies that the SIP application is running on the remote host and listening on the port specified in the TSAP address.

For a full list of events and alarms, see the Cisco BTS 10200 Softswitch Troubleshooting Guide.

OPTIONS Message

The following example shows a SIP OPTIONS message sent out to audit the liveness of a SIP trunk. 

OPTIONS sip: vmserver.globalsys.net:11617 SIP/2.0

Via: SIP/2.0/UDP prica20:15000;branch=z9hG4bK_av617_7801

From: <sip:prica20>;tag=1_av617_f11_3429

To: <sip:vmserver.globalsys.net>

Call-ID: 1726021128@prica20

CSeq: 1 OPTIONS

Max-Forwards: 1

Supported: 100rel,precondition,timer

Contact: <sip:prica20:15000>

Content-Length: 0

SIP Triggers

The SIP Triggers feature uses the SIP protocol, with some extensions, to enable the BTS 10200 to provide services from third-party application servers. The triggers can be used by these servers to provide originating services (such as TV caller ID, custom ringback, and voice dial) when a subscriber places a call, and enriched terminating services when a subscriber receives a call.

Note In the initial release of Release 5.0, SIP triggers are provided for MGCP and NCS subscribers only. In Maintenance Release 1 (MR1) of Release 5.0, SIP triggers are also provided for termination attempts to SIP subscribers when the incoming call is based on a directory number (DN).

For information on this feature, including limitations, see the following sections:

•For a description of the basic SIP triggers feature, see the "SIP Triggers" section in the Cisco BTS 10200 Softswitch Network and Subscriber Feature Descriptions document.

•For general SIP trigger provisioning details, see the "SIP Trigger Provisioning" section in the Cisco BTS 10200 Softswitch Provisioning Guide.

Call Redirection

The Call Redirection feature allows a remote SIP endpoint receiving a call from the BTS 10200 to reroute the call at the BTS 10200, using one or more destinations provided by the endpoint. It also supports load sharing and redundancy solutions used by other switches or applications interworking with the BTS 10200 using SIP. These solutions typically involve a front-end SIP network management server that manages load sharing and redundancy for back-end servers.

Call Redirection Process

The BTS 10200 honors the redirection (SIP 300 class) response to a SIP INVITE call request and redirects the call using the specifications outlined in RFC 3261.

When a redirection response is received with multiple contacts, multiple redirections are attempted in series in the order the contacts were received. This includes contacts received in subsequent redirection responses, in which case the contacts are appended to the serial list of redirections being attempted.

The BTS 10200 requires that redirection contacts have a SIP URI format. The user information field of the SIP URI must be present and must contain a phone number and a host name. The following example illustrates the SIP URI format: 


sip:2125553333@phone.cisco.com

Call redirection is not supported on SIP trunks provisioned with a business group. The BTS 10200 does not support an incoming 300 class response from a local BTS 10200 SIP subscriber.

Call redirection is not supported if the call is committed, that is, if the termination is alerting and media has been exchanged. See the "Support for Sending 302 on Call Forwarding" section.

When the BTS 10200 selects a contact from the 300 class redirection response to perform a call redirection, it decides how the redirection is done based on the number and host name in the contact's SIP URI.

•If the host name is the same as the configured SIP contact, the BTS 10200 routes the call using the number in the user portion of the redirected contact URI.

•If this number also matches the called number in the redirected INVITE, the BTS 10200 routes by advancing to the next trunk in the provisioned route set of the originating trunk. This is called "route advance."

•If this number does not match the previously called number, the BTS 10200 determines the next trunk to send the call out by performing routing on the new number based on the dial plan of the terminating trunk. This is called a "reroute."

Note A provisionable parameter (SIP_3XX-REROUTE_ON_LOCAL_DOMAIN in the ca-config table) allows the service provider to force the system to use the reroute method regardless of whether the redirect number matches the number in the initial INVITE. This parameter affects all SIP trunks on the switch.

•If the host name field of the redirection contact selected for call redirection matches the provisioned TSAP address of a provisioned BTS 10200 SIP trunk, the BTS 10200 redirects the call out this trunk without going through the BTS 10200 routing system. The number in the contact is set as the called party number in the Request URI of the redirected INVITE.

•If the host name field does not match the SIP contact of the BTS 10200 or the TSAP address of any of the provisioned SIP trunks, the call is redirected toward the host identified in the contact URI. This contact URI is used as the request URI for the redirected call. The redirected call uses the properties of the SIP trunk in the previous call attempt, and the call does not go through the BTS 10200 routing system. However, if the profile of this SIP trunk restricts redirection to contacts having host names matching only SIP trunks or BTS 10200 contact, redirection is not performed for this contact. This restriction is the default.

•If the diversion feature is enabled for the BTS 10200 SIP trunk selected for call redirection, and the last redirection response received contained diversion headers, these headers are populated in the newly redirected call.

Call Redirection Provisioning

The following command controls the call redirection on all trunks associated with a specified SIP trunk group: 

add softsw-tg-profile id=<profile_id>; redirect-supported=<see list below>;

The allowed values for redirect-supported are as follows:

•valid-domains-only (default)—The trunk accepts redirection contacts only with host names of the BTS 10200 SIP contact, or the TSAP address of any provisioned SIP trunk.

•all-domains—The trunk accepts redirection contacts with any host name. A contact URI is used as the request URI for the redirected call. The redirected call uses the properties of the SIP trunk in the previous call attempt.

•none—Disables call redirection.

The parameters in the following steps are provisioned through the Call Agent Configuration (ca-config) table, and affect all SIP trunks on the switch. Additional details for the ca-config table are provided in Appendix A of the Cisco BTS 10200 Softswitch Call Processing Command Line Interface Reference. Cisco recommends that you leave these values at their default values unless you experience problems with the call redirection feature in your network. In that case, contact Cisco TAC to discuss the values to provision for these parameters.

Caution Provisioning changes in the ca-config table do not take effect until the platform switches over or restarts.

Step 1 If necessary, change the upper limit on the number of 300 class redirection responses the Cisco BTS 10200 Softswitch accepts while performing redirection on any given call attempt;
the default is 1. 

add ca-config type=MAX-3XX-COUNT; datatype=INTEGER; value=2;

Step 2 If necessary, change the upper limit on the maximum number of call redirection attempts the Cisco BTS 10200 Softswitch makes on any given call attempt, after which it releases the call;
the default is 5. 

add ca-config type=MAX-REATTEMPT-COUNT; datatype=INTEGER; value=4;

Step 3 If necessary, set the 3XX reroute parameter for call redirection. 


add ca-config type=SIP-3XX-REROUTE-ON-LOCAL-DOMAIN; datatype=BOOLEAN;  
value=<see list below>;

•N (default)—Does not force the use of reroute. The system performs route advance when the redirection number is the same as the number in the original INVITE.

•Y—Forces the system to perform fresh routing (reroute) using the dial plan of the terminating trunk regardless of whether the redirect number matches the number in the initial INVITE.

Support for Sending 302 on Call Forwarding

The system supports sending the 302 message on call forwarding as described in this section. The SIP response code 302 requests that a call be redirected to a new IP address/phone number.

Sending 302 Feature Description

The following limitations apply to the Sending 302 feature:

•Sending 302 is supported only for Call Forwarding No Answer (CFNA) on SIP trunks.

•CFNA sends 302 if it is the first call forwarding feature invoked after the call is received.

•Relaying SIP 302 is not supported.

•302 tandeming through the BTS 10200 is supported on a limited basis—If both the originating and terminating sides are trunks, the call scenario is CFNA, the terminating side has recv_3xx_use_cf_method set to Y (yes) in the softsw_tg_profile table, and the originating side has send_302_on_cf set to Y, the 302 is passed through.

•Receiving 302 from SIP subscribers is not supported; sending 302 to local SIP subscribers is not supported.

•Receiving multiple contact lists in 302; the BTS 10200 uses the first and ignores the rest.

•Forwarding only the original called number (OCN) and redirecting number (RDN) when the BTS 10200 forwards an INVITE out on a SIP trunk (in-between or middle-hop diversion headers are dropped).

•Sending diversion headers (if enabled) in 302 only for OCN and RDN.

For the BTS 10200 to properly route the call, the 302 must have the following:

•Contact header URL with the host name of the local BTS 10200 SIP interface

•IP address/phone number different than the one initially entered by the calling party

The BTS performs SIP 302 redirection on its POTS Feature Server (FS) as several call forwarding features. When the BTS is the originating switch and it receives a 302, it takes one of the following actions:

•Reroutes the call using a network-based reroute mechanism

•Uses one of its call forwarding mechanisms (BTS default)

BTS implements SIP 302 as the Call Forward Redirection (CFR) feature. CFR does the following:

•Looks for the cause code and redirected number passed from the BTS CA

•Instructs the BTS CA to forward the call

The system provides billing and traffic data for the following call forwarding features on the BTS: