The table below lists PSTN cause codes and the corresponding SIP event mappings that are set by default. Any code other than the codes listed are mapped by default to 500 Internal server error .

The table below lists the SIP events and the corresponding PSTN cause codes mappings that are set by default.

The feature offers control and flexibility. By using CLI commands, you can easily customize the default or standard mappings that are currently available between PSTN and SIP networks. This allows for flexibility when setting up deployment sites.

Cisco implements this feature on SIP trunking gateways by supporting a new header, Accept-Language, as defined in the Internet Engineering Task Force (IETF) specification, draft-ietf-sip-rfc2543bis-09, SIP: Session Initiation Protocol. The Accept-Language header is used in SIP INVITEs, which establish media sessions between user agents, and in SIP OPTIONS responses, which list user-agent capabilities. The header specifies language preferences for reason phrases, session descriptions, or status responses. A SIP proxy may also use the Accept-Language header to route to a human operator.

The Accept-Language header supports 139 languages, as specified in the International Organization for Standardization (ISO) specification, ISO 639: Codes for Representation of Names of Languages. The SIP Accept-Language Header Support feature allows you to configure up to nine languages to be carried in INVITE messages and OPTIONS responses. This feature also supports the qvalue (q=) parameter, which allows you to indicate multiple language preferences, that is, first choice, second choice, and so on.

The following is a sample outgoing INVITE message for a gateway configured to support the Sindhi, Zulu, and Lingala languages.

11:38:42: Sent:
INVITE sip:36602@172.18.193.120:5060 SIP/2.0
Via: SIP/2.0/UDP  172.18.193.98:5060
From: <sip:172.18.193.98>;tag=27FB000-42E
To: <sip:36602@172.18.193.120>
Date: Mon, 01 Mar 1993 11:38:42 GMT
Call-ID: 23970D87-155011CC-8009E835-18264FDE@172.18.193.98
Supported: timer,100rel
Min-SE:  1800
Cisco-Guid: 0-0-0-0
User-Agent: Cisco-SIPGateway/IOS-12.x
Accept-Language: sd, zu, ln;q=0.123
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, Refer , SUBSCRIBE, NOTIFY, INFO
CSeq: 101 INVITE
Max-Forwards: 10
Remote-Party-ID: <sip:172.18.193.98>;party=calling;screen=no;privacy=off
Timestamp: 730985922
Contact: <sip:172.18.193.98:5060>
Expires: 300
Allow-Events: telephone-event
Content-Type: application/sdp
Content-Length: 322
v=0
o=CiscoSystemsSIP-GW-UserAgent 5606 9265 IN IP4 172.18.193.98
s=SIP Call
c=IN IP4 172.18.193.98
t=0 0
m=audio 16434 RTP/AVP 18 100 101
c=IN IP4 172.18.193.98
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:100 X-NSE/8000
a=fmtp:100 192-194
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:10

The following is a sample OPTIONS response from a gateway configured to support the Yoruba, Sindhi, and English languages.

11:28:44: Received:
OPTIONS sip:36601@172.18.193.98:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP  172.18.193.120:5060
From: "user" <sip:36602@172.18.193.120>
To: <sip:36601@172.18.193.98>
Date: Mon, 01 Mar 1993 02:55:01 GMT
Call-ID: BB8A5738-14EE11CC-8008B310-2C18B10E@172.18.193.120
Accept: application/sdp
CSeq: 110 OPTIONS
Contact: <sip:36601@172.18.193.98:5060>
Content-Length: 0
11:28:44: Sent:
SIP/2.0 200 OK
Via: SIP/2.0/UDP  172.18.193.120:5060
From: "user" <sip:36602@172.18.193.120>
To: <sip:36601@172.18.193.98>;tag=2768F24-1DB2
Date: Mon, 01 Mar 1993 11:28:44 GMT
Call-ID: BB8A5738-14EE11CC-8008B310-2C18B10E@172.18.193.120
Server: Cisco-SIPGateway/IOS-12.x
Content-Type: application/sdp
CSeq: 110 OPTIONS
Supported: 100rel
Accept-Language: yo, sd;q=0.234, en;q=0.123
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, Refer , SUBSCRIBE, NOTIFY, INFO
Accept: application/sdp
Allow-Events: telephone-event
Content-Length: 170
v=0
o=CiscoSystemsSIP-GW-UserAgent 7292 5756 IN IP4 172.18.193.98
s=SIP Call
c=IN IP4 172.18.193.98
t=0 0
m=audio 0 RTP/AVP 18 0 8 4 2 15 3
c=IN IP4 172.18.193.98

Cisco implements this feature on SIP trunking gateways by supporting a header, Remote-Party-ID, as defined in the IETF specification, draft-ietf-privacy-.02.txt, SIP Extensions for Caller Identity and Privacy. The Remote-Part-ID header identifies the calling party and carries presentation and screening information. In previous SIP implementations, the From header was used to indicate calling party identity, and once defined in the initial INVITE request, could not be modified for that session. Implementing the Remote-Part-ID header, which can be modified, added, or removed as a call session is being established, overcomes previous limitations and enables call participant privacy indication, screening, and verification. The feature uses the Remote-Part-ID header to support translation capability between Integrated Services Digital Networks (ISDN) messages and Remote-Party-ID SIP tags. The SIP header also enables support for certain telephony services, and some regulatory and public safety requirements, by providing screening and presentation indicators.

The SIP Extensions for Caller Identity and Privacy feature introduces command-line interface (CLI) commands to enable remote-party-id translations and to configure alternative calling information treatments for calls entering the SIP trunking gateway. Configurable treatment options are:

• Calling name and number pass-through (default).

• No calling name or number sent in the forwarded Setup message.

• Calling name unconditionally set to the configured string in the forwarded Setup message.

• Calling number unconditionally set to the configured string in the forwarded Setup message.

You can configure alternative calling information treatments for calls exiting the SIP trunking gateway. Configurable treatment options are as follows:

• Calling name and number pass-through (default).

• No calling name or number sent in the forwarded INVITE message.

• Display-name of the From header unconditionally set to the configured string in the forwarded INVITE message.

• User part of the From header unconditionally set to the configured string in the forwarded INVITE message.

• Display-name of the Remote-Party-ID header unconditionally set to the configured string in the forwarded INVITE message.

• User part of the Remote-Party-ID header unconditionally set to the configured string in the forwarded INVITE message.

This section discusses the implementation of the Remote-Party-ID feature in a SIP network. Before the implementation of this feature, there was no mechanism to modify the contents of the From header field. With the feature enabled, SIP gateways provide translation capability for ISDN screening and presentation identifiers in call setup messages. SIP gateways and proxy servers require configuration to support Remote-Party-ID feature.

The figure below shows a typical network where the feature is implemented. Gateway C is configured for unscreened discard, that is, if the incoming SIP INVITE request does not contain a screened Remote-Part-ID header (;screen=yes), no calling name or number is sent in the forwarded Setup message.

Note	With respect to privacy and screening indication, it is the responsibility of the proxy server to protect display-name information and enforce privacy policies at the administrative boundary.

The figures in the Inbound and Outbound Call Flows section illustrate various calling information treatment options using the commands available with the feature. Calling information treatment is determined by the parameters specified in the Setup message and Remote-Party-ID configuration on the SIP gateway.

This section presents inbound and outbound call flows for the Remote-Party-ID feature. The figure below shows the SIP-to-PSTN default behavior where the calling party name and number are passed. The feature enables this treatment by default and no configuration is required.

The figure below shows the PSTN-to-SIP default behavior where the calling party name and number are passed. This feature enables this treatment by default and no configuration is required.

The figure below shows the call flow for discarding the calling name and number at Gateway B. The Setup message includes ISDN information elements (IEs) that specify calling information treatment. The INVITE message from Gateway A includes the corresponding Remote-Party-ID SIP tags.

The figure below shows Gateway B overriding the calling name and number received in the Setup message from Gateway A. To configure Gateway B to override calling name and number, use the following commands:

• remote-party-id

• calling-info sip-to-pstn name set name

• calling-info sip-to-pstn number set number

In the figure below the trunking SIP gateway is configured to override the calling name and number of the From header. To configure this call treatment option, use the following commands:

• remote-party-id

• calling-info pstn-to-sip from name set name

• calling-info pstn-to-sip from number set number

The figure below shows translation of OLI or ANI II digits for a billing application. The Remote-Party-ID feature enables this treatment by default; no configuration tasks are required. If the feature was disabled by using the no remote-party-id command, use the remote-party-id command to re-enable the feature.

The next two figures show the SIP trunking gateway capability to provide translation between ISDN screening and presentation identifiers and SIP Remote-Party-ID extensions. The two figures show the difference in call treatment, with and without privacy requested. With no privacy requested, the calling party name and number are passed unchanged.

With privacy requested, as shown in the figure below, screened identity information is still logged in accounting records for billing information, but the user field is not populated in the From header of the outgoing INVITE message, and the display-name is populated with “anonymous.”

The ability to provide marking, screening, and PSTN translation of identity information to and from Remote-Party-ID extensions is supported in SIP INVITE and PSTN messages. This section discusses the formats of SIP INVITE and PSTN messages, and has the following subsections:

• Expands PSTN interoperability

• Supports the ability to override privacy and screening indicators

• Enables network verification and screening of a call participant identity by SIP proxy servers

• Supports logging of screened identity information in accounting records for billing information

• Provides enhanced subscriber information that supports the enabling of service creation platforms and application servers for service providers

• Allows the service provider enhanced control of the ability to identify a subscriber and its qualifications within the network

The initial INVITE request establishes the duration of the session and may include a Session-Expires header and a Min-SE header. These headers indicate the session timer value required by the UAC. A receiving user-agent server (UAS) or proxy can lower the session timer value, but not lower than the value of the Min-SE header. If the session timer duration is lower than the configured minimum, the proxy or UAS can also send out a 422 response message. If the UAS or proxy finds that the session timer value is acceptable, it copies the Session-Expires header into the 2xx class response.

A UAS or proxy can also insert a Session-Expires header in the INVITE if the UAC did not include one. Thus a UAC can receive a Session-Expires header in a response even if none was present in the request.

In the 2xx response, the refresher parameter in the Session-Expires header indicates who performs the re-INVITEs or UPDATE. For example, if the parameter contains the value UAC, the UAC performs the refreshes. For compatibility issues, only one of the two user agents needs to support the session timer feature, and in that case, the user agent that supports the feature performs the refreshes.

Re-INVITEs are processed identically to INVITE requests, but go out in predetermined session intervals. Re-INVITEs carry the new session expiration time. The user agent that is responsible for generating re-INVITE requests sends a re-INVITE out before the session expires. If there is no response, the user agent sends a BYE request to terminate the call before session expiration. If a re-INVITE is not sent before the session expiration, either the UAC or the UAS can send a BYE.

If the 2xx response does not contain a Session-Expires header, there is no session expiration and re-INVITEs do not need to be sent.

The Session-Expires header conveys the session interval for a SIP call. It is placed in an INVITE request and is allowed in any 2xx class response to an INVITE. Its presence indicates that the UAC wishes to use the session timer for this call. Unlike the SIP-Expires header, it can only contain a delta-time, which is the current time, plus the session interval from the response.

For example, if a UAS generates a 200 OK response to a INVITE that contained a Session-Expires header with a value of 90 seconds (1.5 minutes), the UAS computes the session expiration as 1.5 minutes after the time when the 200 OK response was sent. For each proxy, the session expiration is 1.5 minutes after the time when the 2xx was received or sent. For the UAC, the expiration time is 1.5 minutes after the receipt of the final response.

When the gateway acts as an UAS, it is responsible for refreshes. The refresh interval is a minimum of 32 seconds, or one-third the refresh interval. When the gateway act as an UAC, the refresh interval is one-half the refresh interval.

If the session is not refreshed, the minimum time to send a BYE before the session expires is 32 seconds.

The recommended value for the Session-Expires header is 90 seconds.

The syntax of the Session-Expires header is as follows:

Session-Expires  =  ("Session-Expires" | 
"x"
) ":" delta-seconds
                            [refresher]
refresher        =  ";" "refresher" "=" "UAS"|"UAC"

The refresher parameter is optional in the initial INVITE, although the UAC can set it to UAC to indicate that it will do the refreshes. The 200 OK response must have the refresher parameter set.

Because of the processing load of INVITE requests, the proxy, UAC, and UAS can have a configured minimum timer value that they can accept. The min-se (SIP) command sets the minimum timer, and it is conveyed in the Min-SE header in the initial INVITE request.

When making a call, the presence of the Min-SE header informs the UAS and any proxies of the minimum value that the UAC accepts for the session timer duration, in units of delta-seconds. The default value is 90 seconds (1.5 minutes). By not reducing the session interval below the value set, the UAS and proxies prevent the UAC from having to reject a call with a 422 error. Once set, the min-se command value affects all calls originated by the router. If the Min-SE header is not present, the user agent accepts any value.

The syntax of the Min-SE header is:

Min-SE  =  "Min-SE" ":" delta-seconds

If the value of the Session-Expires header is too small, the UAS or proxy rejects the call with a 422 Session Timer Too Small response message. With the 422 response message, the proxy or UAS includes a Min-SE header indicating the minimum session value it can accept. The UAC may then retry the call with a larger session timer value.

If a 422 response message is received after an INVITE request, the UAC can retry the INVITE.

The presence of the timer argument in the Supported header indicates that the user agent supports the SIP session timer. The presence of the timer argument in the Require header indicates that the opposite user agent must support the SIP session timer for the call to be successful.

• This feature provides a periodic refresh of SIP sessions. The periodic refresh allows user agents and proxies to monitor the status of a SIP session, preventing hung network resources when network failures occur.

• Only one of the two user-agent or proxy participants in a call needs to have the SIP Session Timer Support feature implemented. This feature is easily compatible with older SIP networks.

The Reason header facilitates PSTN interworking. This is achieved by having the side receiving a Disconnect message response append a Reason header to the outgoing Bye or Cancel message request and 4xx, 5xx, or 6xx message response, indicating the Q.850 cause code that passed down from the PSTN (see the figure below).

SIP implementations on PSTN gateways are plagued with issues related to mapping ISDN-disconnect message-request cause codes to SIP response status codes, which stem from the mapping on the gateway receiving the disconnect. Specifically, more than one ISDN-disconnect message-request cause code maps to one SIP status code. For example, on SIP gateways, ISDN cause codes 18, 19, and 20 all map to the SIP status code of 480 message response. This makes it impossible to deterministically relay the cause-code value on the remote end. The Reason header can carry the actual cause code (see the figure below).

As shown in the figure below, Cisco IOS SIP has always supported receiving calling-name information in the display information element (IE) of a Setup message request. Support for receiving calling-name information in the facility IE of a Setup message request, of a Facility message request, and of a NOTIFY message request were supported through the Support for the ISDN Calling Name Display feature in release 12.3(4)T (refer to the “Configuring SIP DTMF Features” chapter).

The Buffered Calling Name Completion feature adds support for buffering the INVITE message request when the calling-name information is going to arrive in a subsequent facility IE of a Facility message request.

When an originating gateway (OGW) receives a Setup message with an indication that calling-name information is enabled, the configuration is checked for INVITE-message display-name buffering. When buffering is enabled, the INVITE message is buffered until the time specified in the configuration. If a Facility message with display information in the From and Remote Party ID headers of the INVITE message is received, then send it out. If no Facility message is received in the specified time, send out only the INVITE message.

Prior to the implementation of this feature, voice applications running on the gateway did not have access to headers sent in SIP requests. The SIP Header Passing feature makes SIP headers, the fields which specify session details in SIP messages, available to applications. This feature supports the following capabilities for VoiceXML and Tcl IVR 2.0 applications:

• Set SIP headers for outgoing SIP INVITE messages.

• Obtain information about SIP headers for incoming calls and create session variables to access the headers in VoiceXML document or Tcl IVR 2.0 script.

• Set and obtain extended and non-standard headers (user-defined header attribute-value pairs)

Using headers in SIP INVITE messages, voice applications can pass information about a call to an application on another server. For example, if the caller has entered an account number and the application transfers the call to another application on another platform, the account number can be passed in a SIP Header. An example scenario is an airline application transferring the call to a hotel reservation application hosted at a different service provider. This feature enables the respective sites to share context information about the caller.

This feature introduces a new command, the header-passing command, to either enable or disable passing headers from INVITE messages to applications.

The SIP Header Passing feature also provides enhanced inbound and outbound dial-peer matching services.

This feature implements support for two SIP methods, SUBSCRIBE and NOTIFY, and for a new Event header, as defined in the IETF draft, draft-roach-sip-subscribe-notify-02.txt, Event Notification in SIP.

The Cisco IOS gateway accepts in dialog the SUBSCRIBE message requests with the same Call-Id and tags (to and from) for out-of-band (OOB) DTMF for Event header: telephone event. There can be an ID parameter in it, but the gateway supports in-dialog subscription for only one event. After the subscription is accepted, an initial NOTIFY message request is sent and includes a Subscription-State header as per RFC 3265.

When a digit is pressed on the PSTN end, the digit event is sent in the NOTIFY message requests. The Subscription-State header in these requests is active.

When the subscription expires before it is refreshed, the gateway terminates it by sending a NOTIFY message request with a Subscription-State header value set to terminated. The subscriber can always refresh the subscription by sending another SUBSCRIBE message request with the same Call-Id and tags as in the initial SUBSCRIBE message request.

If the INVITE message request dialog is terminated before the subscription expires, the subscription is terminated by sending a NOTIFY message request with a Subscription-State header value set to terminated. The gateway does not support generating in-dialog SUBSCRIBE message request.

The Skinny Client Control Protocol (SCCP) IP phones do not support in-band DTMF digits; they are capable of sending only out-of-band DTMF digits. To support SCCP devices, originating and terminating SIP gateways can use Cisco-proprietary NOTIFY-based out-of-band DTMF relay. In addition, NOTIFY-based out-of-band DTMF relay can also be used by analog phones attached to analog voice ports (FXS) on the router.

NOTIFY-based out-of-band DTMF relay sends messages bidirectionally between the originating and terminating gateways for a DTMF event during a call. If multiple DTMF relay mechanisms are enabled on a SIP dial peer and are negotiated successfully, NOTIFY-based out-of-band DTMF relay takes precedence.

The originating gateway sends an INVITE message with a SIP Call-Info header to indicate the use of NOTIFY-based out-of-band DTMF relay. The terminating gateway acknowledges the message with an 18x or 200 Response message, also using the Call-Info header. The Call-Info header for NOTIFY-based out-of-band relay appears as follows:

Call-Info: <sip: address>; method="NOTIFY;Event=telephone-event;Duration=msec"

Note	Duration is the interval between NOTIFY messages sent for a single digit and is set by means of the notify telephone-event command.

The NOTIFY-based out-of-band DTMF relay mechanism is negotiated by the SIP INVITE and 18x/200 Response messages. Then, when a DTMF event occurs, the gateway sends a SIP NOTIFY message for that event. In response, the gateway expects to receive a 200 OK message.

The NOTIFY-based out-of-band DTMF relay mechanism is similar to the DTMF message format described in RFC 2833. NOTIFY-based out-of-band DTMF relay consists of 4 bytes in a binary encoded format. The message format is shown in the figure below; the table below describes the fields.

This feature provides implementation on the gateway with suitable enhancements to the common stack to support quality of service (QoS) RSVP calls adhering to RFC 3312. This feature changes the existing implementation and follows RFC 3312 to provide QoS services using RSVP.

The Achieving SIP RFC Compliance feature enhances SIP gateway compliance for RFCs 3261, 3262, and 3264. This feature inherits these enhancements for the portable stack. Refer to the “Achieving SIP RFC Compliance” chapter for a description of introduced enhancements.

The portable stack handles redirections (3xx or 485 message responses) internally. When a 3xx or 485 class message response is received by the SIP stack, the stack sends out a new INVITE message request to the contact in the 3xx message response, without notification to the application. In this feature, the functionality is opened up to the application. Upon receipt of a 3xx or 485 message response the application has the ability to take over the redirect response. When the application decides to handle the redirect, the SIP stack disconnects the original call that the 3xx or 485 message response received, and the application takes over responsibilities for setting up the new call.

This feature upgrades the Diversion header draft implementation to the draft-levy-diversion-06.txt version. This upgrade adds the capability to send or receive two new parameters in the Diversion header. The stack adds two new fields to set or pass this information to and from the application.

Note	The draft-levy-diversion-06.txt version has since expired. Current standard uses History-Info header (refer to RFC 4244 , An Extension to the Session Initiation Protocol (SIP) for Request History Information .

Call active and history VoIP records present the local hostname. They have the following format:

#show call active voice
VOIP:
LocalHostname=example.com

These records are generated for calls created in the context of the INVITE message request.

The CLI affects the host portion of the following SIP headers generated for an outbound VoIP call from the SIP gateway:

• Call-ID--The Call-ID header in the SIP messages has an existing format of unique-string@ipaddr. With the CLI, the Call-ID has a value in the form of unique-string@localhostname or unique-string@domain-name. The dialog initiating the SIP requests that are affected namely are the INVITE and SUBSCRIBE message requests.

• From--The From header in the following dialog initiating requests. The INVITE and SUBSCRIBE message requests originating from the gateway have host or domain name in the host portion of the SIP URI. When the CLI is configured, the Remote-Party-ID header also has a hostname in the host portion of the SIP URI. The Remote-Party-ID header is sent out in the INVITE and INFO message requests from the gateway.

Other SIP headers such as Contact and Via are not affected by configuring the new CLI. Those headers continue to have IP addresses even when the CLI is configured.

These changes do not affect the Session Definition Protocol (SDP).

SIP headers that are provided by the application to SIP via header passing mechanisms always override headers generated by SIP.

This section contains the following sample SIP header messages with the SIP: Domain Name Support in SIP Headers feature disabled and enabled:

Sent:
INVITE sip:9002@example.sip.com:5060 SIP/2.0
Via:SIP/2.0/TCP 172.18.195.49;branch=z9hG4bK597
Remote-Party-ID:<sip:9001@172.18.195.49>;party=calling;screen=no;privacy=off
From:<sip:9001@172.18.195.49>;tag=3AA7574-11BA
To:<sip:9002@example.sip.com>
Date:Tue, 31 Aug 2004 13:40:57 GMT
Call-ID:3924408D-FA8A11D8-80208D32-72E3122E@172.18.195.49
Supported:100rel,timer,resource-priority
Min-SE:1800
Cisco-Guid:940277299-4203352536-2149420338-1927483950
User-Agent:Cisco-SIPGateway/IOS-12.x
Allow:INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, Refer , SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq:101 INVITE
Max-Forwards:70
Timestamp:1093959657
Contact:<sip:9001@172.18.195.49:5060;transport=tcp>
Expires:180
Allow-Events:telephone-event
Content-Type:multipart/mixed;boundary=uniqueBoundary
Mime-Version:1.0
Content-Length:418
--uniqueBoundary
Content-Type:application/sdp
Content-Disposition:session;handling=required
v=0
o=CiscoSystemsSIP-GW-UserAgent 4780 5715 IN IP4 172.18.195.49
s=SIP Call
c=IN IP4 172.18.195.49
t=0 0
m=audio 18336 RTP/AVP 18 101 19
c=IN IP4 172.18.195.49
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20
--uniqueBoundary--

Sent:
INVITE sip:9002@example.sip.com:5060 SIP/2.0
Via:SIP/2.0/TCP 172.18.195.49;branch=z9hG4bK22C7
Remote-Party-ID:<sip:9001@gw11.example.com>;party=calling;screen=no;privacy=off
From:<sip:9001@gw11.example.com>;tag=39CF740-FFC
To:<sip:9002@example.sip.com>
Date:Tue, 31 Aug 2004 13:26:13 GMT
Call-ID:2A101AD3-FA8811D8-801C8D32-72E3122E@gw11.example.com
Supported:100rel,timer,resource-priority
Min-SE:1800
Cisco-Guid:686218050-4203221464-2149158194-1927483950
User-Agent:Cisco-SIPGateway/IOS-12.x
Allow:INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, Refer , SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq:101 INVITE
Max-Forwards:70
Timestamp:1093958773
Contact:<sip:9001@172.18.195.49:5060;transport=tcp>
Expires:180
Allow-Events:telephone-event
Content-Type:multipart/mixed;boundary=uniqueBoundary
Mime-Version:1.0
Content-Length:418
--uniqueBoundary
Content-Type:application/sdp
Content-Disposition:session;handling=required
v=0
o=CiscoSystemsSIP-GW-UserAgent 5250 7833 IN IP4 172.18.195.49
s=SIP Call
c=IN IP4 172.18.195.49
t=0 0
m=audio 18998 RTP/AVP 18 101 19
c=IN IP4 172.18.195.49
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:19 CN/8000
a=ptime:20
--uniqueBoundary--

The SDP Session Information line can exist multiple times within a session description. The line, represented by “i=” in the SDP, can be present at the session-level as well as the media-level. You can have only one session description per packet. The session description contains one session-level, but can have multiple media-levels.

The following is a sample SDP description. The highlighted lines represent the updates to reflect RFC 2327:

v=0
o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4
s=SDP Seminar
i=A Seminar on the session description protocol
u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps
e=mjh@isi.edu (Mark Handley)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 0
i=media-information 1
m=video 51372 RTP/AVP 31
i=media-information 2
m=application 32416 udp wb
a=orient:portrait

The session information is optional, therefore internal structures are not built to expect this parameter. Specifically, internal memory is only allocated for this parameter when it is present in SDP, or when the application specifies that it be built into an outgoing message. In order to protect the internal operation of the Cisco IOS gateway, the maximum allowable length of a received session information line is 1000 characters. Session information lines over 1000 characters are truncated.

While the RFC detailing SDP indicates to only expect one session information line at the appropriate level, the Cisco IOS gateway will not “drop” the SDP in the event that this rule is violated. In the event that multiple “i=” lines are received at a particular level, the first parsed line that contains data is stored. All subsequent lines for that level are dropped.

Beginning with Cisco IOS Software Release 12.4(9)T, administrators can validate hostnames of incoming initial INVITE messages. When the gateway processes an initial INVITE, a determination is made whether or not the host portion is in ipv4 format or a domain name.

If the host portion is an IP address, its IP address is compared with the interfaces on the gateway. If a match is found, the INVITE is processed as normal. If there is not a match, the gateway sends a 400 Bad Request - ‘Invalid IP Address’ message.

If the initial INVITE has a domain name in the host of the request URI, the gateway checks this domain name against a list of configured hostnames. If you configure no hostnames, existing behavior executes and the INVITE is processed. If you configure hostnames for this gateway, the gateway compares the host name in the request URI to the configured hostname list. If a match is found, the INVITE is processed as normal. If there is not a match, the gateway sends a 400 Bad Request - ‘Invalid host’ message.

You can configure up to 10 hostnames by re-entering the permit hostname dns command. Use the no form of this command to remove any configured hostnames.

The following example shows a configured list of hostnames. The highlighted lines represent the updates to reflect RFC 2327.

sip-ua
retry invite 1
registrar ipv4:172.18.193.97 expires 3600
permit hostname dns:sinise.sip.com
permit hostname dns:liotta.sip.com
permit hostname dns:sipgw.sip.com
permit hostname dns:yourgw.sip.com
permit hostname dns:csps.sip.com
!

The following example shows an initial INVITE message with a hostname. The highlighted line represents the updates to reflect RFC 2327.

INVITE sip:777@sinise.sip.com;user=phone SIP/2.0
Via: SIP/2.0/UDP 172.18.201.173:5060;branch=z9hG4bK2C419
To: <sip:777@172.18.197.154>
From: <sip:333@64.102.17.246>;tag=B87C0-B65
Date: Thu, 23 Feb 2006 16:49:26 GMT
Call-ID: 4EAF670B-A3C311DA-80148B65-6E225A8E@172.18.197.154
Contact: <sip:333@172.18.201.173>
Supported: 100rel, eatit
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, Refer, SUBSCRIBE, NOTIFY, INFO
Max-Forwards: 70
Cseq: 104 INVITE
Expires: 60
Timestamp: 730947404
Content-Length: 211
Content-Type: application/sdp
^M
v=0
o=CiscoSystemsSIP-GW-UserAgent 6109 4520 IN IP4 172.18.201.173
s=SIP Call
c=IN IP4 111.11.111.111
t=0 0
m=audio 16880 RTP/AVP 0 19
c=IN IP4 111.11.111.111
a=rtpmap:0 PCMU/8000
a=rtpmap:19 CN/8000
a=ptime:20

Cisco implements SIP History-Info Header Support on SIP TDM gateways and SIP-SIP Cisco UBEs by supporting the history-info header, as defined in RFC 4244 , An Extension to the Session Initiation Protocol (SIP) for Request History Information. The history-info header forms part of the SIP INVITE messages that establish media sessions between user agents, and the subsequent responses to the INVITE messages.

Support for history-info headers on a gateway is enabled using the history-info command. The system supports multiple history-info headers ( maximum of nine) for a single INVITE message. The headers are contained in a comma-separated list.

When you configure the privacy command to use one of the header values shown in the table above, then the gateway’s outgoing message request contains a privacy header set to the corresponding privacy value. The following example shows the format of the “From” header, if you configure the privacy command, based on RFC 3323:

From: “Anonymous” <sip:anonymous@anonymous.invalid>; tag=<tag value>

If you configure the privacy critical command, the gateway adds a Proxy-Require header with the value set to critical. Thus, in the unlikely event that the user agent sends a request to an intermediary that does not support the described extension, the request will fail.

If you configure the asserted-id pai command, the gateway builds a PAI into the common SIP stack. The asserted-id pai command has priority over the Remote-Party-ID (RPID) header and removes this header from any outbound message even if the router is configured to use the RPID header.

If you configure the asserted-id ppi command, the gateway builds a PPI into the common SIP stack. The asserted-id ppi command has priority over the Remote-Party-ID (RPID) header and removes this header from any outbound message even if the router is configured to use the RPID header.

You can use the privacy pstn command to derive information passed in from the PSTN Octet 3a of the CALLING PARTY Information Element to enable privacy information on the VoIP side of the call. The data within the CALLING PARTY field indicates whether or not you want to relay calling information. The CALLING PARTY field also supplies information and details about who supplied the information, and whether or not the information has been verified.

The table below summarizes the relationship between the ISDN Octet 3a values and the SIP-header values that the UAC gateway generates, when you configure the privacy pstn command.

When you configure the privacy pstn command, on the UAC gateway side of the call, after configuring the substitute name command under the clid (voice-service-voip) command and defining no “Display Name” parameter, then the PAI or PPI substitutes the calling number in the Display field.

The following example show a PAI header when the substitute name command is not set:

P-Asserted_Identity: <sip:5551212@example.com>

If you set the substitute name command, the header in the example is modified:

P-Asserted_Identity: “5551212” <sip:5551212@example.com>

When you configure the privacy pstn command, after configuring the strip pi-restrict all command under the clid (voice-service-voip) command, and if the CALLING INFORMATION Octet 3a indicates that the number is restricted, then the PAI/PPI value is not sent.

On the UAS gateway side of the call, if you configure the clid network-provided command, it will override any value you set by using the privacy command. If you configure the clid network-provided command and a PPI is received, the number in the Octet 3a is set to “Network Provided.” If you do not configure the clid network-provided command, the number in the Octet 3a is set to “User Provided.”

If you configure the calling-info pstn-to-sip unscreened discard command and the privacy pstn command, and if the calling number has a screening indicator of “User-provided, not screened,” or “User-provided, failed screen” the PAI/PPI is not sent.

The table below summarizes the interaction when you configure the privacy pstn command.

You can configure the hostname in either of two configuration modes:

Note	Dial-peer-specific configuration takes precedence over more general gateway-wide configuration.