Table Of Contents
Configuring SIP Message, Timer, and Response Features
Prerequisites for SIP Message, Timer, and Response Features
Restrictions for SIP Message, Timer, and Response Features
Information About SIP Message Components, Session Timers, and Response Features
Internal Cause Code Consistency Between SIP and H.323
SIP - Configurable PSTN Cause Code Mapping
Benefits of SIP - Configurable PSTN Cause Code Mapping
SIP: Accept-Language Header Support
Feature Design of SIP Accept-Language Header Support
SIP Enhanced 180 Provisional Response Handling
SIP Extensions for Caller Identity and Privacy
Privacy, Screening, and Presentation Indicators
Remote-Party-ID Implementation
Inbound and Outbound Call Flows
Remote-Party-ID in SIP and PSTN Messages
Benefits of SIP Extensions for Caller Identity and Privacy
SIP INVITE Request with Malformed Via Header
Benefits of SIP Session Timer Support
SIP: Cisco IOS Gateway Reason Header and Buffered Calling Name Completion
Buffered Calling-Name Completion
SIP: SIP Header/URL Support and SUBSCRIBE/NOTIFY for External Triggers
Feature Design of SIP Header Support
Feature Design of SIP SUBSCRIBE and NOTIFY for External Triggers
SIP Call Transfer and Call Forwarding Using Tcl IVR 2.0 and VoiceXML Applications
SUBSCRIBE or NOTIFY Message Request Support
SIP NOTIFY-Based Out-of-Band DTMF Relay
Support for the Achieving SIP RFC Compliance Feature
Diversion Header Draft 06 Compliance
SIP: Domain Name Support in SIP Headers
SIP Gateway Support for SDP Session Information and Permit Hostname CLI
SDP Changes for Session Information Line
Validating Hostname in Initial INVITE Request URI
Outbound Proxy Support for the SIP Gateway
SIP: History-info Header Support
Feature Design of SIP History-info Header Support
How to Configure SIP Message, Timer, and Response Features
Configuring Internal Cause Code Consistency Between SIP and H.323
Configure Internal Cause Code Consistency Between SIP and H.323
Configuring SIP - Configurable PSTN Cause Code Mapping
Map PSTN Codes to SIP Status Codes
Map SIP Status Codes to PSTN Cause Codes
Configuring SIP Accept-Language Header Support
Configuring SIP Enhanced 180 Provisional Response Handling
Configuring SIP Extensions for Caller Identity and Privacy
Configure SIP-to-PSTN Calling-Info Policy
Configure PSTN-to-SIP Calling-Info Policy
Configuring SIP INVITE Request with Malformed Via Header
Privacy Header PSTN with UAC Gateway
Privacy Header PSTN with UAS Gateway
Interaction with Caller ID When Privacy Exists
Configuring SIP Session Timer Support
Configuring SIP: Cisco IOS Gateway Reason Header and Buffered Calling Name Completion
Configure Reason-Header Override
Configure Buffer Calling-Name Completion
Configuring SIP: SIP Header/URL Support and SUBSCRIBE/NOTIFY for External Triggers
Configure SIP SUBSCRIBE and NOTIFY for External Triggers
Configuring SIP Stack Portability
Configuring SIP: Domain Name Support in SIP Headers
Configure the Hostname in Locally Generated SIP Headers
Monitor the Hostname in Locally Generated SIP Headers
Configuring SIP Gateway Support for Session Information
Configuring SIP Gateway Support for Permit Hostname CLI
Configuring Outbound Proxy Support for the SIP Gateway
Configuring an Outbound-Proxy Server Globally on a Gateway
Configuring an Outbound-Proxy Server on a Dial Peer
Configuring SIP Support for PAI
Configuring a Name and Number in the asserted-id Header
Configuring SIP History-info Header Support
Configuring SIP History-info Header Support Globally
Configuring SIP History-info Header Support at the Dial-Peer Level
Verifying SIP Message Components, Session Timers, and Responses Configuration
Troubleshooting Tips for SIP Message, Timer, and Response Features
Configuration Examples for SIP Message, Timer, and Response Features
Internal Cause Code Consistency Between SIP and H.323: Example
SIP - Configurable PSTN Cause Code Mapping: Example
SIP Accept-Language Header Support: Examples
SIP Extensions for Caller Identity and Privacy: Example
SIP Session Timer Support: Example
SIP: Cisco IOS Gateway Reason Header and Buffered Calling Name Completion: Examples
SIP: SIP Header/URL Support and SUBSCRIBE/NOTIFY for External Triggers: Examples
SIP: Domain Name Support in SIP Headers: Examples
SIP Gateway Support for Permit Hostname: Example
Outbound-Proxy Support for the SIP Gateway: Examples
SIP: SIP Support for PAI: Examples
Configuring a Privacy Header: Example
SIP History-Info Header Support: Examples
Configuring SIP Message, Timer, and Response Features
First Published: March 1992Last Updated: October 10, 2008This chapter describes how to configure Session Initiation Protocol (SIP) message components, session timers, and responses. It describes the following features:
•
Internal Cause Code Consistency Between SIP and H.323
•
•
•
•
•
•
•
•
•
•
•
History for the Internal Cause Code Consistency Between SIP and H.323 Feature
History for the SIP - Configurable PSTN Cause Code Mapping Feature
History for the SIP Accept-Language Header Support Feature
History for the SIP Enhanced 180 Provisional Response Handling Feature
History for the SIP Extensions for Caller Identity and Privacy Feature
History for the SIP INVITE Request with Malformed Via Header Feature
12.2(2)XB
This feature was introduced.
12.2(8)T
This feature was integrated into this release.
12.2(11)T
Support was added for additional platforms.
History for the SIP Session Timer Support Feature
12.2(11)T
These features were introduced.
12.4(9)T
This feature was updated to support RFC 4028.
History for the SIP: Cisco IOS Gateway Reason Header and Buffered Calling Name Completion Feature
History for the SIP: SIP Header/URL Support and SUBSCRIBE/NOTIFY for External Triggers Feature
History for the SIP Stack Portability Feature
History for the SIP: Domain Name Support in SIP Headers Feature
History for the SIP Gateway Support for SDP Session Information and Permit Hostname CLI Feature
History for the Outbound Proxy Support for the SIP Gateway
12.4(15)T
This feature was introduced.
12.4(20)T
Support was added for disabling outbound proxy support for SIP on a per dial peer basis
History for the SIP Support for PAI
History for the SIP History-info Header Support Feature
Finding Feature Information
Your software release may not support all the features documented in this module. For the latest feature information and caveats, see the release notes for your platform and software release. To find information about the features documented in this module, and to see a list of the releases in which each feature is supported, see the "Information About SIP Message Components, Session Timers, and Response Features" section.
Use Cisco Feature Navigator to find information about platform support and Cisco IOS, Catalyst OS, and Cisco IOS XE software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn. An account on Cisco.com is not required.
Contents
•
•
•
•
•
Prerequisites for SIP Message, Timer, and Response Features
All SIP Message Components, Session Timers, and Responses Features
•
•
Refer to the following Cisco IOS IP Configuration Guides by navigating to them from the Product Support page (http://www.cisco.com/web/psa/products/index.html?c=268438303) according to your Cisco IOS release):–
–
–
–
•
•
SIP: Cisco IOS Gateway Reason Header and Buffered Calling Name Completion Feature
•
–
•
–
–
•
Restrictions for SIP Message, Timer, and Response Features
All SIP Message Components, Session Timers, and Responses Features
•
SIP Permit Hostname Command Features
•
SIP Accept-Language Header Support Feature
•
SIP Extensions for Caller Identity and Privacy Feature
•
•
SIP INVITE Request with Malformed Via Header Feature
•
SIP Session Timer Support Feature
•
•
•
SIP: SIP Header/URL Support and SUBSCRIBE/NOTIFY for External Triggers Feature
•
–
–
–
–
–
–
–
–
All other headers may be overwritten by the application to create the header lines in the SIP INVITE message.
•
SIP Gateway Support for SDP Session Information Feature
•
SIP: SIP Support for PAI
•
SIP History-info Header Support Feature
•
•
Information About SIP Message Components, Session Timers, and Response Features
This section contains the following information:
•
•
•
•
•
•
•
•
•
•
•
•
•
Internal Cause Code Consistency Between SIP and H.323
The Internal Cause Code Consistency Between SIP and H.323 feature establishes a standard set of categories for internal causes of voice call failures. Before this feature, the cause code that was passed when an internal failure occurred was not standardized or based on any defined rules. The nonstandardization lead to confusing or incorrect cause code information, and possibly contributed to billing errors.
This feature establishes a standard set of categories for internal causes of voice call failures. Internal cause-code consistency enables more efficient and effective operation of combined SIP and H.323 networks, which reduces operational expenses and improves service availability.
Note
H.323 and SIP standard cause codes that are now generated accurately reflect the nature of each internal failure. This capability makes the H.323 and SIP call control protocols consistent with cause codes that are generated for common problems. Also, for each internal failure, an ITU-T Q.850 release cause code is also assigned and Table 1 maps the new standard categories with the Q.850 release cause code and description that is assigned to each category.
SIP - Configurable PSTN Cause Code Mapping
For calls to be established between a SIP network and a PSTN network, the two networks must be able to interoperate. One aspect of their interoperation is the mapping of PSTN cause codes, which indicate reasons for PSTN call failure or completion, to SIP status codes or events. The opposite is also true: SIP status codes or events are mapped to PSTN cause codes. Event mapping tables found in this document show the standard or default mappings between SIP and PSTN.
However, you may want to customize the SIP user-agent software to override the default mappings between the SIP and PSTN networks. The SIP - Configurable PSTN Cause Code Mapping feature allows you to configure specific map settings between the PSTN and SIP networks. Thus, any SIP status code can be mapped to any PSTN cause code, or vice versa.
When set, these settings can be stored in the NVRAM and are restored automatically on bootup.
Default Mappings
Table 2 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.
Table 3 lists the SIP events and the corresponding PSTN cause codes mappings that are set by default.
Benefits of SIP - Configurable PSTN Cause Code Mapping
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.
SIP: Accept-Language Header Support
The SIP Accept-Language Header Support feature introduces support for the Accept-Language header in SIP INVITE messages and in OPTIONS responses. This feature enables you to configure up to nine languages to be carried in SIP messages and to indicate multiple language preferences of first choice, second choice, and so on.
Feature benefits include the following:
•
•
To configure Accept-Language header support, you need to understand the following concepts:
•
Feature Design of SIP Accept-Language Header Support
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.
Sample INVITE Message
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.0Via: SIP/2.0/UDP 172.18.193.98:5060From: <sip:172.18.193.98>;tag=27FB000-42ETo: <sip:36602@172.18.193.120>Date: Mon, 01 Mar 1993 11:38:42 GMTCall-ID: 23970D87-155011CC-8009E835-18264FDE@172.18.193.98Supported: timer,100relMin-SE: 1800Cisco-Guid: 0-0-0-0User-Agent: Cisco-SIPGateway/IOS-12.xAccept-Language: sd, zu, ln;q=0.123Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, Refer , SUBSCRIBE, NOTIFY, INFOCSeq: 101 INVITEMax-Forwards: 10Remote-Party-ID: <sip:172.18.193.98>;party=calling;screen=no;privacy=offTimestamp: 730985922Contact: <sip:172.18.193.98:5060>Expires: 300Allow-Events: telephone-eventContent-Type: application/sdpContent-Length: 322v=0o=CiscoSystemsSIP-GW-UserAgent 5606 9265 IN IP4 172.18.193.98s=SIP Callc=IN IP4 172.18.193.98t=0 0m=audio 16434 RTP/AVP 18 100 101c=IN IP4 172.18.193.98a=rtpmap:18 G729/8000a=fmtp:18 annexb=noa=rtpmap:100 X-NSE/8000a=fmtp:100 192-194a=rtpmap:101 telephone-event/8000a=fmtp:101 0-16a=ptime:10Sample OPTIONS Response
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.0Via: SIP/2.0/UDP 172.18.193.120:5060From: "user" <sip:36602@172.18.193.120>To: <sip:36601@172.18.193.98>Date: Mon, 01 Mar 1993 02:55:01 GMTCall-ID: BB8A5738-14EE11CC-8008B310-2C18B10E@172.18.193.120Accept: application/sdpCSeq: 110 OPTIONSContact: <sip:36601@172.18.193.98:5060>Content-Length: 011:28:44: Sent:SIP/2.0 200 OKVia: SIP/2.0/UDP 172.18.193.120:5060From: "user" <sip:36602@172.18.193.120>To: <sip:36601@172.18.193.98>;tag=2768F24-1DB2Date: Mon, 01 Mar 1993 11:28:44 GMTCall-ID: BB8A5738-14EE11CC-8008B310-2C18B10E@172.18.193.120Server: Cisco-SIPGateway/IOS-12.xContent-Type: application/sdpCSeq: 110 OPTIONSSupported: 100relAccept-Language: yo, sd;q=0.234, en;q=0.123Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, Refer , SUBSCRIBE, NOTIFY, INFOAccept: application/sdpAllow-Events: telephone-eventContent-Length: 170v=0o=CiscoSystemsSIP-GW-UserAgent 7292 5756 IN IP4 172.18.193.98s=SIP Callc=IN IP4 172.18.193.98t=0 0m=audio 0 RTP/AVP 18 0 8 4 2 15 3c=IN IP4 172.18.193.98SIP Enhanced 180 Provisional Response Handling
The SIP Enhanced 180 Provisional Response Handling feature provides the ability to enable or disable early media cut-through on Cisco IOS gateways for SIP 180 response messages. The feature allows you to specify whether 180 messages with Session Description Protocol (SDP) are handled in the same way as 183 responses with SDP. The 180 Ringing message is a provisional or informational response used to indicate that the INVITE message has been received by the user agent and that alerting is taking place. The 183 Session Progress response indicates that information about the call state is present in the message body media information. Both 180 and 183 messages may contain SDP which allow an early media session to be established prior to the call being answered.
Prior to the implementation of this feature, Cisco gateways handled a 180 Ringing response with SDP in the same manner as a 183 Session Progress response; that is, the SDP was assumed to be an indication that the far end would send early media. Cisco gateways handled a 180 response without SDP by providing local ringback, rather than early media cut-through. This feature provides the capability to ignore the presence or absence of SDP in 180 messages, and as a result, treat all 180 messages in a uniform manner. The SIP Enhanced 180 Provisional Response Handling feature introduces the new disable-early-media 180 command that enables you to specify which call treatment, early media or local ringback, is provided for 180 responses with SDP.
Table 4 shows the call treatments available with this feature.
SIP Extensions for Caller Identity and Privacy
To configure the SIP Extensions for Caller Identity and Privacy feature, you must understand the following concepts:
•
•
•
•
Privacy, Screening, and Presentation Indicators
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:
•
•
•
•
You can configure alternative calling information treatments for calls exiting the SIP trunking gateway. Configurable treatment options are as follows:
•
•
•
•
•
•
Remote-Party-ID Implementation
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.
Figure 1 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.
Figure 1 Wholesaler SIP Network
Note
In the following sections, Figure 2 through Figure 9 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.
Inbound and Outbound Call Flows
This section presents inbound and outbound call flows for the Remote-Party-ID feature. Figure 2 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.
Figure 2 SIP-to-PSTN Default Call Flow with Remote-Party-ID
Figure 3 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.
Figure 3 PSTN-to-SIP Default Call Flow with Remote-Party-ID Translation, No Privacy Requested
Figure 4 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.
Figure 4 Discarding Calling Name and Number at Gateway
Figure 5 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:
•
•
•
Figure 5 Overriding Calling Name and Number at Gateway
In Figure 6 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:
•
•
•
Figure 6 Overriding Calling Name and Number of From Header
Figure 7 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.
Figure 7 Passing OLI from CAS to SIP
Figure 8 and Figure 9 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.
Figure 8 PSTN-to-SIP Call Flow with Remote-Party-ID Translation, No Privacy Requested
With privacy requested, as shown in Figure 9, 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."
Figure 9 PSTN-to-SIP Call Flow with Remote-Party-ID, Privacy Requested
Remote-Party-ID in SIP and PSTN Messages
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:
•
Remote-Party-ID Header
The SIP Remote-Party-ID header identifies the calling party and includes user, party, screen and privacy headers that specify how a call is presented and screened. The header contains a URL and an optional display name that identifies a user. A valid Remote-Party-ID header may be either a SIP URL or a TEL URL.
Note
The following example shows representative Remote-Party-ID headers, including user, party, screen, and privacy.
02:32:17:Received:INVITE sip:3331000@172.27.184.118:5060;user=phone SIP/2.0Via:SIP/2.0/UDP 10.0.0.1:5070Supported:org.ietf.sip.100relFrom:"alice" <sip:555-1001@10.0.0.1:5070>To:sip:555-1002@172.27.184.118:5060Remote-Party-ID:"Alice Smith" <sip:5551111@192.0.2.67;user=phone>;party=calling;screen=no;privacy=offCall-ID:00000001@10.0.0.1:5070CSeq:1 INVITEContact:"alice" <sip:10.0.0.1:5070>Content-Type:application/sdpv=0o=- 2890844526 2890844526 IN IP4 A3C47F2146789F0s=-c=IN IP4 10.0.0.1t=36124033 0m=audio 49170 RTP/AVP 0Remote-Party-ID Syntax
Remote-Party-ID fields identify the calling party depending upon how the field is marked. If the party is unmarked, a Remote-Party-ID in a header represents the identity of the calling party.
Remote-Party-ID follows the Augmented Backus-Naur Format (ABNF). Refer to draft-ietf-sip-privacy-02.txt for the definitive specification. Fields are as follows:
•
•
•
•
•
•
•
ISDN Syntax
ISDN messages follow the format specified in ISDN Primary Rate Interface Call Control Switching and Signalling Generic Requirements for Class II Equipment, TR-NWT-001268, Revisions 1-4, Telcordia Technologies Technical Reference, 2001 and ISDN Basic Rate Interface Call Control Switching and Signalling Generic Requirements, GR-268-CORE, July 1998, to signal call control. ISDN messages are composed of information elements (IEs). The Cisco IOS VoiceXML feature uses Calling Party Number and Display Text IEs to provide specified screening and presentation treatment. The Calling Party Number IE specifies the origin of the calling number and presentation status, and the Display Text IE supplies calling party name information that is formatted for display by a terminal for a human user. See the Setup message in Figure 2 for sample IE information.
Screening and Presentation Information
The Remote-Part-ID header and ISDN Setup messages contain tags used to specify screened identity information. Table 5 lists translation of screening and presentation information included in the Remote-Party-ID SIP tags for SIP to PSTN networks. Table 6 provides the same translation for PSTN to SIP networks.
Table 7 lists the corresponding translation for ISDN tags in binary and hex formats.
Benefits of SIP Extensions for Caller Identity and Privacy
•
•
•
•
•
•
SIP INVITE Request with Malformed Via Header
A SIP INVITE requests that a user or service participate in a session. Each INVITE contains a Via header that indicates the transport path taken by the request so far, and where to send a response.
In the past, when an INVITE contained a malformed Via header, the gateway would print a debug message and discard the INVITE without incrementing a counter. However, the printed debug message was often inadequate, and it was difficult to detect that messages were being discarded.
The SIP INVITE Request with Malformed Via Header feature provides a response to the malformed request. A counter, Client Error: Bad Request, increments when a response is sent for a malformed Via field. Bad Request is a class 400 response and includes the explanation Malformed Via Field. The response is sent to the source IP address (the IP address where the SIP request originated) at User Datagram Protocol (UDP) port 5060.
Note
Feature benefits include the following:
•
•
SIP Session Timer Support
The SIP Session Timer Support feature adds the capability to periodically refresh SIP sessions by sending repeated INVITE requests. The repeated INVITE requests (re-INVITEs), are sent during an active call leg to allow user agents or proxies to determine the status of a SIP session. Without this keepalive mechanism, proxies that remember incoming and outgoing requests (stateful proxies) may continue to retain call state needlessly. If a user agent fails to send a BYE message at the end of a session or if the BYE message is lost because of network problems, a stateful proxy does not know that the session has ended. The re-INVITEs ensure that active sessions stay active and completed sessions are terminated.
In addition to re-INVITEs, UPDATE can also used as a method for session keepalives. The SIP stack supports both re-INVITE and UPDATE. The gateway continues to use re-INVITE for session refresh.
The SIP Session Timer Support feature also adds two new general headers that are used to negotiate the value of the refresh interval.
•
•
Role of the User Agents
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.
Session-Expires Header
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.
Min-SE Header
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-seconds422 Response Message
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.
Supported and Require Headers
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.
Benefits of SIP Session Timer Support
•
•
SIP: Cisco IOS Gateway Reason Header and Buffered Calling Name Completion
Reason Header
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 Figure 10).
Figure 10 PSTN Interworking Using Reason Header Example
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 Figure 11).
Figure 11 Reason Header in Action; Extinguishing the Ambiguity in SIP Status Codes
Buffered Calling-Name Completion
As shown in Figure 12, 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.
Figure 12 Calling Name in Facility IE of Facility
SIP: SIP Header/URL Support and SUBSCRIBE/NOTIFY for External Triggers
The SIP: SIP Header/URL Support and SUBSCRIBE/NOTIFY for External Triggers feature provides a mechanism for applications to send and receive SIP headers and to send SUBSCRIBE messages and receive NOTIFY events. Where appropriate, this section discusses separately the features that make up this feature set, the SIP Header Support feature along with the SUBSCRIBE and NOTIFY for External Triggers feature.
Feature benefits include the following:
•
•
•
•
This section contains the following information:
•
•
Feature Design of SIP Header Support
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:
•
•
•
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.
Feature Design of SIP SUBSCRIBE and NOTIFY for External Triggers
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. More detailed information for this feature is described in the following sections:
•
•
•
•
Overview of the SUBSCRIBE and NOTIFY for External Triggers Application
The SIP event notification mechanism uses the SUBSCRIBE method to request notification of an event at a later time. The NOTIFY method provides notification that an event which has been requested by an earlier SUBSCRIBE method has occurred, or provides further details about the event. The new feature makes headers in incoming SIP INVITE, SUBSCRIBE, and NOTIFY messages available to applications for use in event subscription. Similarly, to allow an application to place an outbound call using SIP, this feature passes headers in the URL for use by the SIP service provider interface (SPI) to create an outgoing INVITE request.
The new feature also supports the capability to subscribe to standard event packages, such as Message Waiting Indicator and Presence, and to application-specific custom event packages, as defined in SIP-Specific Event Notification, an earlier draft of RFC 3265, Session Initiation Protocol (SIP)-Specific Event Notification.
Note
•
•
•
Cisco implements the SUBSCRIBE and NOTIFY for External Triggers feature using the Application SUBSCRIBE/NOTIFY Layer (ASNL). ASNL is a software interface layer between the application and signaling protocol stacks that allows the application to subscribe to interested events and to pass notification when it is received.
The SUBSCRIBE and NOTIFY for External Triggers allows external SIP servers to trigger a particular voice application, behavior or activity on Cisco voice gateways. For example, a client application on the gateway subscribes to a particular event in a server. When the event takes place, the server notifies the client of that event. On receiving this event notification, the client application triggers a particular action in the gateway. The client and server must mutually agree on the events they can handle and the processing of those events.
Example of a SUBSCRIBE and NOTIFY for External Triggers Application
The SUBSCRIBE and NOTIFY for External Triggers feature supports various applications of external triggers. In the following scenario, a user requests a stock reminder service, for example "Let me know if Stock X reaches 100. Here is a phone number to reach me." The SUBSCRIBE and NOTIFY for External Triggers feature supports an application like this in the following manner:
•
•
•
•
Other external trigger applications include mid-call triggers such as call center queuing and subscription to a wake-up call service.
RFC 3265 Compliance for the SUBSCRIBE and NOTIFY for External Triggers Feature
The Cisco implementation of SIP SUBSCRIBE and NOTIFY methods is based on an earlier draft of SIP-Specific Event Notification, and deviates from RFC 3265, Session Initiation Protocol (SIP)-Specific Event Notification in the following capabilities:
•
–
–
–
–
•
•
•
SUBSCRIBE and NOTIFY Message Flow
Figure 13 shows a typical message flow for SUBSCRIBE and NOTIFY messages.
Figure 13 SUBSCRIBE and NOTIFY Message Flow
Figure 14 shows the message flow for a successful subscription.
Figure 14 Successful Subscription
Figure 15 shows a completed subscription. The server can send any number of NOTIFY messages as long as the subscription is active.
Figure 15 Subscription Completed
Figure 16 shows the message flow for subscription termination by the server.
Figure 16 Subscription Termination by the Server
Figure 17 shows the message flow for subscription termination by the client.
Figure 17 Subscription Termination by the Client
Sample Messages
This section presents a sequence of SIP messages sent and received between gateways during the message flow shown in Figure 13 in the preceding section.
Example: Subscription Request Sent From Client
This example shows a SUBSCRIBE request sent to the server. The example includes a nonstandard Subject header and an Event header.
*Apr 19 08:38:52.525: //-1//TCL2:HN01C24D3C:/tcl_PutsCmd:Sending MWI client request to server*Apr 19 08:38:52.525:*Apr 19 08:38:52.529: Sent:SUBSCRIBE sip:user@10.7.104.88:5060 SIP/2.0Via: SIP/2.0/UDP 10.7.102.35:5060From: <sip:10.7.102.35>;tag=1C24D44-20FDTo: <sip:user@10.7.104.88>Date: Wed, 19 Apr 2000 08:38:52 UTCCall-ID: C4BB7610-150411D4-802186E3-AD119804CSeq: 101 SUBSCRIBETimestamp: 956133532Subject: Hi ThereContact: <sip:10.7.102.35:5060>Event: message-summaryExpires: 500 )Content-Type: text/plainContent-Length: 21This is from clientExample: Subscription Response Received from the Server
This example shows a response from the server to a subscription request.
*Apr 19 08:38:52.537: Received:SIP/2.0 202 AcceptedVia: SIP/2.0/UDP 10.7.102.35:5060From: <sip:10.7.102.35>;tag=1C24D44-20FDTo: <sip:user@10.7.104.88>;tag=1D80E90-2072Date: Sun, 17 Nov 2002 02:59:19 GMTCall-ID: C4BB7610-150411D4-802186E3-AD119804Server: Cisco-SIPGateway/IOS-12.xTimestamp: 956133532Content-Length: 0CSeq: 101 SUBSCRIBEExpires: 500*Apr 19 08:38:52.541: //-1//TCL2:HN01C24D3C:/tcl_PutsCmd: ***** act_Subscribe : SUBSCRIPTION DONE received*Apr 19 08:38:52.541: //-1//TCL2:HN01C24D3C:/tcl_PutsCmd: *** act_subscribe: subscription status=sn_000Example: NOTIFY Request from the Server
This example shows the initial NOTIFY request from a server and includes an application-specific nonstandard Hello header.
*Apr 19 08:38:52.545: Received:NOTIFY sip:10.7.102.35:5060 SIP/2.0Via: SIP/2.0/UDP 10.7.104.88:5060From: <sip:user@10.7.104.88>;tag=1D80E90-2072To: <sip:10.7.102.35>;tag=1C24D44-20FDDate: Sun, 17 Nov 2002 02:59:19 GMTCall-ID: C4BB7610-150411D4-802186E3-AD119804User-Agent: Cisco-SIPGateway/IOS-12.xMax-Forwards: 6Timestamp: 1037501959CSeq: 101 NOTIFYEvent: message-summaryHello: Hello worldContact: <sip:user@10.7.104.88:5060>Content-Length: 43Content-Type: text/plainThis is content(message body) from serverExample: An Application Reads Header and Body Information in a NOTIFY Request
This example shows an application accessing the From and Hello headers in the NOTIFY request.
*Apr 19 08:38:52.549: //-1//TCL2:HN01C24D3C:/tcl_PutsCmd: *** act_Notify : NOTIFY RECEIVED t*Apr 19 08:38:52.549: //-1//TCL2:HN01C24D3C:/tcl_PutsCmd:From header is: <sip:user@10.7.104.88>;tag=1D80E90-2072*Apr 19 08:38:52.549: //-1//TCL2:HN01C24D3C:/tcl_PutsCmd:Hello header is: Hello world*Apr 19 08:38:52.549: //-1//TCL2:HN01C24D3C:/tcl_PutsCmd:content_type received=text/plain*Apr 19 08:38:52.549:*Apr 19 08:38:52.553: //-1//TCL2:HN01C24D3C:/tcl_PutsCmd:content received=This is content(message body) from serverExample: NOTIFY Request Sent From the Client
This example shows a NOTIFY request sent from a client.
*Apr 19 08:38:52.553: Sent:SIP/2.0 200 OKVia: SIP/2.0/UDP 10.7.102.35:5060From: <sip:user@10.7.104.88>;tag=1D80E90-2072To: <sip:10.7.102.35>;tag=1C24D44-20FDDate: Wed, 19 Apr 2000 08:38:52 UTCCall-ID: C4BB7610-150411D4-802186E3-AD119804CSeq: 101 NOTIFYTimestamp: 956133532Event: message-summaryContent-Length: 0Example: The Client receives a NOTIFY Message
This example shows a NOTIFY message received by a client.
c5300-5#*Apr 19 08:38:57.565: Received:NOTIFY sip:10.7.102.35:5060 SIP/2.0Via: SIP/2.0/UDP 10.7.104.88:5060From: <sip:user@10.7.104.88>;tag=1D80E90-2072To: <sip:10.7.102.35>;tag=1C24D44-20FDDate: Sun, 17 Nov 2002 02:59:19 GMTCall-ID: C4BB7610-150411D4-802186E3-AD119804User-Agent: Cisco-SIPGateway/IOS-12.xMax-Forwards: 6Timestamp: 1037501964CSeq: 102 NOTIFYEvent: message-summaryHello: Hello worldContact: <sip:user@10.7.104.88:5060>Content-Length: 35Content-Type: text/plainthis is just a notify from server*Apr 19 08:38:57.569: //-1//TCL2:HN01C24D3C:/tcl_PutsCmd: *** act_Notify : NOTIFY RECEIVED*Apr 19 08:38:57.569: //-1//TCL2:HN01C24D3C:/tcl_PutsCmd:From header is: <sip:user@10.7.104.88>;tag=1D80E90-2072*Apr 19 08:38:57.569: //-1//TCL2:HN01C24D3C:/tcl_PutsCmd:Hello header is: Hello world*Apr 19 08:38:57.569: //-1//TCL2:HN01C24D3C:/tcl_PutsCmd:content_type received=text/plain*Apr 19 08:38:57.569: //-1//TCL2:HN01C24D3C:/tcl_PutsCmd:content received=this is just a notify from serverExample: The Client Sends a NOTIFY Message
This example shows a client sending a NOTIFY message.
*Apr 19 08:38:57.573: Sent:SIP/2.0 200 OKVia: SIP/2.0/UDP 10.7.102.35:5060From: <sip:user@10.7.104.88>;tag=1D80E90-2072To: <sip:10.7.102.35>;tag=1C24D44-20FDDate: Wed, 19 Apr 2000 08:38:57 UTCCall-ID: C4BB7610-150411D4-802186E3-AD119804CSeq: 102 NOTIFYTimestamp: 956133537Event: message-summaryContent-Length: 0Example: The Client Initiates a Subscription Termination
This example shows a a client initiating a subscription termination request using the Expires header set to zero.
*Apr 19 08:38:57.577: Sent:SUBSCRIBE sip:user@10.7.104.88:5060 SIP/2.0Via: SIP/2.0/UDP 10.7.102.35:5060From: <sip:10.7.102.35>;tag=1C24D44-20FDTo: <sip:user@10.7.104.88>;tag=1D80E90-2072Date: Wed, 19 Apr 2000 08:38:57 UTCCall-ID: C4BB7610-150411D4-802186E3-AD119804CSeq: 102 SUBSCRIBETimestamp: 956133537Subject: Hi ThereContact: <sip:10.7.102.35:5060>Event: message-summaryExpires: 0Content-Type: text/plainContent-Length: 21This is from clientExample: The Client Receives a Response to a Subscription Termination Request
This example shows a client receiving a response to a subscription termination request.
*Apr 19 08:38:57.589: Received:SIP/2.0 200 OKVia: SIP/2.0/UDP 10.7.102.35:5060From: <sip:10.7.102.35>;tag=1C24D44-20FDTo: <sip:user@10.7.104.88>;tag=1D80E90-2072Date: Sun, 17 Nov 2002 02:59:24 GMTCall-ID: C4BB7610-150411D4-802186E3-AD119804Server: Cisco-SIPGateway/IOS-12.xTimestamp: 956133532Content-Length: 0CSeq: 102 SUBSCRIBEExpires: 0Contact: <sip:user@10.7.104.88:5060>Example: The Client Receives a Final NOTIFY Message
This example shows a client receiving a final NOTIFY message that a subscription is finished.
c5300-5#*Apr 19 08:39:02.585: Received:NOTIFY sip:10.7.102.35:5060 SIP/2.0Via: SIP/2.0/UDP 10.7.104.88:5060From: <sip:user@10.7.104.88>;tag=1D80E90-2072To: <sip:10.7.102.35>;tag=1C24D44-20FDDate: Sun, 17 Nov 2002 02:59:24 GMTCall-ID: C4BB7610-150411D4-802186E3-AD119804User-Agent: Cisco-SIPGateway/IOS-12.xMax-Forwards: 6Timestamp: 1037501969CSeq: 103 NOTIFYEvent: message-summaryHello: Hello worldContact: <sip:user@10.7.104.88:5060>Content-Length: 35Content-Type: text/plainthis is just a notify from server*Apr 19 08:39:02.589: //-1//TCL2:HN01C24D3C:/tcl_PutsCmd: *** act_Notify : FINAL NOTIFY RECEIVED*Apr 19 08:39:02.589: //-1//TCL2:HN01C24D3C:/tcl_PutsCmd: status=sn_004*Apr 19 08:39:02.589: //-1//TCL2:HN01C24D3C:/tcl_PutsCmd:From header is: <sip:user@10.7.104.88>;tag=1D80E90-2072*Apr 19 08:39:02.593: //-1//TCL2:HN01C24D3C:/tcl_PutsCmd: act_UnsubcribeDone : !!! SUBSCRIPTION IS OVER !!!Example: A Final NOTIFY Message to a Server
This example shows a final NOTIFY message to a server.
*Apr 19 08:39:02.593: Sent:SIP/2.0 200 OKVia: SIP/2.0/UDP 10.7.102.35:5060From: <sip:user@10.7.104.88>;tag=1D80E90-2072To: <sip:10.7.102.35>;tag=1C24D44-20FDDate: Wed, 19 Apr 2000 08:39:02 UTCCall-ID: C4BB7610-150411D4-802186E3-AD119804CSeq: 103 NOTIFYTimestamp: 956133542Event: message-summaryContent-Length: 0SIP Stack Portability
The SIP Stack Portability feature implements the following capabilities to the Cisco IOS SIP gateway stack:
•
•
•
•
It sends an INVITE message request without Session Description Protocol (SDP) and provides SDP information in either the PRACK or ACK message request for both initial call establishment and mid-call re-INVITE message requests.
•
The stack applies certain rules and restrictions for a subset of headers and for some content types (such as SDP) to protect the integrity of the stack's functionality and to maintain backward compatibility. When receiving SIP message requests, it reads the SIP header and any attached body without any restrictions.
To make the best use of SIP call-transfer features, you should understand the following concepts:
•
•
•
•
•
SIP Call-Transfer Basics
This section contains the following information:
•
•
Basic Terminology of SIP Call Transfer
Call transfer allows a wide variety of decentralized multiparty call operations. These decentralized call operations form the basis for third-party call control, and thus are important features for VoIP and SIP. Call transfer is also critical for conference calling, where calls can transition smoothly between multiple point-to-point links and IP-level multicasting.
Refer Message Request
The SIP Refer message request provides call-transfer capabilities to supplement the SIP BYE and ALSO message requests already implemented on Cisco IOS SIP gateways. The Refer message request has three main roles:
•
•
•
Note
The Refer message request always begins within the context of an existing call and starts with the originator. The originator sends a Refer request to the recipient (user agent receiving the Refer request) to initiate a triggered INVITE request. The triggered INVITE request uses the SIP URL contained in the Refer-To header as the destination of the INVITE request. The recipient then contacts the resource in the Refer-To header (final recipient), and returns a SIP 202 (Accepted) response to the originator. The recipient also must notify the originator of the outcome of the Refer transaction—whether the final recipient was successfully contacted or not. The notification is accomplished using the SIP NOTIFY message request, SIP's event notification mechanism. A NOTIFY message with a message body of SIP 200 OK indicates a successful transfer, and a message body of SIP 503 Service Unavailable indicates an unsuccessful transfer. If the call was successful, a call between the recipient and the final recipient results.
Figure 18 represents the call flow of a successful Refer transaction initiated within the context of an existing call.
Figure 18 Successful Refer transaction
Refer-To Header
The recipient receives from the originator a Refer request that always contains a single Refer-To header. The Refer-To header includes a SIP URL that indicates the party to be invited and must be in SIP URL format.
Note
The Refer-To header may contain three additional overloaded headers to form the triggered INVITE request. If any of these three headers are present, they are included in the triggered INVITE request. The three headers are:
•
•
•
All other headers present in the Refer-To are ignored, and are not sent in the triggered INVITE.
Note
Referred-By Header
The Referred-By header is required in a Refer request. It identifies the originator and may also contain a signature (included for security purposes). SIP gateways echo the contents of the Referred-By header in the triggered INVITE request, but on receiving an INVITE request with this header, gateways do not act on it.
Note
NOTIFY Message Request
Once the outcome of the Refer transaction is known, the recipient of the Refer request must notify the originator of the outcome of the Refer transaction—whether the final-recipient was successfully contacted or not. The notification is accomplished using the NOTIFY message request, SIP's event notification mechanism. The notification contains a message body with a SIP response status line and the response class in the status line indicates the success or failure of the Refer transaction.
The NOTIFY message must do the following:
•
•
•
Two Cisco IOS commands pertain to the NOTIFY message request:
•
•
Note
Types of SIP Call Transfer Using the Refer Message Request
This section discusses how the Refer message request facilitates call transfer.
There are two types of call transfer: blind and attended. The primary difference between the two is that the Replaces header is used in attended call transfers. The Replaces header is interpreted by the final recipient and contains a Call-ID header, indicating that the initial call leg is to be replaced with the incoming INVITE request.
As outlined in the Refer message request, there are three main roles:
•
•
•
A gateway can be a recipient or final recipient, but not an originator.
Blind Call-Transfer Process
A blind, or unattended, transfer is one in which the transferring phone connects the caller to a destination line before ringback begins. This is different from a consultative, or attended, transfer in which one of the transferring parties either connects the caller to a ringing phone (ringback heard) or speaks with the third party before connecting the caller to the third party. Blind transfers are often preferred by automated devices that do not have the capability to make consultation calls.
Blind transfer works as described in the "Refer Message Request" section. The process is as follows:
1.
a.
b.
2.
a.
b.
c.
3.
4.
•
•
Figure 19 shows a successful blind or unattended call transfer in which the originator initiates a Bye request to terminate signaling with the recipient.
Figure 19 Successful Blind or Unattended Transfer—Originator Initiating a Bye Request
Figure 20 shows a successful blind or unattended call transfer in which the recipient initiates a Bye request to terminate signaling with the originator. A NOTIFY message is always sent by the recipient to the originator after the final outcome of the call is known.
Figure 20 Successful Blind or Unattended Transfer—Recipient Initiating a Bye Request
If a failure occurs with the triggered INVITE to the final recipient, the call between originator and recipient is not disconnected. Rather, with blind transfer the process is as follows:
1.
2.
3.
4.
5.
a.
b.
Figure 21 Failed Blind Transfer—Originator Returns to Original Call with Recipient
Attended Transfer
In attended transfers, the Replaces header is inserted by the initiator of the Refer message request as an overloaded header in the Refer-To and is copied into the triggered INVITE request sent to the final recipient. The header has no effect on the recipient, but is interpreted by the final recipient as a way to distinguish between blind transfer and attended transfer. The attended transfer process is as follows:
1.
a.
b.
c.
d.
2.
a.
b.
3.
4.
5.
Replaces Header
The Replaces header is required in attended transfers. It indicates to the final recipient that the initial call leg (identified by the Call-ID header and tags) is to be shut down and replaced by the incoming INVITE request. The final recipient sends a Bye request to the originator to terminate its session.
If the information provided by the Replaces header does not match an existing call leg, or if the information provided by the Replaces header matches a call leg but the call leg is not active (a Connect, 200 OK to the INVITE request has not been sent by the final-recipient), the triggered INVITE does not replace the initial call leg and the triggered INVITE request is processed normally.
Any failure resulting from the triggered INVITE request from the recipient to the final recipient does not drop the call between the originator and the final recipient. In these scenarios, all calls that are active (originator to recipient and originator to final recipient) remain active after the failed attended transfer attempt
Figure 22 shows a call flow for a successful attended transfer.
Figure 22 Successful Attended Transfer
Attended Transfer with Early Completion
Attended transfers allow the originator to have a call established between both the recipient and the final recipient. With attended transfer with early completion, the call between the originator and the final recipient does not have to be active, or in the talking state, before the originator can transfer it to the recipient. The originator establishes a call with the recipient and only needs to be setting up a call with the final recipient. The final recipient may be ringing, but has not answered the call from the originator when it receives a re-INVITE to replace the call with the originator and the recipient.
The process for attended transfer with early completion is as follows (see Figure 23):
1.
a.
b.
c.
d.
2.
a.
b.
3.
4.
Note
5.
6.
Figure 23 Attended Transfer with Early Completion
VSA for Call Transfer
You can use a vendor-specific attribute (VSA) for SIP call transfer.
Referred-By Header
For consistency with existing billing models, Referred-By and Requested-By headers are populated in call history tables as a VSA. Cisco VSAs are used for VoIP call authorization. The new VSA tag supp-svc-xfer-by helps to associate the call legs for call-detail-record (CDR) generation. The call legs can be originator-to-recipient or recipient-to-final-recipient.
The VSA tag supp-svc-xfer-by contains the user@host portion of the SIP URL of the Referred-By header for transfers performed with the Refer message request. For transfers performed with the Bye/Also message request, the tag contains user@host portion of the SIP URL of the Requested-By header. For each call on the gateway, two RADIUS records are generated: start and stop. The supp-svc-xfer-by VSA is generated only for stop records and is generated only on the recipient gateway—the gateway receiving the Refer or Bye/Also message.
The VSA is generated when a gateway that acts as a recipient receives a Refer or Bye/Also message with the Referred-By or Requested-By headers. There are usually two pairs of start and stop records. There is a start and stop record between the recipient and the originator and also between the recipient to final recipient. In the latter case, the VSA is generated between the recipient to the final recipient only.
Business Group Field
A new business group VSA field has been added that assists service providers with billing. The field allows service providers to add a proprietary header to call records. The VSA tag for business group ID is cust-biz-grp-id and is generated only for stop records. It is generated when the gateway receives an initial INVITE with a vendor dial-plan header to be used in call records. In cases when the gateway acts as a recipient, the VSA is populated in the stop records between the recipient and originator and the final recipient.
Note
SIP Call Transfer and Call Forwarding Using Tcl IVR 2.0 and VoiceXML Applications
This section contains the following information about SIP Call Transfer and Call Forwarding with a Toolkit Command Language (Tcl) interactive-voice-response (IVR) or VoiceXML script:
•
•
•
SIP Call Transfer and Call Forwarding with a Tcl IVR Script
When using a Tcl IVR 2.0 application, you can implement SIP support of blind, or attended, call-transfer and call-forwarding requests from a Cisco IOS gateway. A blind transfer is one in which the transferring phone connects the caller to a destination line before ringback begins. This is different from a consultative transfer in which one of the transferring parties either connects the caller to a ringing phone (ringback heard) or speaks with the third party before connecting the caller to the third party. Blind transfers are often preferred by automated devices that do not have the capability to make consultation calls.
Before implementing blind transfer and call forwarding, you must write a custom Tcl IVR 2.0 script that implements call transfer and call forwarding. The script is responsible for receiving the hookflash event, providing dial tone, matching against the dial plan, initiating call transfer, and reestablishing the original call if the transfer attempt fails.
Note
When the Tcl IVR script runs on the Cisco gateway, it can respond to requests to initiate blind call transfer (transfer without consultation) on a SIP call leg. SIP call forwarding on ephones (IP phones that are not configured on the gateway) is also supported.
Note
Release Link Trunking on SIP Gateways
Release link trunking (RLT) functionality has been added to Cisco IOS SIP gateways. With RLT functionality, SIP call transfer now can be triggered by channel associated signaling (CAS) trunk signaling, which the custom Tcl IVR application can monitor. After a SIP call transfer has transpired and the CAS interface is no longer required, the CAS interface can be released.
The RLT functionality can be used to initiate blind transfers on SIP gateways. Blind call transfer uses the Refer message request. A full description of blind transfer and the Refer message request can be found in the "Configuring SIP Call-Transfer Features" chapter.
RLT and SIP Call Transfers
Call transfer can be triggered by CAS trunk signaling and then captured by the Tcl IVR script on a gateway. The process begins with the originator (the SIP user agent that initiates the transfer or Refer message request) responding with a dial tone once the originator receives the signal or hookflash from the PSTN call leg. The originator then prepares to receive dual-tone multifrequency (DTMF) digits that identify the final recipient (the user agent introduced into a call with the recipient).
Once the first DTMF digit is received, the dial tone is discontinued. DTMF-digit collection is not completed until a 4-second interdigit timeout occurs, or an on-hook is received on that specific CAS time slot. Call transfer starts when DTMF-digit collection is successful. If digit collection fails, for example, if not enough DTMF digits or invalid digits are collected, the initial call is reestablished.
Once the DTMF digits are successfully collected, the Tcl IVR script can initiate call transfer. SIP messaging begins when the transfer is initiated with the Refer message request. The originator sends an INVITE to the recipient (the user agent that receives the Refer message request and is transferred to the final recipient) to hold the call and request that the recipient not return Real-Time Transport Protocol (RTP) packets to the originator. The originator then sends a SIP Refer message request to the recipient to start the transfer process. When the recipient receives the request, the recipient returns a 202 Accepted acknowledgment to the originator. The Tcl IVR script run by the originator can then release the CAS trunk and close the primary call. See Figure 24.
If the recipient does not support the Refer message request, a 501 Not implemented message is returned. However, for backward compatibility purposes, the call transfer is automatically continued with the Bye/Also message request. The originator sends a Bye/Also request to the recipient and releases the CAS trunk with the PSTN call leg. The primary call between the originator and the recipient is closed when a 200 OK response is received.
In all other cases of call-transfer failures, the primary call between the originator and the recipient is immediately shut down.
Figure 24 Call Transfer Using the Refer Message Request
SIP and TEL URLs in Call Transfers
When the SIP call-transfer originator collects DTMF digits from the CAS trunk, it attempts to find a dial peer. If a dial peer is found, the session target in the dial peer is used to formulate a SIP URL. This URL can be used with both the Refer message request and the Bye/Also message request. A SIP URL is in the following form:
sip:JohnSmith@example.comIf a valid dial peer is not found, a Telephone Uniform Resource Locator (TEL URL) is formulated in the Refer-To header. A TEL URL is in the following form:
tel:+11235550100The choice of which URL to use is critical when correctly routing SIP calls. For example, the originating gateway can send out a Bye with an Also header, but the Also header can carry only a SIP URL. The Also header cannot carry a TEL URL. That is, if the gateway decides to send a Bye/Also but cannot find a matched dial peer, the gateway reports an error on the transfer gateway and sends a Bye without the Also header.
If the recipient of a SIP call transfer is a SIP phone, the phone must have the capability to interpret either the Refer message request or the Bye/Also message request for the call transfer to work. If the recipient is a Cisco IOS gateway, there needs to be a matching dial peer for the Refer-To user. User, looking at the previous example, can be either JohnSmith or 11235550100. The dial peer also needs to have an application session defined, where session can be the name of a Tcl IVR application. If there is no match, a 4xx error is sent back and no transfer occurs. If there is a POTS dial-peer match, a call is made to that POTS phone. Before Cisco IOS Release 12.2(15)T, if there is a VoIP match, the Refer-To URL is used to initiate a SIP call. In Release 12.2(15)T and later releases, the application session target in the dial peer is used for the SIP call.
SIP Gateway Initiation of Call Transfers
SIP gateways can also initiate, or originate, attended call transfers. The process begins when the originator establishes a call with the recipient. When the user on the PSTN call leg wants to transfer the call, the user uses hookflash to get a second dial tone and then enters the final recipient's number. The Tcl IVR script can then put the original call on hold and set up the call to the final-recipient, making the originator active with the final-recipient. The Refer message request is sent out when the user hangs up to transfer the call. The Refer message request contains a Replaces header that contains three tags: SIP CallID, from, and to. The tags are passed along in the INVITE from the recipient to the final recipient, giving the final recipient adequate information to replace the call leg. The host portion of the Refer message request is built from the established initial call. The following is an example of a Refer message request that contains a Replaces header:
Note
Refer sip:5550100@172.16.190.100:5060;user=phone SIP/2.0Via: SIP/2.0/UDP 172.16.190.99:5060From: "5550101" <sip:5555555@172.16.190.187>To: <sip:5550100@172.16.190.187>;tag=A7C2C-1E8CDate: Sat, 01 Jan 2000 05:15:06 GMTCall-ID: c2943000-106ae5-1c5f-3428@172.16.197.182User-Agent: Cisco-SIPGateway/IOS-12.xMax-Forwards: 6Timestamp: 946685709CSeq: 103 ReferRefer-To: sip:5550101@10.102.17.217?Replaces=DD713380-339C11CC-80BCF308-92BA812C@172.16.195.77;to-ta g=A5438-23E4;from-tag=C9122EDB-2408Referred-By: <sip:5550101@172.16.190.99>Content-Length: 0Once the NOTIFY is received by the originator, the Tcl IVR script can disconnect the call between the originator and the recipient. The call between the originator and the final recipient is disconnected by the recipient sending a BYE to the originator. See Figure 25 for a call flow of a successful call transfer.
Figure 25 Successful Attended Call Transfer Initiated by the Originator
If the recipient does not support the Refer message request, a 501 Not implemented message is returned.
In all other cases of call-transfer failures, the primary call between the originator and the recipient is immediately shut down. Figure 26 shows the recipient hanging up the call before the transfer completes. The item to notice is that the NOTIFY message is never sent.
Figure 26 Unsuccessful Call Transfer—Recipient Hangs Up Before Transfer Completes
SIP Call Forwarding
SIP call forwarding is supported only on ephones—IP phones that are not configured on the gateway. Foreign exchange station (FXS), foreign exchange office (FXO), T1, E1, and CAS phones are not supported.
With ephones, four different types of SIP call forwarding are supported:
•
•
•
•
In all four of these call-forwarding types, a 302 Moved Temporarily response is sent to the user-agent client. A Diversion header included in the 302 response indicates the type of forward.
The 302 response also includes a Contact header, which is generated by the calling number that is provided by the custom Tcl IVR script. The 302 response also includes the host portion found in the dial peer for that calling number. If the calling number cannot match a VoIP dial-peer or POTS dial-peer number, a 503 Service Unavailable message is sent, except in the case of the Call Forward No Answer. With Call Forward No Answer, call forwarding is ignored, the phone rings, and the expires timer clears the call if there is no answer.
Note
SUBSCRIBE or NOTIFY Message Request Support
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.
SIP NOTIFY-Based Out-of-Band DTMF Relay
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
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 Figure 27; Table 8 describes the fields.
Figure 27 Message Format of NOTIFY-Based Out-of-Band DTMF Relay
Sending NOTIFY Messages
As soon as the DTMF event is recognized, the gateway sends out an initial NOTIFY message for this event with the duration negotiated in the Call-Info header of the SIP INVITE. For the initial NOTIFY message, the end bit is set to zero. Afterward, one of the following actions can occur:
•
•
•
For example, if the negotiated duration is 600 ms, as soon as a DTMF event occurs, the initial NOTIFY message is sent with duration as 600 ms. Then a timer starts for this duration.
•
•
Every DTMF event corresponds to at least two NOTIFY message requests: an initial NOTIFY message and an end NOTIFY message. There might also be some update NOTIFY message requests involved, if the total duration of the event is greater than the negotiated max-duration interval. Because DTMF events generally last for less than 1000 ms, setting the duration using the notify telephone-event command to more than 1000 ms reduces the total number of NOTIFY messages sent. The default value of the notify telephone-event command is 2000 ms.
Receiving NOTIFY Messages
Once a NOTIFY message is received by the terminating gateway, the DTMF tone plays and a timer is set for the value in the duration field. Afterward, one of the following actions can occur:
•
•
•
•
Note
Two commands allow you to enable or disable NOTIFY-based out-of-band DTMF relay on a dial peer. The functionality is advertised to the other end using INVITE messages if it is enabled by the commands, and must be configured on both the originating and terminating SIP gateways. A third command allows you to verify DTMF relay status:
•
•
•
The NOTIFY message request has a Subscription-State header per RFC 3265. Refer to the "Configuring SIP DTMF Features" module for additional information that relates to the DTMF feature.
Support for RFC 3312—QoS
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.
SIP Portable Stack Considerations for QoS
The portable SIP stack is unaware of the type of call (QoS or regular). All QoS-related information carried by SIP or SDP are passed by or to the application. The application takes the necessary steps to distinguish the type of call and handle it accordingly, transparent to the portable SIP stack. From the portable SIP stack's perspective, the call flow for establishing a QoS call is similar to that of a non-QoS call. The only additions to the portable SIP stack application for establishing or modifying QoS calls are as follows:
•
•
Behavior for QoS with RFC 3312 for Cisco IOS Gateways
The following lists the behavior that SIP QoS calls exhibits on Cisco IOS gateways, with RFC 3312 complaint stack as opposed to existing ICEE implementation:
•
Current Status—This attribute carries the current status of the network resources for a particular media stream in either offer or answer SDP. The gateways generates the following values depending on the state of the reservation.
Desired Status—This attribute states the preconditions for a particular media stream. For the Cisco IOS gateway the reservation is always applicable end-to-end status with resources reserved in either direction. The strength tag is configurable.
Confirmation Status—This attribute carries the information for the other gateway to notify back (using the UPDATE message request) once resource reservations are done on its end. On Cisco IOS gateways the originating gateways never request confirmation from the terminating gateway and if that fails, then the call is not presented and is terminated with a 580 (Precondition Failure) message response. The terminating gateway always asks for confirmation from the originating gateway when its reservations are done using the UPDATE message request. This is requested through the 183 message response for the INVITE message request.
•
•
•
•
Backward Compatibility
The QoS call flows are not backward compatible on Cisco IOS gateways. SIP continues to use existing RSVP Cisco IOS subsystem and its APIs but the SIP or SDP signalling involved is different from the existing implementation.
COMET Message Request Obsolescence
This feature stack is obsoletes the usage (sending or receiving) of COMET message requests. This message request is replaced by UPDATE message request. This change has minor impact on the Call Admission Control feature on Cisco IOS gateways. QoS is the only other feature to use COMET. The CAC feature is using the UPDATE message request instead of COMET.
QoS Call Flow
The flows shown in Figure 28 show a two-party call that invokes RSVP services to reserve resources before the called party is alerted. On the Cisco IOS gateway for this feature implementation the originating gateway does not need confirmation for INVITE message request preconditions. All the QoS SDP attributes shown are media-level attributes. If multiple media lines are associated with their own QoS attributes, then only the first media line QoS is honored.
Figure 28 Successful QoS Call Establishment
Support for the Achieving SIP RFC Compliance Feature
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.
Enhanced Redirect Handling
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.
Cisco IOS Behavior
There are no changes in the handling of redirects in Cisco IOS software. The stack continues to perform the redirections.
Diversion Header Draft 06 Compliance
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
SIP: Domain Name Support in SIP Headers
The SIP: Domain Name Support in SIP Headers feature adds a command line interface (CLI) switch to provide a host or domain name in the host portion of the locally generated Session Initiation Protocol (SIP) headers (for example, From, RPID, and Call-ID). This feature also affects outgoing dialog-initiating SIP requests (for example, INVITE and SUBSCRIBE message requests).
To configure this feature, you should understand the following concepts:
•
Vendor-specific attribute (VSA) is introduced to generate information about the locally configured host or domain name in the accounting records generated by the gateway. For a complete list of VSA changes, see the RADIUS VSA Voice Implementation Guide.
Call Active and History VoIP Records
Call active and history VoIP records present the local hostname. They have the following format:
#show call active voiceVOIP:LocalHostname=example.comThese records are generated for calls created in the context of the INVITE message request.
SIP Headers
The CLI affects the host portion of the following SIP headers generated for an outbound VoIP call from the SIP 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.
Sample SIP Header Messages
This section contains the following sample SIP header messages with the SIP: Domain Name Support in SIP Headers feature disabled and enabled:
•
•
Feature Disabled—INVITE Message Request Sent from the Gateway
Sent:INVITE sip:9002@example.sip.com:5060 SIP/2.0Via:SIP/2.0/TCP 172.18.195.49;branch=z9hG4bK597Remote-Party-ID:<sip:9001@172.18.195.49>;party=calling;screen=no;privacy=offFrom:<sip:9001@172.18.195.49>;tag=3AA7574-11BATo:<sip:9002@example.sip.com>Date:Tue, 31 Aug 2004 13:40:57 GMTCall-ID:3924408D-FA8A11D8-80208D32-72E3122E@172.18.195.49Supported:100rel,timer,resource-priorityMin-SE:1800Cisco-Guid:940277299-4203352536-2149420338-1927483950User-Agent:Cisco-SIPGateway/IOS-12.xAllow:INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, Refer , SUBSCRIBE, NOTIFY, INFO, REGISTERCSeq:101 INVITEMax-Forwards:70Timestamp:1093959657Contact:<sip:9001@172.18.195.49:5060;transport=tcp>Expires:180Allow-Events:telephone-eventContent-Type:multipart/mixed;boundary=uniqueBoundaryMime-Version:1.0Content-Length:418--uniqueBoundaryContent-Type:application/sdpContent-Disposition:session;handling=requiredv=0o=CiscoSystemsSIP-GW-UserAgent 4780 5715 IN IP4 172.18.195.49s=SIP Callc=IN IP4 172.18.195.49t=0 0m=audio 18336 RTP/AVP 18 101 19c=IN IP4 172.18.195.49a=rtpmap:18 G729/8000a=fmtp:18 annexb=noa=rtpmap:101 telephone-event/8000a=fmtp:101 0-16a=rtpmap:19 CN/8000a=ptime:20--uniqueBoundary--Feature Enabled—INVITE Message Request Sent from the Gateway
Sent:INVITE sip:9002@example.sip.com:5060 SIP/2.0Via:SIP/2.0/TCP 172.18.195.49;branch=z9hG4bK22C7Remote-Party-ID:<sip:9001@gw11.example.com>;party=calling;screen=no;privacy=offFrom:<sip:9001@gw11.example.com>;tag=39CF740-FFCTo:<sip:9002@example.sip.com>Date:Tue, 31 Aug 2004 13:26:13 GMTCall-ID:2A101AD3-FA8811D8-801C8D32-72E3122E@gw11.example.comSupported:100rel,timer,resource-priorityMin-SE:1800Cisco-Guid:686218050-4203221464-2149158194-1927483950User-Agent:Cisco-SIPGateway/IOS-12.xAllow:INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, Refer , SUBSCRIBE, NOTIFY, INFO, REGISTERCSeq:101 INVITEMax-Forwards:70Timestamp:1093958773Contact:<sip:9001@172.18.195.49:5060;transport=tcp>Expires:180Allow-Events:telephone-eventContent-Type:multipart/mixed;boundary=uniqueBoundaryMime-Version:1.0Content-Length:418--uniqueBoundaryContent-Type:application/sdpContent-Disposition:session;handling=requiredv=0o=CiscoSystemsSIP-GW-UserAgent 5250 7833 IN IP4 172.18.195.49s=SIP Callc=IN IP4 172.18.195.49t=0 0m=audio 18998 RTP/AVP 18 101 19c=IN IP4 172.18.195.49a=rtpmap:18 G729/8000a=fmtp:18 annexb=noa=rtpmap:101 telephone-event/8000a=fmtp:101 0-16a=rtpmap:19 CN/8000a=ptime:20--uniqueBoundary--SIP Gateway Support for SDP Session Information and Permit Hostname CLI
The SIP GW Support for SDP Session Information and Permit Hostname CLI Feature adds support to Cisco IOS SIP gateways for both SDP session information and validation of hostnames in initial INVITE requests. These features are described in the following sections:
•
•
SDP Changes for Session Information Line
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=0o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4s=SDP Seminari=A Seminar on the session description protocolu=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.pse=mjh@isi.edu (Mark Handley)c=IN IP4 224.2.17.12/127t=2873397496 2873404696a=recvonlym=audio 49170 RTP/AVP 0i=media-information 1m=video 51372 RTP/AVP 31i=media-information 2m=application 32416 udp wba=orient:portraitThe 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.
Validating Hostname in Initial INVITE Request URI
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-uaretry invite 1registrar ipv4:172.18.193.97 expires 3600permit hostname dns:sinise.sip.compermit hostname dns:liotta.sip.compermit hostname dns:sipgw.sip.compermit hostname dns:yourgw.sip.compermit 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.0Via: SIP/2.0/UDP 172.18.201.173:5060;branch=z9hG4bK2C419To: <sip:777@172.18.197.154>From: <sip:333@64.102.17.246>;tag=B87C0-B65Date: Thu, 23 Feb 2006 16:49:26 GMTCall-ID: 4EAF670B-A3C311DA-80148B65-6E225A8E@172.18.197.154Contact: <sip:333@172.18.201.173>Supported: 100rel, eatitAllow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, Refer , SUBSCRIBE, NOTIFY, INFOMax-Forwards: 70Cseq: 104 INVITEExpires: 60Timestamp: 730947404Content-Length: 211Content-Type: application/sdp^Mv=0o=CiscoSystemsSIP-GW-UserAgent 6109 4520 IN IP4 172.18.201.173s=SIP Callc=IN IP4 111.11.111.111t=0 0m=audio 16880 RTP/AVP 0 19c=IN IP4 111.11.111.111a=rtpmap:0 PCMU/8000a=rtpmap:19 CN/8000a=ptime:20Outbound Proxy Support for the SIP Gateway
The Outbound Proxy Support for the SIP Gateway feature allows you to configure an outbound proxy server on a SIP gateway. You can use the outbound-proxy command to globally configure a SIP gateway to send all dialog initiating requests (such as INVITE, SUBSCRIBE, and REGISTER) to a specified destination. You can also use the voice-class sip outbound-proxy command to configure these settings on an individual dial peer, overriding the global gateway settings (refer to the Cisco IOS Voice Command Reference).
The request-uri of these dialog initiating requests are extracted from the session-target and does not reflect that the request is sent to a configured outbound-proxy server. The outbound-proxy server, based on the host in the request-uri, routes it accordingly. However, in some scenarios, it is possible that calls coming in over a SIP trunk to Cisco Unified Communications Manger Express (Cisco Unified CME) get forwarded to the outbound SIP proxy rather than directly to the phone. To correct this behavior, use the outbound-proxy system command to configure SIP line-side phones o a Cisco Unified CME (refer to the Cisco Unified Communications Manager Express Command Reference).
SIP: SIP Support for PAI
The SIP Support for PAI feature allows you to configure privacy headers into associated SIP request messages, as defined in RFC 3323 and RFC 3325. This feature introduces the privacy and asserted-id commands which you can use to build various privacy-header requests into common SIP messages, as shown in Table 9.
SIP: History-info Header Support
The SIP History-info Header Support feature provides support for the history-info header in SIP INVITE messages only. The SIP gateway generates history information in the INVITE message for all forwarded and transferred calls. The history-info header records the call or dialog history. The receiving application uses the history-info header information to determine how and why the call has reached it.
The receiving application can use the call or dialog history to enhance services, such as calls to voice mail servers or sessions initiated to call centers from a click-to-talk SIP URL on a web page.
To configure the SIP History-info Header Support feature, you need to understand the following concepts:
•
Feature Design of SIP History-info Header Support
Cisco implements this feature on SIP-TDM gateways and SIP-SIP Cisco Unified Border Element gateways 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 (up to a maximum of nine) for a single INVITE message. The headers are contained in a comma-separated list.
SIP History-info Header Support on SIP-TDM Gateways
When the TDM gateway sends an INVITE message, it creates the history-info header based on the request URI.
When the gateway receives a redirected PSTN call, it builds the history-info header using the redirect information provided by the PSTN source signaling address, the local host configuration (DNS name), and the host registrar.
To maintain the correct order and to record any redirection of a request, the header includes index information (as a series of dot-delimited digits). The index format is defined in RFC 4244 section 4.3.3.1.3.
If history-info headers are enabled for the SIP stage, the gateway sends both diversion headers and history-info headers in the outbound request. However, the history-info header takes preference when the gateway maps the header to the ISDN redirect number.
SIP History-info Header Support on SIP-SIP Cisco Unified Border Element Gateways
When the Cisco Unified Border Element gateway receives an inbound INVITE message without a history-info header, it generates the history-info header based on the request URI in the outbound INVITE message. If privacy is enabled on the gateway, then history is added to the privacy settings.
When the gateway receives an outbound message it creates the history-info header to the message based on the request URI. The maximum number of history-info headers supported by the gateway is nine. If the gateway receives a message with nine or more headers, it keeps the first eight messages only and adds the new header to the end of the header list.
When history-info privacy is configured on the gateway, it transparently passes all history-info and privacy headers in the message from one SIP stage to the next.
The gateway forwards history-info headers from one SIP stage to the next. If history-info headers are enabled for the SIP stage, the gateway behaves as follows:
•
•
•
If history-info headers are disabled for the SIP stage, the gateway sends all diversion headers (including any new diversion headers) to the next SIP stage.
How to Configure SIP Message, Timer, and Response Features
This section contains the following procedures:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Note
–
–
•
Configuring Internal Cause Code Consistency Between SIP and H.323
To configure the Internal Cause Code Consistence Between SIP and H.323 feature, perform the following procedures.
•
•
Configure Internal Cause Code Consistency Between SIP and H.323
The standard set of cause-code categories that is now generated for internal voice call failures is used by default. To configure internal failures with existing or nonstandard H.323 and SIP cause codes, perform the following steps.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configuring SIP - Configurable PSTN Cause Code Mapping
To configure SIP - Configurable PSTN Cause Code Mapping, perform the following procedures.
•
•
Map PSTN Codes to SIP Status Codes
To configure incoming PSTN cause codes to SIP status codes, perform the following steps.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Map SIP Status Codes to PSTN Cause Codes
To map incoming SIP status codes to PSTN cause codes, complete the following steps.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configuring SIP Accept-Language Header Support
You can configure Accept-Language header support in two different configuration modes: voice service configuration mode and dial-peer voice configuration mode. The gateway first checks for languages configured under the dial-peer voice configuration mode and failing a match will then default to the global voice service configuration. If no languages are configured in either mode, then the header is not added.
Note
Perform this task to enable Accept-Language header support and specify languages carried in the Accept-Language header of SIP INVITE requests and OPTIONS responses.
SUMMARY STEPS
1.
2.
3.
or
dial-peer voice tag pots
4.
5.
DETAILED STEPS
Note
AR—Arabic
HE—Hebrew
ES—Spanish
ZH—Chinese
GA—Irish
SW—Swahili
EN—English
IT—Italian
SV—Swedish
EO—Esperanto
JA—Japanese
VI—Vietnamese
DE—German
KO—Korean
YI—Yiddish
EL—Greek
RU—Russian
ZU—Zulu
Configuring SIP Enhanced 180 Provisional Response Handling
This feature allows you to do the following:
•
•
Note
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configuring SIP Extensions for Caller Identity and Privacy
To configure SIP extensions for caller identify and privacy, perform the following steps.
•
•
•
Configure Remote Party-ID
This feature is enabled by default; no configuration tasks are required to enable this feature. If the feature is disabled by means of the no remote-party-id command, perform this task to re-enable the feature.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configure SIP-to-PSTN Calling-Info Policy
When Remote-Party-ID support is enabled, the default calling-info treatment is the following:
•
•
To override the default calling-info treatment, perform this task to optionally configure SIP to PSTN calling-info policy.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configure PSTN-to-SIP Calling-Info Policy
To override the default calling-info treatment, perform this task to optionally configure PSTN to SIP calling-info policy.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configuring SIP INVITE Request with Malformed Via Header
There are no configuration steps for this feature. Use the show sip-ua statistics command (see the "Verifying SIP Message Components, Session Timers, and Responses Configuration" section) to display the Bad Request counter.
Configuring Privacy Headers
You can configure privacy headers according to values defined in RFC 3323 and RFC 3325 as shown in Table 10.
Table 10 Privacy Header Values
Header
Indicates that the privacy service enforces privacy for all headers in the SIP message which might identify information about the subscriber.
Session
Indicates that the information held in the session description protocol (SDP) is hidden outside the trusted domain.
User
Enforces user-level privacy for the subscriber by removing any user identification from the SIP message.
Critical
Indicates that the message is rejected if the privacy service cannot or will not enforce the specified privacy.
Note
ID
Indicates the Network-Asserted Identity remains private with respect to SIP entries outside the user-authenticated trusted domain.
PSTN
Indicates information passed in from the PSTN Octet 3a of the CALLING PARTY Information Element enables privacy information on the VoIP side of the call (see Privacy Header PSTN with UAC Gateway).
System
Use system settings.
Disable
Disables the privacy.
UAC Gateway Behavior
When you configure the privacy command to use one of the header values shown in Table 9, 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.
Privacy Header PSTN with UAC Gateway
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.
Table 11 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.
Table 11 ISDN Octet 3a-to-SIP Header Mapping for UAC Gateways
Privacy Header PSTN with UAS Gateway
When you configure a privacy header for PSTN by using the privacy pstn command, a UAS gateway maps headers in the incoming SIP messages to Octet 3a fields on the outbound side of the call.
If a UAS gateway receives a message that has a Privacy header with a valid value, it ignores the privacy or asserted-id commands. The UAS gateway marks the outbound Octet 3a value Presentation Prohibited. If the UAS gateway does not receive a Privacy header, then the UAS gateway marks the outbound Octet 3a value as Presentation Allowed.
If a UAS gateway receives an Asserted-ID header, and a valid Privacy header is within the same message, then the UAS gateway uses the Asserted-ID to derive the ISDN Name and Number fields. If the UAS gateway receives an Asserted-ID with PAI, then the Octet 3a Number Origin is marked as "User Provided, passed network screening." If the received Asserted-ID is PPI, then the Octet 3a Number Origin is marked as "User provided, number not screened."
If a UAS gateway receives an Asserted-ID header that has no Privacy header in the same message, then the UAS gateway checks the asserted-id command. If you configure the asserted-id command, then the asserted-ID is used. Otherwise, the information in the "From" header is used to populate the appropriate ISDN fields.
Table 12 summarizes the relationship between the ISDN Octet 3a values and SIP header values that the UAS gateway generates on the outbound side of the call.
Table 12
SIP Header-to-ISDN Mapping for UAS Gateways
Interaction with Caller ID When Privacy Exists
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.
Table 13 summarizes the interaction when you configure the privacy pstn command.
Table 13
See Table 9.
See Table 9.
Not set.
If you do not configure the calling-info pstn-to-sip command, then see Table 9.
Presentation allowed.
User provided, not screened.
Unscreened discard.
From: <sip:example.com>; tag=1
Contact: <sip:example.com>Presentation allowed.
User provided number passed network screening.
Unscreened discard.
From: <sip:5551212@example.com>; tag=1
Contact: <sip:5551212@example.com:5060>
P-Asserted-Identity: <sip:5551212@example.com>Presentation allowed.
User provided number failed network screening.
Unscreened discard.
From: <sip:example.com>; tag=1
Contact: <sip:example.com>Presentation prohibited.
User provided, number.
Unscreened discard.
From: <sip:5551212@example.com>; tag=1
Contact: <sip:5551212@example.com:5060>
P-Asserted-Identity: <sip:5551212@example.com>Presentation prohibited.
User provided number, not screened.
Unscreened discard.
From: "Anonymous" <sip:anonymous@anonymous.com>; tag=1
Contact: <sip:example.com>
Privacy: IDPresentation prohibited
User provided number, failed network screening.
Unscreened discard
From: "Anonymous" <sip:anonymous@anonymous.com>; tag=1
Contact: <sip:example.com>
Privacy: IDPresentation prohibited
User provided number, passed network screening.
Unscreened discard
From: "Anonymous" <sip:anonymous@anonymous.com>; tag=1
P-Asserted-Identity:
Contact: <sip:5551212@example.com:>
Privacy: ID
Interactions When Using the privacy pstn Command
Configuring SIP Session Timer Support
To configure SIP session timer support including the Min-SE value, perform the following steps.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Configuring SIP: Cisco IOS Gateway Reason Header and Buffered Calling Name Completion
The SIP: Cisco IOS Gateway Reason Header and Buffered Calling Name Completion feature implements support for Reason headers and buffered calling-name completion. Reason-header support on Cisco IOS gateways is defined by RFC 3326.
Feature benefits include the following:
•
•
•
This section contains the following procedures:
•
•
Configure Reason-Header Override
To configure Reason-header override, perform the following steps.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configure Buffer Calling-Name Completion
To configure buffer calling-name completion, perform the following steps.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configuring SIP: SIP Header/URL Support and SUBSCRIBE/NOTIFY for External Triggers
This section contains the following procedures:
•
•
Configure SIP Header Support
To configure SIP header support, perform the following steps.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Configure SIP SUBSCRIBE and NOTIFY for External Triggers
To configure SIP subscription options, perform the following steps.
Prerequisites
•
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
DETAILED STEPS
Configuring SIP Stack Portability
No configuration tasks are required to configure the SIP stack portability feature. The feature is enabled by default.
Configuring SIP: Domain Name Support in SIP Headers
This section contains the following procedures:
•
•
Configure the Hostname in Locally Generated SIP Headers
You can configure the hostname in either of two configuration modes:
•
•
Note
Gateway-Wide Configuration Mode
This procedure allows global configuration of the local hostname for use for locally generated URIs.
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Dial-Peer-Specific Configuration Mode
This procedure allows dial-peer configuration of the local hostname for use for locally generated URIs.
Note
.SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Monitor the Hostname in Locally Generated SIP Headers
This procedure monitors the gateway-wide or dial-peer-specific configuration.
SUMMARY STEPS
1.
2.
3.
4.
DETAILED STEPS
Examples
This section provides the following command output:
•
•
show call active Command Output: Example
The following example shows active-call command output when the local hostname is enabled.
Router# show call active voiceTelephony call-legs:1SIP call-legs:1H323 call-legs:0Call agent controlled call-legs:0Multicast call-legs:0Total call-legs:2GENERIC:SetupTime=126640 msIndex=1PeerAddress=9001PeerSubAddress=PeerId=100PeerIfIndex=6LogicalIfIndex=4ConnectTime=130300 msCallDuration=00:00:47 secCallState=4CallOrigin=2ChargedUnits=0InfoType=speechTransmitPackets=2431TransmitBytes=48620ReceivePackets=2431ReceiveBytes=48620TELE:ConnectionId=[0xA0DC41CF 0x115511D9 0x8002EC82 0xAB4FD5BE]IncomingConnectionId=[0xA0DC41CF 0x115511D9 0x8002EC82 0xAB4FD5BE]CallID=1TxDuration=48620 msVoiceTxDuration=48620 msFaxTxDuration=0 msCoderTypeRate=g729r8NoiseLevel=-61ACOMLevel=3OutSignalLevel=-35InSignalLevel=-30InfoActivity=2ERLLevel=3SessionTarget=ImgPages=0CallerName=CallerIDBlocked=FalseOriginalCallingNumber=OriginalCallingOctet=0x0OriginalCalledNumber=OriginalCalledOctet=0x80OriginalRedirectCalledNumber=OriginalRedirectCalledOctet=0x0TranslatedCallingNumber=9001TranslatedCallingOctet=0x0TranslatedCalledNumber=TranslatedCalledOctet=0x80TranslatedRedirectCalledNumber=TranslatedRedirectCalledOctet=0x0GwCollectedCalledNumber=9002GENERIC:SetupTime=128980 msIndex=1PeerAddress=9002PeerSubAddress=PeerId=3301PeerIfIndex=7LogicalIfIndex=0ConnectTime=130300 msCallDuration=00:00:50 secCallState=4CallOrigin=1ChargedUnits=0InfoType=speechTransmitPackets=2587TransmitBytes=51740ReceivePackets=2587ReceiveBytes=51740VOIP:ConnectionId[0xA0DC41CF 0x115511D9 0x8002EC82 0xAB4FD5BE]IncomingConnectionId[0xA0DC41CF 0x115511D9 0x8002EC82 0xAB4FD5BE]CallID=2RemoteIPAddress=172.18.193.87RemoteUDPPort=17602RemoteSignallingIPAddress=172.18.193.87RemoteSignallingPort=5060RemoteMediaIPAddress=172.18.193.87RemoteMediaPort=17602RoundTripDelay=2 msSelectedQoS=best-efforttx_DtmfRelay=inband-voiceFastConnect=FALSEAnnexE=FALSESeparate H245 Connection=FALSEH245 Tunneling=FALSESessionProtocol=sipv2ProtocolCallId=A240B4DC-115511D9-8005EC82-AB4FD5BE@pip.example.comSessionTarget=172.18.193.87OnTimeRvPlayout=48620GapFillWithSilence=0 msGapFillWithPrediction=0 msGapFillWithInterpolation=0 msGapFillWithRedundancy=0 msHiWaterPlayoutDelay=70 msLoWaterPlayoutDelay=69 msTxPakNumber=2434TxSignalPak=0TxComfortNoisePak=0TxDuration=48680TxVoiceDuration=48680RxPakNumber=2434RxSignalPak=0RxDuration=0TxVoiceDuration=48670VoiceRxDuration=48620RxOutOfSeq=0RxLatePak=0RxEarlyPak=0PlayDelayCurrent=69PlayDelayMin=69PlayDelayMax=70PlayDelayClockOffset=43547PlayDelayJitter=0PlayErrPredictive=0PlayErrInterpolative=0PlayErrSilence=0PlayErrBufferOverFlow=0PlayErrRetroactive=0PlayErrTalkspurt=0OutSignalLevel=-35InSignalLevel=-30LevelTxPowerMean=0LevelRxPowerMean=-302LevelBgNoise=0ERLLevel=3ACOMLevel=3ErrRxDrop=0ErrTxDrop=0ErrTxControl=0ErrRxControl=0ReceiveDelay=69 msLostPackets=0EarlyPackets=0LatePackets=0SRTP = offVAD = enabledCoderTypeRate=g729r8CodecBytes=20Media Setting=flow-aroundCallerName=CallerIDBlocked=FalseOriginalCallingNumber=9001OriginalCallingOctet=0x0OriginalCalledNumber=9002OriginalCalledOctet=0x80OriginalRedirectCalledNumber=OriginalRedirectCalledOctet=0x0TranslatedCallingNumber=9001TranslatedCallingOctet=0x0TranslatedCalledNumber=9002TranslatedCalledOctet=0x80TranslatedRedirectCalledNumber=TranslatedRedirectCalledOctet=0x0GwCollectedCalledNumber=9002GwOutpulsedCalledNumber=9002GwOutpulsedCalledOctet3=0x80GwOutpulsedCallingNumber=9001GwOutpulsedCallingOctet3=0x0GwOutpulsedCallingOctet3a=0x0MediaInactiveDetected=noMediaInactiveTimestamp=MediaControlReceived=Username=LocalHostname=pip.example.com ! LocalHostname fieldTelephony call-legs:1SIP call-legs:1H323 call-legs:0Call agent controlled call-legs:0Multicast call-legs:0Total call-legs:2show call history Command Output: Example
The following example shows call-history command output when the local hostname is enabled.
Router# show call history voiceTelephony call-legs:1SIP call-legs:1H323 call-legs:0Call agent controlled call-legs:0Total call-legs:2GENERIC:SetupTime=128980 msIndex=1PeerAddress=9002PeerSubAddress=PeerId=3301PeerIfIndex=7LogicalIfIndex=0DisconnectCause=10DisconnectText=normal call clearing (16)ConnectTime=130300 msDisconnectTime=329120 msCallDuration=00:03:18 secCallOrigin=1ReleaseSource=4ChargedUnits=0InfoType=speechTransmitPackets=9981TransmitBytes=199601ReceivePackets=9987ReceiveBytes=199692VOIP:ConnectionId[0xA0DC41CF 0x115511D9 0x8002EC82 0xAB4FD5BE]IncomingConnectionId[0xA0DC41CF 0x115511D9 0x8002EC82 0xAB4FD5BE]CallID=2RemoteIPAddress=172.18.193.87RemoteUDPPort=17602RemoteSignallingIPAddress=172.18.193.87RemoteSignallingPort=5060RemoteMediaIPAddress=172.18.193.87RemoteMediaPort=17602SRTP = offRoundTripDelay=1 msSelectedQoS=best-efforttx_DtmfRelay=inband-voiceFastConnect=FALSEAnnexE=FALSESeparate H245 Connection=FALSEH245 Tunneling=FALSESessionProtocol=sipv2ProtocolCallId=A240B4DC-115511D9-8005EC82-AB4FD5BE@pip.example.comSessionTarget=172.18.193.87OnTimeRvPlayout=195880GapFillWithSilence=0 msGapFillWithPrediction=0 msGapFillWithInterpolation=0 msGapFillWithRedundancy=0 msHiWaterPlayoutDelay=70 msLoWaterPlayoutDelay=69 msReceiveDelay=69 msLostPackets=0EarlyPackets=0LatePackets=0VAD = enabledCoderTypeRate=g729r8CodecBytes=20cvVoIPCallHistoryIcpif=2MediaSetting=flow-aroundCallerName=CallerIDBlocked=FalseOriginalCallingNumber=9001OriginalCallingOctet=0x0OriginalCalledNumber=9002OriginalCalledOctet=0x80OriginalRedirectCalledNumber=OriginalRedirectCalledOctet=0x0TranslatedCallingNumber=9001TranslatedCallingOctet=0x0TranslatedCalledNumber=9002TranslatedCalledOctet=0x80TranslatedRedirectCalledNumber=TranslatedRedirectCalledOctet=0x0GwCollectedCalledNumber=9002GwOutpulsedCalledNumber=9002GwOutpulsedCalledOctet3=0x80GwOutpulsedCallingNumber=9001GwOutpulsedCallingOctet3=0x0GwOutpulsedCallingOctet3a=0x0MediaInactiveDetected=noMediaInactiveTimestamp=MediaControlReceived=LocalHostname=pip.example.com ! LocalHostname fieldUsername=GENERIC:SetupTime=126640 msIndex=2PeerAddress=9001PeerSubAddress=PeerId=100PeerIfIndex=6LogicalIfIndex=4DisconnectCause=10DisconnectText=normal call clearing (16)ConnectTime=130300 msDisconnectTime=330080 msCallDuration=00:03:19 secCallOrigin=2ReleaseSource=4ChargedUnits=0InfoType=speechTransmitPackets=9987TransmitBytes=199692ReceivePackets=9981ReceiveBytes=199601TELE:ConnectionId=[0xA0DC41CF 0x115511D9 0x8002EC82 0xAB4FD5BE]IncomingConnectionId=[0xA0DC41CF 0x115511D9 0x8002EC82 0xAB4FD5BE]CallID=1TxDuration=195940 msVoiceTxDuration=195940 msFaxTxDuration=0 msCoderTypeRate=g729r8NoiseLevel=-73ACOMLevel=4SessionTarget=ImgPages=0CallerName=CallerIDBlocked=FalseOriginalCallingNumber=OriginalCallingOctet=0x0OriginalCalledNumber=OriginalCalledOctet=0x80OriginalRedirectCalledNumber=OriginalRedirectCalledOctet=0x0TranslatedCallingNumber=9001TranslatedCallingOctet=0x0TranslatedCalledNumber=TranslatedCalledOctet=0x80TranslatedRedirectCalledNumber=TranslatedRedirectCalledOctet=0x0GwCollectedCalledNumber=9002Configuring SIP Gateway Support for Session Information
There are no tasks for configuring SIP gateway support for session information.
Configuring SIP Gateway Support for Permit Hostname CLI
To configure a list of hostname to validate against incoming INVITE messages, perform the following steps.
Restrictions
Hostname can be a maximum of 30 characters; hostnames longer than 30 characters are truncated.
SUMMARY STEPS
1.
2.
3.
4.
5.
DETAILED STEPS
Configuring Outbound Proxy Support for the SIP Gateway
This section describes the procedures for configuring an outbound-proxy server. These procedures include the following:
•
•
Configuring an Outbound-Proxy Server Globally on a Gateway
To configure SIP support for an outbound-proxy server globally on a SIP gateway, follow these steps:
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
DETAILED STEPS
Configuring an Outbound-Proxy Server on a Dial Peer
To configure an outbound-proxy server on a dial peer, follow these steps:
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
7.
DETAILED STEPS
Configuring SIP Support for PAI
This section provides procedures for configuring the following supplementary services:
•
•
Configuring a Privacy Header
To configure a privacy header in support of RFC 3323, follow these steps:
SUMMARY STEPS
1.
2.
3.
4.
5.
6.
Guest
