SIP Header Tunneling Support

Table Of Contents

Cisco BTS 10200 Softswitch SIP Header Tunneling Feature Module

Contents

Feature Overview

Unknown Headers, Header Parameters, and User Parameters

Permitted Names and Values

Unknown Header

Unknown-Header Parameter

Known and Supported User and Header-Parameters

Known and Supported Headers

Callflow Scenarios

Unknown Header-Parameter in FROM Header

Unknown Header in SIP INVITE

More than Five Unknown Headers in SIP INVITE

Unknown User-Parameter in FROM Header

Same Unknown User and Header-Parameter in FROM Header

Feature Provisioning

Configuring the Feature

Additional References

Related Documents

Cisco BTS 10200 Softswitch SIP Header Tunneling Feature Module

---

Last Updated: August 10, 2011

The Cisco BTS 10200 Softswitch SIP header tunneling feature enables the BTS 10200 to preserve up to five unknown SIP headers, and one unknown parameter received in each of the TO, FROM, VIA, REQ-URI, and CONTACT header of an incoming request, and tunnel these in the outgoing request.

Contents

•Feature Overview

•Feature Provisioning

•Additional References

Feature Overview

Note This document uses terms such as Back-to-Back User Agent (B2BUA), User Agent Client (UAC), User Agent Server (UAS), and so on. For more information on these terms, see the Cisco BTS 10200 Softswitch SIP User Guide.

The BTS 10200 processes only the first five unknown headers received in a SIP invite. If more than five unknown headers are received, the BTS 10200 saves only the first five and ignores the rest. Additionally, the BTS 10200 saves only one unknown header-parameter or user-parameter received in the REQ-URI, VIA, FROM, TO, and CONTACT headers of a SIP request message.

Unknown Headers, Header Parameters, and User Parameters

As a B2BUA the BTS 10200 performs the functions of a UAC and UAS for a single call. In a call between two SIP endpoints (such as a SIP phone or a SIP trunk), the BTS 10200 ends the originating half of the call, as a UAS, and sets up the terminating half of the call as a UAC. Thereby creating two segments for a single call. As a result of this function, any header, header-parameter, or user-parameter received on one side of the call (or a dialog) in the incoming SIP INVITE is not automatically processed or sent to the other side of the call (in the outgoing SIP INVITE), unless these are required for call processing. Such headers, header-parameters, and user-parameters are considered unknown and are not processed by the BTS 10200. Subsequently, the outgoing message does not contain the received unknown header or user parameter.

The following sections provide some examples of unknown headers, header-parameters, and user-parameters that may be present in a SIP INVITE.

Example:Unknown Header

INVITE sip:5073877777@BTS1.com SIP/2.0

To: sip:5073877777@ BTS1.com 

 FROM: sip:5063866666@ BTS2.com;tag=AParty|

CSeq: 1 INVITE

Via: SIP/2.0/UDP BTS3.com;branch=z9hG4bK_03370245891654

Call-ID: 0696753567856835

Contact: sip:5063866666@BTS1.com

Servprovname: sip:NASDAQ:SERVPRO

Content-Length: 169

Content-Type: application/sdp

v=0

o=- 520 0 IN IP4 192.90.225.30

s=AParty SDP 0

c=IN IP4 192.90.225.30

t=0 0

m=audio 17336 RTP/AVP 8 0 99 100 101 102 103 18

a=rtpmap:99 G.723.1-H/8000/1

The above example contains an unknown header named Servprovname. The BTS 10200 parses and saves the header, and tunnels it is in the outgoing INVITE message.

Example:Unknown Header-Parameter

INVITE sip:5073877777@BTS1.com SIP/2.0

To: sip:5073877777@ BTS1.com 

From: sip:5073877777@sia-SYS12CA146.ipclab.cisco.com; wholesale_tag=12

CSeq: 1 INVITE

Via: SIP/2.0/UDP BTS3.com;branch=z9hG4bK_03370245891654

Call-ID: 0696753567856835

Contact: sip:5063866666@BTS1.com

Content-Length: 169

Content-Type: application/sdp

v=0

o=- 520 0 IN IP4 192.90.225.30

s=AParty SDP 0

c=IN IP4 192.90.225.30

t=0 0

m=audio 17336 RTP/AVP 8 0 99 100 101 102 103 18

a=rtpmap:99 G.723.1-H/8000/1 

The wholesale_tag is an unknown header-parameter in the FROM header. The BTS 10200 parses, saves, encodes this parameter, and tunnels it in the outgoing SIP INVITE message.

Example:Unknown User-Parameter

Invite sip: 5085543216@10.123.14.327SIP/2.0

To: <sip:5085543216@10.123.14.327>

From: <sip:234575126:wholesale_tag=12@10.123.14.327;tag=1928301774\r\n

Call-ID: 015679511947474\r\n

Cseq: 1 INVITE\r\n

Supported: 100rel\r\n

Contact: sip:2345751267@10.78.672.21\r\n

Content-Length: 200\r\n

Content-Type: application/sdp\r\n

The wholesale_tag is an unknown user-parameter in the FROM header of a SIP INVITE message. The BTS 10200 parses, saves, encodes this parameter, and tunnels it in the outgoing SIP INVITE message.

Table 1 lists the specifications for unknown header, header-parameter, and user-parameter for call processing.

Table 1 Unknown header, Header-Parameter, and User-Parameter Specifications

SIP INVITE Field and Parameters	Name Length	Value Length
Unknown header	32 characters (maximum)	255 characters (maximum)
Unknown header-parameter	32 characters (maximum)	255 characters (maximum)
Unknown user-parameter	32 characters per REQ-URI, FROM, TO, and CONTACT header. A maximum of 128 characters in the above mentioned headers.

The BTS 10200 preserves only those unknown headers, unknown header-parameters, and user-parameters that have the above specifications.

Note If an unknown user-parameter or unknown header-parameter contains an "=" symbol after the parameter name, the parameter value must be present, else the call is not processed. Additionally, a user-parameter that exceeds 32 characters per header (with a total length of 128 characters), is also ignored.

Note In the REQ-URI, TO, FROM, and CONTACT headers, both the unknown header-parameter, and unknown user-parameter tunneling are supported. However, in the VIA header, only the unknown header-parameter tunneling is supported.

Permitted Names and Values

The permitted characters in names and values of unknown header, unknown header-parameter, and unknown-user parameter are provided in this section.

Unknown Header

Table 2 lists the permitted characters for unknown header name and its value.

Table 2 Permitted Characters for Unknown Header Names and Value

Unknown Header Syntax	Unknown Header Value Syntax
a-z A-Z 0-9 _ $ - # . + @	ASCII values from 32 to 126

If an unknown header and its value is not compliant with the above syntax, the BTS 10200 does not process the call.

Unknown-Header Parameter

Table 3 lists the permitted characters for an unknown header-parameter name and its value.

Table 3 Permitted Characters for an Unknown Header-Parameter Name and Value

Header Name	Unknown-Header Parameter Name Syntax	Unknown-header Parameter Value Syntax
REQ-URI	a-z A-Z 0-9 [ ] / : & + $ , - _ . ! ~ * ( ) %	a-z A-Z 0-9 / - . ! % * _ + ` ' ~ :
TO	a-z A-Z 0-9 - . ! % * _ + ` ~	a-z A-Z 0-9 / - . ! % * _ + ` ' ~ :
FROM	a-z A-Z 0-9 - . ! % * _ + ` ~	a-z A-Z 0-9 / - . ! % * _ + ` ' ~ :
CONTACT	a-z A-Z 0-9 - . ! % * _ + ` ~	a-z A-Z 0-9 / - . ! % * _ + ` ' ~ :
VIA	a-z A-Z 0-9 - . ! % * _ + ` ~	a-z A-Z 0-9 / - . ! % * _ + ` ' ~ :

Note Literal strings are also allowed in header parameter value. Literal strings are the values that are specified in quotes.

The syntax (permitted characters) for unknown user-parameter is same as for any existing user-parameter in REQ-URI, TO, FROM, CONTACT, and VIA header.

Known and Supported User and Header-Parameters

Table 4 lists the known user and header-parameters that are supported by BTS 10200. These parameters are not tunneled.

The unknown header-parameters are tunneled only when provisioned in the BTS 10200. For information on provisioning the unknown header-parameters, see the "Feature Provisioning" section.

Table 4 Supported SIP Header Parameters

Parameter Name	Description
RN	Req-URI Parameter
NPDI	Req-URI Parameter
CIC	Req-URI Parameter
CT	Req-URI Parameter
NOA	Req-URI Parameter
DAI	Req-URI Parameter
OVERLAP	Req-URI Parameter
TGRP	Req-URI/Contact header Parameter
TRUNK-CONTEXT	Req-URI/Contact header Parameter
BGID	Req-URI Parameter
TGID	Req-URI Parameter
OLI	From / PAID Header URI Parameter
CPC	From / PAID Header URI Parameter
NPI	P-Charge-Info Parameter
NOA	P-Charge-Info Parameter
USER	Privacy Header Parameter
HEADER	Privacy Header Parameter
SESSION	Privacy Header Parameter
ID	Privacy Header Parameter
CRITICAL	Privacy Header Parameter
NONE	Privacy Header Parameter
Q	Accept, Accept-Encoding, Accept-Lang Parameters
USERNAME	Authorization Parameter
REALM	Authorization Parameter
NONCE	Authorization Parameter
QOP	Authorization Parameter
NC	Authorization Parameter
CNONCE	Authorization Parameter
RESPONSE	Authorization Parameter
OPAQUE	Authorization Parameter
ALGORITHM	Authorization Parameter
URI	Authorization Parameter
CNONCE	Authentication-Info Parameter
NC	Authentication-Info Parameter
NEXTNONCE	Authentication-Info Parameter
QOP	Authentication-Info Parameter
RSPAUTH	Authentication-Info Parameter
PURPOSE	Call-Info Header
EXPIRES	Contact Header
HANDLING	Content-Disposition Parameter
ID	Event Header Parameter
REMOTE-TAG	Event Header Parameter
LOCAL-TAG	Event Header Parameter
CALL-ID	Event Header Parameter
ICID-VALUE	P-Charging-Vector Parameter
RKSGROUP	P_DCS_BILLING_INFO
CHARGE	P_DCS_BILLING_INFO
CALLING	P_DCS_BILLING_INFO
CALLED	P_DCS_BILLING_INFO
ROUTING	P_DCS_BILLING_INFO
LOCROUTING	P_DCS_BILLING_INFO
JIP	P_DCS_BILLING_INFO
CONTENT	P_DCS_LAES_PARAM
KEY	P_DCS_LAES_PARAM
BCID	P_DCS_LAES_PARAM
CCCID	P_DCS_LAES_PARAM
REDIRECTOR-URI	P_DCS_REDIRECT Parameter
COUNT	P_DCS_REDIRECT Parameter
CAUSE	Reason header Parameter
TEXT	Reason header Parameter
EXPIRES	Subscription-State Parameter
RETRY-AFTER	Subscription-State Parameter
REASON	Subscription-State Parameter
TAG	TO, FROM Header Parameter
RPORT	Via Header Parameter
BRANCH	Via Header Parameter
MADDR	VIA Header Parameter
LR	Path header Parameter
REFRESHER	SESSION_EXP_PARAMS
REASON	DIVERSION Parameter, Subscription-state Parameter
COUNTER	DIVERSION Parameter
LIMIT	DIVERSION Parameter
PRIVACY	DIVERSION Parameter
TO-TAG	REPLACES Parameter
FROM-TAG	REPLACES Parameter
EARLY-ONLY	REPLACES Parameter
ALGORITHM	WWW-Authenticate Header Parameter
DOMAIN	WWW-Authenticate Header Parameter
NONCE	WWW-Authenticate Header Parameter
OPAQUE	WWW-Authenticate Header Parameter
QOP	WWW-Authenticate Header Parameter
REALM	WWW-Authenticate Header Parameter
STALE	WWW-Authenticate Header Parameter

Known and Supported Headers

The BTS 10200 supports and processes the following headers:

•Accept

•Accept-Contact

•Accept-Encoding

•Accept-Language

•Action

•Alert-Info

•Allow

•Allow-Events

•Authentication-Info

•Authorization

•Boundary

•Call-ID

•Call-Info

•Contact

•Content-Disposition

•Content-Encoding

•Content-Length

•Content-Transfer-Encoding

•Content-Type

•CSeq

•Counter

•Date

•Diversion

•Encryption

•Error-Info

•Event

•Expires

•From

•Hide

•Limit

•Max-Forwards

•MIME-Version

•Min-SE

•P-Asserted-Identity

•P-Charge-Info

•P-Charging-Vector

•P-DCS-OSPS

•P-DCS-Billing-Info

•P-DCS-LAES

•P-DCS-REDIRECT

•Path

•Priority

•Privacy

•Proxy

•Proxy-Authorization

•Rack

•Reason

•Record-Route

•Redirect

•Refer-To

•Referred-By

•Replaces

•Require

•Retry-After

•Response-Key

•Route

•RSeq

•Session-Expires

•Sip-Date

•Subject

•Subscription-State

•Supported

•Timestamp

•To

•Transport

•Unsupported

•Via

•Version

•Warning

•X-Service-Override

Callflow Scenarios

This section depicts how the BTS 10200 processes the unknown headers, unknown header-parameters, and unknown user-parameters in an INVITE message.

The FROM header is taken as an example in the following callflows, which contains unknown header-parameter and user-parameter in the incoming INVITE message.

Unknown Header-Parameter in FROM Header

Figure 1 depicts the callflow where unknown header-parameter is received in the incoming SIP INVITE.

Figure 1 Unknown Header-Parameter in FROM Header

When BTS 10200 receives an unknown header-parameter named wholesale_tag (to indicate that the call is a wholesale call) in the FROM header of an incoming INVITE message, the wholesale_tag parameter is sent to the outgoing SIP trunk, as is. Note that to process any unknown header-parameter, you need to enable the tunneling of unknown header-parameter in BTS 10200.

To provision tunneling of unknown header-parameter in BTS 10200, see the "Feature Provisioning" section.

Unknown Header in SIP INVITE

Figure 2 depicts the callflow where an unknown header is received in the incoming SIP INVITE.

Figure 2 Unknown Header in the INVITE Message

When BTS 10200 receives an unknown header named Servprovname (representing the identity of the cable operator) in the incoming INVITE message, the unknown header is sent to the outgoing SIP trunk as is. Note that to process unknown headers, you need to enable the tunneling of unknown headers in BTS 10200. To provision tunneling of unknown header-parameter in BTS 10200, see the "Feature Provisioning" section.

More than Five Unknown Headers in SIP INVITE

Figure 3 depicts the callflow where an more than five unknown headers are received in the incoming SIP INVITE.

When the BTS 10200 receives an INVITE message with more than five unknown headers, only the first five unknown headers are processed. Out of those five unknown headers, only the provisioned unknown headers are tunneled by the BTS 10200. To provision tunneling of unknown headers in BTS 10200, see the "Feature Provisioning" section.

Figure 3 Five Unknown Headers in the INVITE Message

In the above example, seven unknown headers are received but only the first three headers are tunneled because only those three unknown headers are provisioned in the SIP_TG_HDR_TUNNEL_PROFILE table.

Unknown User-Parameter in FROM Header

Figure 4 depicts the callflow where an unknown user-parameter is received in the FROM header of an incoming SIP INVITE.

Figure 4 Unknown User-Parameter in FROOM Header

When BTS 10200 receives an unknown user-parameter named wholesale_tag (to indicate that the call is a wholesale call) in the user part of the FROM header of the incoming INVITE message, the parameter is tunneled and sent to the outgoing SIP trunk in the same header. Note that to process unknown user-parameter in BTS 10200, you need to enable the tunneling of unknown user-parameter in BTS 10200.

To provision tunneling of unknown user-parameter in BTS 10200, see the "Feature Provisioning" section.

Same Unknown User and Header-Parameter in FROM Header

Figure 5 depicts the callflow where both unknown user-parameter and unknown header-parameter is received in the FROM header of an incoming SIP INVITE. In such scenarios, only the unknown header-parameter is given priority and is tunneled by the BTS 10200. The unknown user-parameter is ignored.

To provision tunneling of unknown user-parameter in BTS 10200, see the "Feature Provisioning" section.

Figure 5 Unknown User and Header Parameter in FROM Header

Feature Provisioning

This section explains the new tokens and tables introduced for the feature and how to provision it.

Note The commands shown in this section are only examples; you need to enter values that are appropriate for your network and service requirements. The CLI syntax allows you to use commands in uppercase or lowercase. It also allows you to enter hyphens (-) or underscores (_) interchangeably. (Exceptions, if any, are noted in the procedures.) For a complete list of tokens for each CLI table, as well as the allowed values, default values, and detailed descriptions for each token, see the Cisco BTS 10200 Softswitch CLI Database at this website: http://www.cisco.com/en/US/docs/voice_ip_comm/bts/6.0.3/BTS603_Mainpage.html

A new table called SIP_TG_HDR_TUNNEL_PROFILE is added in BTS 10200, which allows provisioning the tunneling of unknown SIP headers and unknown parameter per REQ-URI, VIA, FROM, TO, and CONTACT headers.

Table 5 lists the tokens present in the SIP_TG_HDR_TUNNEL_PROFILE table.

Table 5 New Tokens and Descriptions

Token Name	Description
ID	Specifies the unique ID for the SIP unknown headers and user parameter tunneling profile. This is applicable only for softswitch trunk groups with PROTOCOL_TYPE as SIP.
ENABLE_HDR_PARAM_TUNNEL	Controls the tunneling of unknown user or header parameter, which is received in the inbound invite. Unknown parameter tunneling is supported for the parameters present in the REQ-URI, VIA, FROM, TO, and CONTACT headers. The default value of this token is N.
HDR_PARAM_IN_REQ_URI	Specifies the name of the user or header parameter that is present in SIP REQ-URI header, which needs to be tunneled in the outgoing SIP INVITE. To process the parameter specified with this token, set the ENABLE_HDR_PARAM_TUNNEL token to Y.
HDR_PARAM_IN_VIA_HDR	Specifies the name of the header parameter that is present in the SIP VIA header, which needs to be tunneled in the outgoing SIP INVITE. To process the parameter specified with this token, set the ENABLE_HDR_PARAM_TUNNEL token to Y.
HDR_PARAM_IN_FROM_HDR	Specifies the name of the user or header parameter that is present in SIP FROM header, which needs to be tunneled in the outgoing SIP INVITE. To process the parameter specified with this token, set the ENABLE_HDR_PARAM_TUNNEL token to Y.
HDR_PARAM_IN_TO_HDR	Specifies the name of the user or header parameter that is present in SIP TO header, which needs to be tunneled in the outgoing SIP INVITE. To process the parameter specified with this token, set the ENABLE_HDR_PARAM_TUNNEL token to Y.
HDR_PARAM_IN_CONTACT_HDR	Specifies the name of the user or header parameter that is present in SIP CONTACT header, which needs to be tunneled in the outgoing SIP INVITE. To process the parameter specified with this token, set the ENABLE_HDR_PARAM_TUNNEL token to Y.
ENABLE_SIP_HDR_TUNNEL	Controls the tunneling of unknown SIP header received in the inbound INVITE. The default value of this token is N.
SIP_HDR_NAME_1	Specifies the name of the SIP header that needs to be tunnelled from the inbound INVITE to the outbound INVITE. To process the unknown header specified with this token, set the ENABLE_SIP_HDR_TUNNEL token to Y.
SIP_HDR_NAME_2	Specifies the name of the SIP header that needs to be tunnelled from the inbound INVITE to the outbound INVITE. To process the unknown header specified with this token, set the ENABLE_SIP_HDR_TUNNEL token to Y.
SIP_HDR_NAME_3	Specifies the name of the SIP header that needs to be tunnelled from the inbound INVITE to the outbound INVITE. To process the unknown header specified with this token, set the ENABLE_SIP_HDR_TUNNEL token to Y.
SIP_HDR_NAME_4	Specifies the name of the SIP header that needs to be tunnelled from the inbound INVITE to the outbound INVITE. To process the unknown header specified with this token, set the ENABLE_SIP_HDR_TUNNEL token to Y.
SIP_HDR_NAME_5	Specifies the name of the SIP header that needs to be tunnelled from the inbound INVITE to the outbound INVITE. To process the unknown header specified with this token, set the ENABLE_SIP_HDR_TUNNEL token to Y.

Configuring the Feature

This section describes how to configure the feature in BTS 10200.

SUMMARY STEPS

•add sip_tg_hdr_tunnel_profile

•add softsw_tg_profile

•add trunk_grp

DETAILED STEPS

Command	Purpose
add sip_tg_hdr_tunnel_profile id= sip_tunnel; enable_hdr_param_tunnel=Y; hdr_param_in_from_hdr=wholesale_tag; enable_sip_hdr_tunnel=Y; sip_hdr_name_1=servproname;	Enables tunneling of unknown SIP header named servprovname and unknown-header parameter named wholesale_tag in the FROM header.
add softsw_tg_profile ID=Tunneling; PROTOCOL_TYPE=SIP; SIP_TG_HDR_TUNNEL_PROFILE_ID=SIP_TUNNEL;	Configures the softswitch trunk group profile.
add trunk_grp ID = 965; TG_TYPE=SOFTSW; SOFTSW_TSAP_ADDR=sia-SYS92CA146.ipclab.cisco.com; DIAL_PLAN_ID=tb92; TG_PROFILE_ID=Tunneling; POP_ID=tb92; CALL_AGENT_ID=CA146;	Configures the SIP trunk group.

Additional References

Related Documents

Related Topic	Document Title
Summary of features and usage guidelines for this release	Cisco BTS 10200 Softswitch Release Notes
Reference listing of all CLI tables and tokens	Cisco BTS 10200 Softswitch CLI database
SIP Features	Cisco BTS 10200 Softswitch SIP Guide

Cisco and the Cisco Logo are trademarks of Cisco Systems, Inc. and/or its affiliates in the U.S. and other countries. A listing of Cisco's trademarks can be found at www.cisco.com/go/trademarks. Third party trademarks mentioned are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (1005R)

Any Internet Protocol (IP) addresses used in this document are not intended to be actual addresses. Any examples, command display output, and figures included in the document are shown for illustrative purposes only. Any use of actual IP addresses in illustrative content is unintentional and coincidental.

© 2011 Cisco Systems, Inc. All rights reserved.