session initiation protocol (sip) for voip

1Cisco IOS Release 12.2(8)T and 12.2(11)T

Session Initiation Protocol (SIP) for VoIP

Document Update Alert

This document was originally produced for Cisco IOS Release 12.2(11)T. This feature has been updated in subsequent releases, and more recent documentation is available.

If you are using Cisco IOS Release 12.3 or higher, refer to the following documentation in the Cisco IOS Voice Configuration Library, Release 12.3:

• Cisco IOS SIP Configuration Guide

If you are using Cisco IOS Release 12.2 or higher, refer to the following chapter in the Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2:

• Configuring Session Initiation Protocol for Voice over IP

Feature History

Release Modification

12.1(1)T SIP was introduced on Cisco Access platforms.

12.1(3)T SIP Enhancements were implemented on Cisco 2600 series and Cisco 3600 series routers.

12.1(3)XI The ISDN Progress Indicator Support for SIP Using 183 Session Progress feature was introduced and implemented on Cisco 2600 series, Cisco 3600 series routers, and the Cisco AS5300 universal access server.

12.1(5)T The ISDN Progress Indicator Support for SIP Using 183 Session Progress feature was integrated into Cisco IOS Release 12.1(5)T.

12.2(2)T SIP Enhancements were integrated into Cisco IOS release 12.2(2)T and implemented on the Cisco AS5400 universal gateway.

The SIP User Agent MIB feature was introduced and implemented on the Cisco 2600 series and Cisco 3600 series routers.

The SIP Diversion Header Implementation for Redirecting Number feature was introduced and implemented on the Cisco 2600 series, Cisco 3600 series, and Cisco AS5300 universal access servers.

12.2(2)XA SIP and SIP Enhancements were integrated in Cisco IOS Release 12.2(2)XA and implemented on the Cisco AS5400 and AS5350 universal gateways.

http://www.cisco.com/univercd/cc/td/doc/product/software/ios123/123cgcr/vvfax_c/callc_c/sip_c/sipc1_c/index.htm

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fvvfax_c/vvfsip.htm

Session Initiation Protocol (SIP) for VoIP


This document describes the Session Initiation Protocol (SIP) for VoIP on Cisco 7200 series routers in Cisco IOS Release 12.2(8)T and contains the following sections:

• Feature Overview, page 3

• Supported Platforms, page 14

• Supported Standards, MIBs, and RFCs, page 15

• Prerequisites, page 16

• Configuration Tasks, page 16

• Configuration Examples, page 24

• Command Reference, page 32

• Glossary, page 94

12.2(2)XB The SIP Gateway Support for Bind Command, SIP Gateway Support of RSVP and TEL URL, SIP INVITE Request with Malformed Via Header, Configurable PSTN Cause Code to SIP Response Mapping, RFC2782 Compliance for DNS SRV, SIP T.38 Fax Relay, and Call Transfer Capabilities Using the Refer Method features were introduced on the Cisco 2600 series, Cisco 3600 series, Cisco 7200 series, Cisco AS5300 universal access server, Cisco AS5350 and Cisco AS5400 universal gateways.

12.2(2)XB1 The SIP T.38 Fax Relay feature was implemented on the Cisco AS5300 universal access server, Cisco AS5350, and AS5400 universal gateways.

SIP, SIP Enhancements, and SIP Gateway Support of RSVP and TEL URL features were implemented on the Cisco AS5850 universal gateway.

12.2(2)XB2 The SIP Gateway Support for Bind Command, Configurable PSTN Cause Code to SIP Response Mapping, Call Transfer Capabilities Using the Refer Method, and SIP T.38 Fax Relay features were implemented on the Cisco AS5850 universal gateway.

12.2(4)XM The ISDN Progress Indicator Support for SIP Using 183 Session Progress feature was implemented on Cisco 1700 series routers.

12.2(8)T SIP, and the following SIP features were implemented on the Cisco 7200 series routers: SIP Enhancements, DTMF Relay for SIP Calls Using Named Telephone Events, SIP User Agent MIB, ISDN Progress Indicator Support for SIP Using 183 Session Progress, SIP Diversion Header Implementation for Redirecting Number, SIP Gateway Support of RSVP and TEL URL, SIP Intra-gateway Hairpinning, SIP INVITE Request with Malformed Via Header, Configurable PSTN Cause Code to SIP Response Mapping, RFC 2782 Compliance for DNS SRV, Call Transfer Capabilities Using Refer, and SIP T.38 Fax Relay features were integrated into Cisco IOS Release 12.2(8)T and implemented on Cisco 7200 series routers.

Support for the Cisco AS5300 universal access server, Cisco AS5350, Cisco AS5400, and Cisco AS5850 universal gateway is not included in this release.

12.2(11)T This feature was integrated Cisco IOS Release 12.2(11)T on the Cisco AS5850 universal gateway.

Session Initiation Protocol (SIP) for VoIPFeature Overview


Feature OverviewSession Initiation Protocol (SIP)

Voice over Internet Protocol (VoIP) currently implements ITU’s H.323 specification within Internet Telephony Gateways (ITGs) to signal voice call setup. Session Initiation Protocol (SIP) is a protocol developed by the Internet Engineering Task Force (IETF) Multiparty Multimedia Session Control (MMUSIC) Working Group as an alternative to H.323. The Cisco SIP functionality equips Cisco routers to signal the setup of voice and multimedia calls over IP networks. SIP provides an alternative to H.323 within the VoIP internetworking software.

The SIP feature also provides nonproprietary advantages in the areas of:

• Protocol extensibility

• System scalability

• Personal mobility services

• Interoperability with different vendors

The SIP feature includes the following functionality:

• Configurable in-band alerting

• Ability to specify the maximum number of SIP redirects

• Ability to specify SIP or H.323 on a dial-peer basis

• Support for both User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) transport layers for SIP messages

• Powerful debugging support

• Support for Domain Name System Server (DNS SRV) records for resolving SIP server host names

• Configurable SIP message timers and retries

SIP Enhancements

Beginning in Cisco IOS Release 12.1(3)T, the following enhancements to SIP were introduced:

• Configurable SIP message timers and retries

• Interoperability with unified call services (UCS)

• Support for a variety of signaling protocols, including ISDN, PRI, and CAS

• Support for a variety of interfaces, including

– Analog interfaces: FXS/FXO/E&M analog interfaces

– Digital interfaces: T1 CAS and E1 CAS

• Support for SIP redirection messages and interaction with SIP proxies. The gateway can redirect an unanswered call to another SIP gateway or SIP-enabled IP phone. In addition, the gateway supports proxy-routed calls.

• Interoperability with DNS servers including support for DNS SRV and “A” records to look up SIP URLs

• Support for SIP over TCP and UDP network protocols

• Support for Routing Table Protocol/RTP Control Protocol (RTP/RTCP) for media transport in VoIP networks

• Support for the following codecs (see Table 1):



• Support for Record-Route headers

• Support for IP Quality of Service (QoS) and IP precedence

• Support for IP Security (IPSec) for SIP signalling messages

• Authentication, Authorization, and Accounting (AAA) support. For accounting, the gateway device generates call data record (CDR) accounting records for export. For authentication, the SIP Gateway sends validate requests to the AAA server. For authorization, the existing access lists are used.

• Support for configurable expiration time for SIP INVITEs and maximum number of proxies or redirect servers that can forward a SIP request

• Expanded support for the mapping of Public Switched Telephone Network (PSTN) cause codes to SIP events

• Ability to hide the calling party’s identity based on the setting of the ISDN presentation indicator

For more information, see the Configuring SIP for VoIP part in the Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2.

Call Transfer Capabilities Using the Refer Method

The Refer method provides call transfer capabilities to supplement the Bye and Also methods already implemented on Cisco IOS Session Initiation Protocol (SIP) gateways.

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 Voice over IP (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.

For more information, see the document Call Transfer Capabilities Using the Refer Method.

Configurable PSTN Cause Code to SIP Response Mapping

This feature allows customization of the standard RFC 2543 mappings between the Session Initiation Protocol (SIP) network and the Public Switched Telephone Network (PSTN).

For calls to be established between a SIP network and a PSTN, 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.

Table 1 SIP-Supported Codecs

Codec SDP

G711ulaw 0

G711alaw 8

G723r63 4

G726r16 2

G728 15

G729r8 18


http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fvvfax_c/index.htm

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122cgcr/fvvfax_c/index.htm

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122limit/122x/122xb/122xb_2/ftrefer.htm



However, you may want to customize the SIP user agent software to override the default mappings between the SIP network and the PSTN. The Configurable PSTN Cause Code to SIP Response 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.

For more information about this feature, including configuration tasks and examples, see the document Configurable PSTN Cause Code to SIP Response Mapping.

DTMF Relay for SIP Calls Using Named Telephone Events

The DTMF Relay for SIP calls Using Named Telephone Events (NTE) feature adds support for relaying DTMF tones and hookflash events in SIP on Cisco VoIP gateways.

Note The DTMF Relay for SIP Calls Using Named Telephone Events feature is implemented for SIP only.

Using NTE to relay dual tone multifrequency (DTMF) tones provides a standardized means of transporting DTMF tones in RTP packets according to section 3 of RFC 2833, RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals, developed by the Internet Engineering Task Force (IETF) Audio/Video Transport (AVT) working group. RFC 2833 defines formats of NTE RTP packets used to transport DTMF digits, hookflash, and other telephony events between two peer endpoints.

DTMF tones are generated when a button on a touch-tone phone is pressed. When the tone is generated, it is compressed, transported to the other party, and decompressed. If a low-bandwidth codec, such as a G.729 or G.723 is used without a DTMF relay method, the tone may be distorted during compression and decompression.

The DTMF Relay for SIP Calls Using NTE feature adds SIP functionality. SIP IP phones currently do not have the capability to generate DTMF tones. Currently, DTMF tones are transferred using Cisco Proprietary RTP or transparently in band. The DTMF Relay using NTE feature allows SIP phones calling voice mail or other interactive voice response (IVR) systems to relay DTMF tones. Additionally, this feature prevents distortion of DTMF tones if the RTP session uses a low bit-rate codec, because tones are passed in NTE packets and are not compressed using the default codec.

With the DTMF Relay Using NTE feature, the endpoints can perform per-call negotiation of the DTMF relay method. During call setup, the calling and called parties negotiate to choose the DTMF relay mode. They also negotiate to determine the payload type value for the NTE RTP packets.

In a SIP call, the gateway forms a session description protocol (SDP) message that indicates:

• If NTP will be used

• Which events will be sent using NTE

• NTE payload type value

The DTMF Relay Using NTE feature also provides hookflash support using in-band and out-of-band modes. In in-band mode, the gateway relays the hookflash without notifying the application, and the default session application and any IVR scripts do not receive the hookflash.

In out-of-band mode, the gateway reports the hookflash to the application and the application can relay the hookflash to the next call leg.

Note In addition, the DTMF Relay for SIP Calls Using NTE feature does not support hookflash generation for advanced features such as call waiting and conferencing.

For more information, see the document DTMF Relay Using Named Telephone Event.

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122limit/122x/122xb/122xb_2/ftmap.htm

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122limit/122x/122xb/122xb_2/ft_dtmf.htm





ISDN Progress Indicator Support for SIP Using 183 Session Progress

This feature provides support for handling inband treatments, such as call progress tones and announcements, when SIP is the session protocol for establishing call connections. The feature ensures the correct establishment of the media stream through the SIP network to allow the successful transport of in-band treatments, which might ingress from a PSTN node on a SIP gateway or egress to a PSTN node. The feature also allows VoIP calls using SIP to provide inband call treatment such as ringback tones, announcements when interworking with ISDN and channel associated signaling (CAS) PSTN networks.

SIP 183 Session Progress messages facilitate better call treatment for SIP VoIP calls when interworking with PSTN networks. The introduction of the 183 Session Progress message allows a called user agent to suppress local alerting from the calling user agent, and to play a tone or announcement during a preliminary call session, before the full SIP session is set up. This functionality enables the calling party to be notified of the status of the call without being charged for the preliminary portion of the call. A new Session header in the 183 Session Progress message controls whether or not the called user agent plays a tone or announcement for the calling party. The 183 Session Progress message is supported by default and does not require any special configuration.

RFC 2782 Compliance for DNS SRV

SIP on Cisco’s VoIP gateways uses DNS SRV query to determine the IP address of the SIP Proxy or the Redirect Server. The query string generated has a prefix in the form of “protocol.transport.” and is attached to the Fully Qualified Domain Name (FQDN) of the next hop SIP server. This prefix style from RFC 2052 has always been available; however, with this release a second style is also available. The second style is in compliance with RFC 2782, and prepends the protocol label with an underscore “_”; as in “_protocol._transport.”. The addition of the underscore reduces the risk of the same name being used for unrelated purposes.

Use the srv version command to configure the DNS SRV feature.

For more information, see the document SIP Gateway Support of RSVP and TEL URL.

SIP Diversion Header Implementation for Redirecting Number

The SIP Diversion Header Implementation for Redirecting Number feature provides support for a new SIP header field; Call Control (CC)-Diversion. The CC-Diversion header field enables the SIP gateway to pass call control redirecting information during the call setup. Call control redirection is the redirection of a call based on a subscriber service such as call forwarding. Call redirection information is information typically used for Unified Messaging and voice mail services to identify the recipient of a message. Call control rediversion information can also be used to support applications such as automatic call distribution, and enhanced telephony features such as Do Not Disturb and Caller ID.

If generated by the SIP gateway during call process, the CC-Diversion header field is based on the contents of the Redirecting Number Information Element (IE) in the ISDN Setup message. In addition, information such as the reason the call was redirected is included in the CC-Diversion header field.

For more information, see the document SIP Diversion Header Implementation for Redirecting Number.

SIP Gateway Support for Bind Command

Currently, Session Initial Protocol (SIP) signaling and media paths use an IP address that is provided by the IP layer as the source address. However, with the addition of the bind command, you can now configure the source IP address of signaling packets, or both signaling and media packets.

In previous releases of Cisco IOS software, the source address of a packet going out of the gateway was never deterministic. That is, the session protocols and VoIP layers always depended on the IP layer to give the best local address. The best local address was then used as the source address (the address

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122limit/122x/122xb/122xb_2/vvfresrv.htm

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121rel/sipcfs/hennigan.htm



showing where the SIP request came from) for signaling and media packets. Using this nondeterministic address occasionally caused confusion for firewall applications, as a firewall could not be configured with an exact address and would take action on several different source address packets.

However, the bind interface command allows you to configure the source IP address of signaling and media packets to a specific interface’s IP address. Thus, the address that goes out on the packet is bound to the IP address of the interface specified with the bind command. Packets that are not destined to the bound address are discarded.

When you do not want to specify a bind address, or if the interface is down, the IP layer still provides the best local address.

The bind command performs different functions based on the state of the interface.

For more information, see the document SIP Gateway Support for the Bind Command.

SIP Gateway Support of RSVP and TEL URL

The SIP Gateway Support of RSVP and TEL URL feature provides the following SIP enhancements:

• RSVP

• Telephone URL format in SIP messages

• Interaction with forking proxies

• SIP intra-gateway hairpinning

• Reliability of SIP provisional responses

• Configurable screening indicator

• RFC 2782 Compliance (style of DNS SRV queries)

For more information, see the document SIP Gateway Support of RSVP and TEL URL.

SIP Intra-Gateway Hairpinning

SIP hairpinning is a call routing capability in which an incoming call on a specific gateway is signaled through the IP network and back out the same gateway. This can be a Public Switched Telephone Network (PSTN) call routed into the IP network and back out to the PSTN over the same gateway, as shown below:

Similarly, SIP hairpinning can be a call signaled from a line (for example, a telephone line) to the IP network and back out to a line on the same access gateway:

With SIP hairpinning, unique gateways for ingress and egress are no longer necessary.

For more information about the SIP Intra-Gateway Hairpinning feature, including configuration tasks and examples, see the document SIP Gateway Support of RSVP and TEL URL.

PSTNGateway

call id - x

call id - x

IP network

3769

8

Line 1

Line 2

Gatewaycall id - y

call id - y

IP network

3769

9

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122limit/122x/122xb/122xb_2/ftbind.htm





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 This feature applies to messages arriving on UDP, because the Via header is not used to respond to messages arriving on TCP.

For more information about this feature, see the document SIP INVITE Request with Malformed Via Header.

SIP T.38 Fax Relay

The SIP T.38 Fax Relay feature adds standards-based fax support to SIP and conforms to ITU-T T.38, Procedures for real-time Group 3 facsimile communication over IP networks. The ITU-T standard specifies real-time transmission of faxes between two regular fax terminals over an IP network.

Much like a voice call, SIP T.38 Fax Relay requires call establishment, data transmission, and release signaling. The following figure shows the basic setup of SIP T.38 Fax Relay:

For more information, including configuration tasks and examples, see the document SIP T.38 Fax Relay.

SIP User Agent MIB

The SIP User Agent MIB addresses the need for SIP-specific gateway information to be made available by Simple Network Management Protocol (SNMP). The implementation of this capability is based upon the current IETF draft “draft-ietf-sip-mib-01.txt”.

The implementation of the SIP MIB in the Cisco SIP gateway supports configuration objects related to SIP such as the configured SIP server, SIP timers, and number of retry attempts allowed for requests and responses.

The SIP MIB also supports SIP-specific statistical information objects. This includes information on numbers of provisional responses, success responses, redirection responses, client error responses, server error responses, and global error responses. In addition, the SIP MIB includes information regarding SIP Requests initiated and received as well as information about retries associated with each SIP Request type.

T.38 path

IP network

SIPoriginating gateway

SIPterminating gateway 62

318

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122limit/122x/122xb/122xb_2/ftmalvia.htm

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122limit/122x/122xb/122xb_2/ftmalvia.htm

http://www.cisco.com/univercd/cc/td/doc/product/software/ios122/122newft/122limit/122x/122xb/122xb_2/ftsipfax.htm



Benefits

Session Initiation Protocol

The SIP feature meets the needs of service providers that use SIP on the gateways of their VoIP network to:

• Enable Cisco voice-enabled platforms to provide RFC 2543-compliant user-agent client gateways

• Support codecs capable of Carrier-class voice quality

Although SIP is simpler than H.323, SIP provides similar capabilities in:

• System scalability

• End-to-end solutions

• High-density voice gateways

SIP Enhancements

The SIP feature enhancements enable SIP gateways to:

• Enable Cisco voice-enabled platforms to provide RFC 2543-compliant user-agent client gateways

• Support proxy-routed calls

• Redirect an unanswered call to another SIP gateway or SIP-enabled IP phone

• Allow end users to place calls on hold

• Hide the calling party’s identity based on the setting of the ISDN presentation indicator


• SIP Call Transfer Using the Refer Method supports attended transfer and blind transfer in accordance with emerging SIP standards.


• The Configurable PSTN Cause Code to SIP Response Mapping feature offers control and flexibility. By using command-line interface 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.


• DTMF relay support for SIP

• Hookflash relay support for SIP

• Simultaneous support with Cisco Proprietary RTP (used for modem passthrough and modem relay)

• Provisioning of RTP payload type values

• Per-call negotiation of relay method and payload type values

• More accurate tone delivery

• Interoperability with SIP applications from other vendors




• Ensures that in-band treatments initiated in the PSTN are successfully transported through the SIP network

• Allows for internetworking of features between the PSTN and the SIP network so that the correct inband feedback is provided to the feature user


• Compliance with RFC 2782 brings DNS compatibility. RFC 2782 updates RFC 2052 by prepending the protocol label with an underscore “_”. This change reduces the risk of the same name being used for unrelated purposes. However, backward compatibility is available, allowing newer versions of IOS software to work with older networks that only support RFC 2052.

• Currently you must know the exact address of a server to contact it. SRV records enable administrators to use several servers to provide the same service within a single domain. SRV Resource Records (RRs) allow administrators to define primary and backup servers and move services from host-to-host without affecting service.


• Provides support for the Call Control (CC)-Diversion SIP header field

• Enables the SIP gateway to pass call control redirecting information during the call setup

• Redirection of a call based on a subscriber service such as call forwarding

• Unified Messaging and voice mail services to identify the recipient of a message

• Support of applications such as automatic call distribution, and enhanced telephony features such as Do Not Disturb and Caller ID

SIP Gateway Support for the Bind Command

• With the bind command, SIP signaling and media paths can advertise the same source IP address on the gateway for certain applications, even if the paths used different addresses to reach the source. This eliminates confusion for firewall applications that, prior to the use of binding, may have taken action on several different source address packets.


• SIP Gateway Support of RSVP and TEL URL enables QoS, ensuring certain bandwidth reservations for specific calls. The bandwidth reservation can be best-effort, in which case the call is completed even if the reservation is not supported by both sides or cannot be established. Or the bandwidth reservation can be required, and the call is not set up if the bandwidth reservation is not performed successfully.

• With the reliable provisional response features, you can ensure that media information is exchanged and resource reservation takes place before connecting a call.

• Forked call responses to Cisco IOS gateways are now supported. Call forking enables the terminating gateway to handle multiple requests and the originating gateway to handle multiple provisional responses for the same call. Call forking is required for the deployment of the find me/follow me type of services.

• Gateways now accept TEL calls sent through the Internet, which provides interoperability with other equipment that uses TEL URL. The TEL URL feature also gives service providers a way to differentiate services based on the type of call, allowing for deployment of specific services.




• Hairpinning enables the same gateway to originate and terminate a call. It works independently of, but enhances, call forking. It also enables call control features to function when it is required that an incoming PSTN call is routed back out to the PSTN on the same Cisco gateway.


• Incrementing a counter and sending a response, rather than simply discarding the INVITE, if it contains a malformed Via header. The counter provides a useful and immediate indication that an INVITE has been discarded, and the response allows the result to be propagated back to the sender.

SIP T.38 Fax Relay

• Cisco furthers its commitment to open standards and to the success of its customers by supporting standards such as ITU-T T.38, Procedures for real-time Group 3 facsimile communication over IP networks and T-38 Annex-D.

• T.38 Fax Relay over packet networks has become a popular way to bypass tolls associated with sending faxes. SIP T.38 Fax Relay provides standards-based toll bypass for both fax and voice calls. Toll bypass capabilities can result in cost savings to end users of packet telephony networks.

• A Cisco originating gateway (OGW) that has T.38 support automatically enters T.38 mode if it receives a T.38 INVITE, even if it is configured for the Cisco proprietary Fax Relay. This choice of fax protocols provides an extremely reliable fax transfer mechanism.

• Currently, SIP uses the Cisco proprietary Fax Relay solution. However, Cisco Fax Relay is sometimes not an ideal solution for enterprise and service provider customers who have implemented a multivendor network. Because the T.38 Fax Relay protocol is standards-based, Cisco gateways and gatekeepers can operate with third-party T.38-enabled gateways and gatekeepers in a multivendor network where real-time Fax Relay capabilities are required.

• T.38 Fax Relay is already implemented in Cisco gateways that support H.323 and Media Gateway Control Protocol (MGCP). The addition of T.38 for SIP strengthens SIPs position as a low-cost standards-based infrastructure, and increases its viability as the protocol of choice for next-generation IP networks.

SIP User Agent MIB

• The SIP User Agent MIB provides SIP-specific information via SNMP—this information allows customers to have SIP-specific information available to evaluate the performance of gateways in conjunction with their SIP networks.

Restrictions

SIP

Ensure that your access platform has 16 MB Flash memory and 64 MB DRAM memory minimum, and that I/O memory is set to either 8 or 16 MB.

SIP Enhancements

• The SIP Gateway does not support codecs other than those listed in Table 1 on page 4.

– If on the originating gateway, an appropriate SIP debug trace is presented, indicating the failure to originate the SIP call leg.

– If on the terminating gateway, an appropriate SIP response (4xx) with a warning indicating incompatible media types is sent.

• The SIP Gateway requires each INVITE to include a Session Description Protocol (SDP) header.



• The contents of the Session Description Protocol (SDP) header cannot change between the 180 Ringing message and the 200 OK message.

• SIP requires that all times be sent in Greenwich Mean Time (GMT). The INVITE is sent with GMT. However, the default for routers is to use Coordinated Universal Time (UTC). To configure the router to use GMT, issue the clock timezone command in global configuration mode and specify the GMT time.

• The Enhancements to SIP for VoIP feature supports plain old telephone service (POTS) to POTS hairpinning (which means the call comes in one voice port and is router out another voice port). It also supports POTS to IP call legs and IP to POTS call legs. However, it does not support IP to IP hairpinning. This means the SIP Gateway cannot take an inbound SIP call and reroute it back to another SIP device using the VoIP dial peers.

• SIP requires that all times be sent in Greenwich Mean Time (GMT). The INVITE is sent with GMT. However, the default for routers is to use Coordinated Universal Time (UTC). To configure the router to use GMT, issue the clock timezone command in global configuration mode and specify the GMT.

• VoIP dial peers allow a user to configure the bytes parameter associated with a codec. However, Cisco SIP gateways currently do not present or respond to this parameter. Currently, the a=ptime parameter is not sent or recognized in the SDP body of a SIP message.

• With call transfer, the Requested-By header identifies the party initiating the transfer. The Requested-By header is included in the INVITE request that is sent to the transferred-to party only if a Requested-By header was also included in the Bye request.

• With call transfer, the Also header identifies the transferred-to party. To invoke a transfer, the user portion of the Also header must be defined explicitly or with wildcards as a destination pattern on a VoIP dial peer. The transferred call is routed using the session target parameter on the dial peer instead of the host portion of the Also header. Therefore, the Also header can contain user@host but the host portion is ignored for call routing purposes.

• The grammar for the Also and Requested-By headers is not fully supported. Only the name-addr header is supported. This implies that the crypto-param, which might be present in the Bye request, will not be populated in the ensuing INVITE to the transferred-to party.

• Cisco SIP Gateways do not support the user=np-queried parameter in a Request URI.

• If a Cisco SIP Gateway receives an ISDN Progress message, it generates a 183 Session Progress message. If the gateway receives an ISDN ALERT, it generates a 180 Ringing message.


• Although SIP IOS gateways currently support SIP URLs and TEL URLs, the Refer-To header must be in SIP URL format to be valid. The TEL URL format cannot be used, because it does not provide a host portion, and without one, the triggered Invite request cannot be routed.

• Only three overloaded headers in the Refer-To header are accepted: Accept-Contact, Proxy-Authorization, and Replaces. All other headers present in the Refer-To are ignored.

• The Refer-To and Contact headers are required in the Refer request. The absence of either header results in a 4xx class response to the Refer request. Also, the Refer request must contain exactly one Refer-To header. Multiple Refer-To headers result in a 4xx class response.

• The Referred-By header is required in a Refer request. The absence of this header results in a 4xx class response to the Refer request. Also, the Refer request must contain exactly one Referred-By header. Multiple Referred-By headers result in a 4xx class response.

• As with the Bye and Also call transfer methods, the dial peers must be configured for correct functioning of the Refer method.




• The DTMF Relay for SIP calls Using Named Telephone Events feature is only available on Cisco VoIP gateways using SIP. The DTMF Relay for SIP Calls Using NTE feature does not support hookflash generation for advanced features such as call waiting and conferencing.


• Support for interaction with forking proxies applied only to gateways acting as a user agent client (UAC) is not supported. It does not apply when the gateway acts as a user agent server (UAS). In that case, the proxy forks multiple INVITES with the same call ID to the same gateway but with different request URLs.

• Forking functionality sets up RSVP for each transaction only if the dial peers are configured for QoS. If not, the calls proceed as best-effort. Bandwidth reservation (QoS) is not supported for Session Description Protocol (SDP changes between 183 Session Progress/180 Alerting and 200 OK responses).

• Bandwidth reservation (QoS) is not attempted if the desired QoS level is set to the default of best-effort. The desired QoS for the associated dial peer must be set to controlled-load or guaranteed-delay.

• Distributed Call Signaling (DCS) headers and extensions are not supported.


• Distributed Call Signaling (DCS) headers and extensions are not supported.

SIP T.38 Fax Relay

• For SIP T.38 Fax Relay only UDP is supported for the transport layer.

• If SIP T.38 Fax Relay is not supported by both gateways, the T.38 negotiation fails and the call reverts back to an audio codec.

• T.38 Fax Relay requires 64 Kbps, the same amount of bandwidth as a voice call with the G.711 codec.

• Calling tones (CNG) are optional, and are not used to initiate a switch to T.38 mode. Instead, called terminal identification tones (CED) or preamble flags are used.

• This feature does not rely on named signaling events (NSE) to signal a switch to T.38 mode. Standard RFC 2543 and RFC 2327 SIP and SDP signaling are used instead.

Note The transport protocols specified in the ITU-T Recommendation for T.38 are Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). However, only UDP is supported for Cisco IOS Release 12.2(2)XB. For further information on T.38 protocol, refer to the ITU-T Recommendations.

Related Features and Technologies• Cisco Fax Relay

• Cisco IP Phones

• Cisco QoS

• Cisco RSVP

• Cisco SIP Proxy Server

Session Initiation Protocol (SIP) for VoIPSupported Platforms


• Cisco TCL/IVR Version 2.0

• Cisco VoIP

Related DocumentsThe following documents contain information related to Cisco SIP functionality:

• Cisco IOS IP Configuration Guide, Release 12.2

• Cisco IOS IP Command Reference, Volume 1 of 3: Addressing and Services, Release 12.2

• Cisco IOS IP Command Reference, Volume 2 of 3: Routing Protocols, Release 12.2

• Cisco IOS IP Command Reference, Volume 3 of 3: Multicast, Release 12.2

• Cisco IOS Quality of Service Solutions Command Reference, Release 12.2

• Cisco IOS Voice, Video, and Fax Command Reference, Release 12.2

• Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2

• Cisco IP Telephony Network Design Guide

• Configuring Session Initiation Protocol for Voice over IP

• Dial Peer Enhancements

• Service Provider Features for Voice over IP, Release 12.0(3)T

• Session Initiation Protocol Call Flows

• Session Initiation Protocol Gateway Call Flows

• Session Initiation Protocol Gateway Call Flows and Compliance Information

• SIP Call Flows, Release 12.2(4)T

• SIP Diversion Header Implementation for Redirecting Number

• SIP Gateway Support of RSVP and TEL URL, Release 12.2(2)XB

• TCL IVR API Version 2.0 Programmer's Guide

• VoIP Call Admission Control Using RSVP chapter in the Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2

• Voice over IP for the Cisco 2600/3600 Series

Supported Platforms• Cisco 2691

• Cisco 3631

• Cisco 3725

• Cisco 3745

• Cisco 7200 series

• Cisco AS5850

http://www.cisco.com/univercd/cc/td/doc/product/voice/ip_tele/network/index.htm


http://www.cisco.com/univercd/cc/td/doc/product/access/acs_serv/5300/sw_conf/voip/sprvvoip.htm

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t1/sipcf.htm

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121rel/sipcfs/index.htm

http://www.cisco.com/univercd/cc/td/doc/product/software/ios121/121newft/121t/121t3/sipcf2.htm



Session Initiation Protocol (SIP) for VoIPSupported Standards, MIBs, and RFCs


Determining Platform Support Through Cisco Feature Navigator

Cisco IOS software is packaged in feature sets that support specific platforms. To get updated information regarding platform support for this feature, access Cisco Feature Navigator. Cisco Feature Navigator dynamically updates the list of supported platforms as new platform support is added for the feature.

Cisco Feature Navigator is a web-based tool that enables you to quickly determine which Cisco IOS software images support a specific set of features and which features are supported in a specific Cisco IOS image. You can search by feature or release. Under the release section, you can compare releases side by side to display both the features unique to each software release and the features in common.

To access Cisco Feature Navigator, you must have an account on Cisco.com. If you have forgotten or lost your account information, send a blank e-mail to [email protected]. An automatic check will verify that your e-mail address is registered with Cisco.com. If the check is successful, account details with a new random password will be e-mailed to you. Qualified users can establish an account on Cisco.com by following the directions at http://www.cisco.com/register.

Cisco Feature Navigator is updated regularly when major Cisco IOS software releases and technology releases occur. For the most current information, go to the Cisco Feature Navigator home page at the following URL:

http://www.cisco.com/go/fn

Supported Standards, MIBs, and RFCsStandards

• ITU-T T.38, Procedures for real-time Group 3 facsimile communication over IP networks

• ITU-T T.38, Procedures for real-time Group 3 facsimile communication over IP networks, Amendment 1

• ITU-T, T.38, Annex-D

MIBs

• CISCO-SIP-UA-MIB

To obtain lists of supported MIBs by platform and Cisco IOS release, and to download MIB modules, go to the Cisco MIB website on Cisco.com at the following URL:

http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml

RFCs

• RFC 1890, RTP Profile for Audio and Video Conferences with Minimal Control

• RFC 2327, SIP/SDP Signaling

• RFC 2543, SIP: Session Initiation Protocol

• RFC 2728, A DNS RR for Specifying the Location of Services (DNS SRV)

• RFC 2806, URLs for Telephone Calls

• RFC 2833, RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals

http://www.cisco.com/register

http://www.cisco.com/register

http://www.cisco.com/go/fn

http://www.cisco.com/public/sw-center/netmgmt/cmtk/mibs.shtml

Session Initiation Protocol (SIP) for VoIPPrerequisites


PrerequisitesGeneral SIP Prerequisites

• Your gateway must have voice functionality that is configurable for either SIP.

• Establish a working IP network.

• Configure VoIP.

• Ensure that your Cisco 2600 series, Cisco 3600 series, or Cisco 7200 series router has 16-MB Flash memory and 64-MB DRAM memory, minimum.


• Set the bind address prior to using the bind command.


• Configure the SIP dial peers for call transfer.

As with the Bye and Also call transfer methods, the dial peers must be configured for correct functioning of the Refer method. See the document Call Transfer Capabilities Using the Refer Method for complete configuration steps.

Configuration TasksSIP

See the following sections for configuration tasks for basic SIP functions. Each task in the list is identified as either required or optional.

• Configuring the SIP User Agent (UA) (required)

• Changing the Configuration of the SIP User Agent (UA) (optional)

• Configuring SIP Support for VoIP Dial Peers (optional)

• Configuring a POTS Dial Peer (optional)

• Configuring SIP Call Transfer for a POTS Dial Peer (optional)

• Configuring SIP Call Transfer for a VoIP Dial Peer (optional)

• Configuring Phone Number Translation Rules (required)

• Verifying the SIP Feature Configuration (optional)

For more information on SIP configuration, including call flows, refer to the Session Initiation Protocol Call Flows document.


For configuration tasks for this feature, see the document Call Transfer Capabilities Using the Refer Method.


For configuration tasks for this feature, see the document Configurable PSTN Cause Code to SIP Response Mapping.









Session Initiation Protocol (SIP) for VoIPConfiguration Tasks


Dual Tone Multifrequency Relay for SIP Calls Using Named Telephone Events

For configuration tasks for this feature, see the document Dual Tone Multifrequency Relay for SIP Calls Using Named Telephone Events.


There are no configuration tasks for this feature.


For configuration tasks for this feature, see the document SIP Gateway Support of RSVP and TEL URL.


For configuration tasks for this feature, see the document SIP Diversion Header Implementation for Redirecting Number.


For configuration tasks for this feature, see the document SIP Gateway Support for Bind Command.


For configuration tasks for this feature, see the document SIP Gateway Support of RSVP and TEL URL.





SIP T.38 Fax Relay

For configuration tasks for this feature, see the document SIP T.38 Fax Relay.

SIP User Agent MIB












Configuring the SIP User Agent (UA)A terminating gateway that is not configured as an SIP user agent cannot receive incoming SIP calls. The transport command opens the SIP listener port (5060) to receive SIP (a SIP user agent is configured to listen by default).

To configure the terminating gateway, enter the following commands beginning in global configuration mode:

Changing the Configuration of the SIP User Agent (UA)It is not necessary to configure a SIP UA in order to place a call. A SIP UA is configured to listen by default. However, if you want to adjust any of the settings, you can do so using the following commands beginning in global configuration mode:

Command Purpose

Step 1 Router(config)# sip-ua Enters SIP user-agent mode to configure SIP UA-related commands.

Step 2 Router(config-sip-ua)# transport {udp | tcp}

Configures the SIP user agent (sip-ua) for SIP signaling messages. The default value is udp.

• udp—Configures the SIP user agent to receive SIP messages on UDP port 5060.

• tcp—Configures the SIP user agent to receive SIP messages on TCP port 5060.

Step 3 Router(config-sip-ua)# sip-server ipv4:ip-address

Enters the IP address of the SIP server interface.

Step 4 Router(config-sip-ua)# timers trying number

Sets time to wait for a response.

• number—Time (in milliseconds) to wait for a 100 response to an INVITE request. Possible values are 100 through 1000. The default is 500.

Step 5 Router(config-sip-ua)# retry invite number

Configures the SIP signaling timers for retry attempts.

• number—Number of INVITE retries: 1 through 10 are valid inputs; default = 6.

Command Purpose

Step 1 Router(config)# sip-ua Enters SIP user agent (sip-ua) mode to configure SIP UA-related commands.

Step 2 Router(config-sip-ua)# transport {udp | tcp}

Configures the SIP user agent (sip-ua) for SIP signaling messages. The default value is udp.





Step 3 Router(config-sip-ua)# sip-server {dns: host-name | ipv4:ip-address [port-number]}

Enters the host name or IP address of the SIP server interface.

• dns:—Sets the global SIP server interface to a DNS.

• host-name—A valid DNS host name takes the following format: gateway.company.com.

• ipv4:ip-address—Sets the global SIP server interface to an IP address. A valid IP address takes the following format: xxx.xxx.xxx.xxx.

• port-number—(Optional) Specifies the port number for the SIP server.

Step 4 Router(config-sip-ua)# timers trying number

Sets time to wait for a response.

• number—Time (in milliseconds) to wait for a 100 response to an INVITE request. Possible values are 100 through 1000. The default is 500.

Step 5 Router(config-sip-ua)# timers expires number

Limits the time duration (in milliseconds) of a search for an INVITE.

• number—Specifies the time (in milliseconds) for which an INVITE request is valid. Possible values are 60000 through 300000. The default is 180000.

Step 6 Router(config-sip-ua)# retry invite number

Configures the SIP signaling timers for retry attempts.

• number—Specifies the number of INVITE retries. Valid values are 1 through 10. The default is 6.

Step 7 Router(config-sip-ua)# max-forwards number

Limits the number of proxy or redirect servers that can forward a request.

• number—Number of hops. Valid values are 1 through 15. The default is 6.

Command Purpose



Configuring SIP Support for VoIP Dial PeersTo configure SIP support for a VoIP dial peer, enter the following commands beginning in global configuration mode:

Command Purpose

Step 1 Router(config)# dial-peer voice tag voip Enters dial-peer configuration mode to configure a VoIP dial peer.

• tag—Digits that define a particular dial peer. Valid entries are from 1 to 2,147,483,647.

Step 2 Router(config-dial-peer)# destination-pattern [+]string[T]

Defines the telephone number associated with this VoIP dial peer.

• +—(Optional) Character indicating an E.164 standard number.

• string—Series of digits that specify the E.164 or private dialing plan telephone number. Valid entries are the digits 0 through 9, the letters A through D, and the following special characters:

– The asterisk (*) and pound sign (#) that appear on standard touch-tone dial pads. On the Cisco 3600 series routers only, these characters cannot be used as leading characters in a string (for example, *650).

– Comma (,), which inserts a pause between digits.

– Period (.), which matches any entered digit (this character is used as a wildcard). On the Cisco 3600 series routers, the period cannot be used as a leading character in a string (for example, .650).

– Percent sign (%), which indicates that the previous digit/pattern occurred zero or multiple times, similar to the wildcard usage in the regular expression.

– Plus sign (+), which matches a sequence of one or more matches of the character/pattern.

Note The plus sign used as part of the digit string is different from the plus sign that can be used in front of the digit string to indicate that the string is an E.164 standard number.



Configuring a POTS Dial PeerTo configure a POTS dial peer, enter the following commands beginning in global configuration mode:

– Circumflex (^), which indicates a match to the beginning of the string.

– Dollar sign ($), which matches the null string at the end of the input string.

– Backslash symbol (\), which is followed by a single character matching that character or used with a single character with no other significance (matching that character).

– Question mark (?), which indicates that the previous digit occurred zero or one time.

– Brackets ( [ ] ), which indicate a range. A range is a sequence of characters enclosed in the brackets; only numeric characters from 0 to 9 are allowed in the range. This is similar to a regular expression rule.

– Parentheses “( )”, which indicate a pattern and is the same as the regular expression rule.

• T—(Optional) Control character indicating that the destination-pattern value is a variable length dial string.

Step 3 Router(config-dial-peer)# session transport {udp | tcp}

Enters the session transport type for the SIP user agent.



Step 4 Router(config-dial-peer)# session protocol sipv2

Enters the session protocol type as IETF Session Inititation Protocol.

Step 5 Router(config-dial-peer)# session target sip-server

Specifies the dial peer session target to use the global SIP server.

Command Purpose

Command Purpose



Defines the telephone number associated with this POTS dial peer.

Step 3 Router(config-dial-peer)# port slot-number/subunit-number/port

Associates this POTS dial peer with a specific voice port.

Step 4 Router(config-dial-peer)# session transport {udp | tcp}

Enters the session transport type for the SIP user agent.

Step 5 Router(config-dial-peer)# session protocol sipv2

Enters the session protocol type.

Step 6 Router(config-dial-peer)# session target sip-server

Specifies the dial peer session target to use the global SIP server.



Configuring SIP Call Transfer for a POTS Dial PeerTo configure SIP call transfer for a POTS dial peer, enter the following commands beginning in global configuration mode:

Configuring SIP Call Transfer for a VoIP Dial PeerTo configure SIP call transfer for a VoIP dial peer, enter the following commands beginning in global configuration mode:

Configuring Phone Number Translation RulesBy default, the SIP gateway tags called numbers that have 11 or more digits as “international” when sending SETUP messages to the PSTN switch. In some cases, such as situations where the user must dial 9 to access an outside line, this assumption may not be correct.

To accommodate such situations, you can define translation rules on the outbound POTS dial peer to convert the “type of number” to the correct value. Translation rules manipulate the called number digits and the “type of number” value associated with the called digits.

Command Purpose

Step 1 Router(config)# dial-peer voice tag pots Enters dial-peer configuration mode to configure a POTS dial peer.

Step 2 Router(config-dial-peer)# application session

Specifies that the standard session application will be invoked for this dial peer.


Specifies the telephone number associated with the dial peer.

Step 4 Router(config-dial-peer)# port slot/port Specifies the voice slot number and port through which incoming VoIP calls are received.

Command Purpose


Step 2 Router(config-dial-peer)# application session

Specifies that the standard session application will be invoked for this dial peer.


Specifies the telephone number associated with the dial peer.

Step 4 Router(config-dial-peer)# session target ipv4:ip-address

Specifies the IP address of the destination gateway for outbound dial peers.



To define translation rules on a POTS dial peer, enter the following commands beginning in global configuration mode:

For more information about the commands used to configure translation rules, see the Dial Peer Enhancements documentation on Cisco.com.

Verifying the SIP Feature Configuration Enter the show running configuration command to verify your configuration.

Command Purpose

Step 1 Router(config)# translation-rule name-tag Defines a translation-rule tag number and enters translation-rule configuration mode. All subsequent commands that you enter in this mode before you exit will apply to this translation-rule tag.

• name-tag—The tag number by which the rule set will be referenced. This is an arbitrarily chosen number. The range is 1 through 2,147,483,647.

Step 2 Router(config-translate)# rule name-tag input-matched-pattern substituted-pattern [match-type substituted-type]

Specifies translation rules. This command can be entered multiple times and is applied to the translation-rule defined in Step 1.

• name-tag—The tag number by which the rule set will be referenced. This is an arbitrarily chosen number. Range is from 1 through 2,147,483,647.

• input-matched-pattern— The input string of digits for which pattern matching is performed.

• substituted-pattern—The replacement digit string that results after pattern matching is performed. Regular expressions are used to carry out this process.

• match-type—(Optional) The choices for this field are, abbreviated, any, international, national, reserved, subscriber, and unknown, as defined by the International Telecommunication Union Telecommunication Standardization Sector (ITU-T) Q.931 specification. If you enter the match-type value, then you must also enter the substituted-type value.

• substituted-type—(Optional) The choices for this field are abbreviated, international, national, reserved, subscriber, and unknown, as defined by the ITU Q.931 specification.

Step 3 Router(config-translate)# exit Exits from translate configuration mode.

Step 4 Router(config)# dial-peer voice tag pots Enter the dial-peer mode to configure a POTS dial peer.

Step 5 Router(config-dial-peer)# translate-outgoing called name-tag

Specifies the translation tag for an outbound called number.

• name-tag—Translation rule tag. Valid values are 1 to 2,147,483,647.

Step 6 Router(config-dial-peer)# port slot-number/port

Specifies the voice port.

Session Initiation Protocol (SIP) for VoIPConfiguration Examples


Configuration ExamplesThis section provides the following configuration examples:

• Basic SIP Configuration Example

• Configuring SIP with Multiple Codecs Example

• Configuring Phone Number Translation Rules Examples

• Call Transfer Configuration Examples


For configuration examples for this feature, see the document Call Transfer Capabilities Using the Refer Method.


For configuration examples for this feature, see the document Configurable PSTN Cause Code to SIP Response Mapping.


For configuration examples for this feature, see the document Dual Tone Multifrequency Relay for SIP Calls Using Named Telephone Events.


There are no configuration examples for this feature.


For configuration examples for this feature, see the document SIP Gateway Support of RSVP and TEL URL.


For configuration examples for this feature, see the document SIP Diversion Header Implementation for Redirecting Number.


For configuration examples for this feature, see the document SIP Gateway Support for Bind Command.


For configuration examples for this feature, see the document SIP Gateway Support of RSVP and TEL URL.




















SIP T.38 Fax Relay

For configuration examples for this feature, see the document SIP T.38 Fax Relay.

SIP User Agent MIB


Basic SIP Configuration ExampleThe following shows an example of the output that appears when you enter the show running configuration command.

Router1# show running configuration

Building configuration...

Current configuration:!version 12.2service timestamps debug datetimeservice timestamps log uptimeno service password-encryption!hostname router1!enable secret 5 $1$dlEK$ziROgcQm08RwI/d0VSfal1enable password password1!dspint DSPfarm1/0!ip subnet-zeroip tcp path-mtu-discoveryip name-server 172.18.192.48!isdn voice-call-failure 0!!controller T1 1/0 framing esf clock source line primary linecode b8zs!controller T1 1/1!!voice-port 2/0/0!voice-port 2/0/1!voice class codec 1 codec preference 1 g711alaw codec preference 2 g723r63 codec preference 3 g723r53!!dial-peer voice 100 pots destination-pattern 3660110 port 2/0/0!dial-peer voice 200 pots application session destination-pattern 3660120




port 2/0/1!dial-peer voice 101 voip destination-pattern 3660210 session protocol sipv2 session target ipv4:166.34.244.73 codec g711ulaw!dial-peer voice 201 voip application sesion destination-pattern 3660220 session protocol sipv2 session target dns:3660-2.sip.com codec g711ulaw!dial-peer voice 999 voip destination-pattern 5551111 session protocol sipv2 session target ipv4:161.44.53.89 session transport tcp!dial-peer voice 300 pots destination-pattern 2101100!dial-peer voice 350 voip destination-pattern 3100607 session protocol sipv2 session target ipv4:172.18.192.197 codec g711ulaw!dial-peer voice 301 voip application session destination-pattern 1234 session protocol sipv2 session target ipv4:172.18.192.193 codec g711ulaw!dial-peer voice 333 voip application session destination-pattern 1235 session protocol sipv2 session target ipv4:172.18.192.199 codec g711ulaw!dial-peer voice 888 voip destination-pattern 888 session protocol sipv2 session target ipv4:161.44.53.89 session transport tcp codec g711ulaw!dial-peer voice 260011 voip destination-pattern 260011 session protocol sipv2 session target ipv4:172.18.192.164 codec g711ulaw!dial-peer voice 444 voip destination-pattern 2339000 session protocol sipv2 session target ipv4:172.18.192.205 codec g711ulaw!dial-peer voice 111 voip



destination-pattern 111 session protocol sipv2 session target sip-server codec g711ulaw!dial-peer voice 7777777 voip destination-pattern 19197777777 session protocol sipv2 session target ipv4:172.18.192.38 codec g711ulaw!!sip-ua max-forwards 0 retry invite 5 retry response 0 retry bye 0 retry cancel 0 retry prack 0 retry comet 0 retry rel1xx 0 retry notify 0 timers trying 501 timers expires 0 timers connect 0 timers disconnect 0 timers prack 0 timers comet 0 timers rel1xx 0 timers notify 0 sip-server ipv4:172.16.0.0 no transport tcp!!interface FastEthernet0/0 ip address 172.18.192.194 255.255.255.0 load-interval 30 speed auto half-duplex!interface FastEthernet0/1 ip address 166.34.245.230 255.255.255.224 load-interval 30 speed auto half-duplex!ip classlessip route 0.0.0.0 0.0.0.0 172.18.192.1ip route 166.34.0.0 255.255.0.0 166.34.245.225no ip http server!access-list 101 permit ip host 10.0.2.30 host 10.0.2.31access-list 101 deny udp any eq rip anyaccess-list 101 deny udp any any eq ripaccess-list 101 deny udp any eq isakmp anyaccess-list 101 deny udp any any eq isakmpaccess-list 101 permit ip any anysnmp-server engineID local 000000090200003094202740snmp-server community public RW! line con 0 exec-timeout 0 0 transport input noneline aux 0line vty 0 4



password xxx login!end

Configuring SIP with Multiple Codecs ExampleThe following shows an example of the output that appears when you enter the show running configuration command. Inapplicable modules are omitted.

Router# show running-configuration

version 12.2...hostname UA-4...controller T1 0 framing esf clock source line primary linecode b8zs ds0-group 0 timeslots 1-24 type e&m-fgb dtmf dnis...controller T1 1 framing esf clock source line secondary 1 linecode b8zs ds0-group 0 timeslots 1-24 type e&m-fgb dtmf dnis...voice-port 0:0...voice-port 1:0...voice class codec 100 codec preference 1 g726r16 codec preference 2 g729r8 codec preference 3 g711alaw codec preference 4 g711ulaw...dial-peer voice 500 pots destination-pattern 92055500.. port 0:0 prefix 92055500...dial-peer voice 600 voip incoming called-number 92055500.. session protocol sipv2



voice-class codec 100 no vad...dial-peer voice 501 pots destination-pattern 94055500.. port 1:0 prefix 94055500...dial-peer voice 601 voip incoming called-number 94055500.. session protocol sipv2 voice-class codec 100 no vad...interface Ethernet0 ip address 172.16.1.1 255.255.255.1 no ip directed-broadcast load-interval 30...interface FastEthernet0 ip address 172.16.1.2 255.255.255.2 no ip directed-broadcast load-interval 30 duplex auto speed auto

Configuring Phone Number Translation Rules ExamplesThe following example illustrates a translation rule for dialing national numbers in the situation where the user must dial 9 to access an outside line. In the rule command in this example:

• 91% is the input search pattern. The percent sign (%) is a wild card.

• The second 1 is the substituted pattern.

• The match type of number is international.

• The substituted type of number is national.

The result of this command is that any outgoing call that is destined for a number that starts with 91 and that is considered by the gateway to be an international number will be sent to the PSTN as a national number with a prefix of 1.

translation-rule 10Rule 1 91% 1 international national!!!dial-peer voice 10 potsdestination-pattern 91..........translate-outgoing called 10port 1:D!



The following example illustrates a translation rule for dialing national numbers in the situation where the user does not need to dial 9 to access an outside line.

translation-rule 10Rule 1 1% 1 international national!!!dial-peer voice 10 potsdestination-pattern 1..........translate-outgoing called 10port 1:Dprefix 1!

The following example illustrates a translation rule for dialing international numbers in the situation where the user must dial 9 to access an outside line.

translation-rule 20Rule 1 9011% 011 unknown international!!!dial-peer voice 10 potsdestination-pattern 9011Ttranslate-outgoing called 20port 1:D!

The following example illustrates a translation rule for dialing international numbers in the situation where the user does not need to dial 9 to access an outside line.

translation-rule 20Rule 1 011% 011 unknown international!!!dial-peer voice 10 potsdestination-pattern 011Ttranslate-outgoing called 20port 1:Dprefix 011!

Call Transfer Configuration ExamplesThe following example illustrates how to configure call transfer. In Figure 1, User A and User C are in an established call. User C then transfers the call to User B. This results in call establishment between User A and User B. User C is then disconnected with User A, regardless of whether the transfer fails or succeeds.

When a call originates or terminates on a gateway, either the calling party number, the called party number, or the port is used (depending on the scenario) to match a dial peer in order to determine the basic call characteristics. One of the characteristics to determine is which application to use for the call. For the call transfer to succeed, the matching dial peer must have application set to “session” on the gateway that is controlling the transfer. (This is the gateway that receives the Bye with an Also header).



There are two scenarios for dial-peer matching based on whether the call is coming from a POTS interface or from the IP network:

• For calls coming from a POTS interface, the port will be used to match a POTS dial peer with the port the call came in from. This dial peer should have “application session.”

• For calls coming from the IP network, a series of criteria is used (in the order listed below) to match dial peers. If the first criteria does not result in a match, the second criteria is used. If the second criteria does not result in a match, the third criteria is used. If a match does not occur, the default application, which does not support call transfer, is used.

a. The called number matches the “incoming called-number” on a VoIP dial peer.

b. The calling number matches the “answer-address” on a VoIP dial peer.

c. The calling number matches the “destination-pattern” on a VoIP dial peer.

Note For calls coming from the IP network, it is possible for the calling number to be blocked based on privacy restrictions. In such cases, the “incoming called-number” is used for call transfers.

Figure 1 Call Transfer Example

In this example, Gateway 1 handles the transfer (recipient of the Bye with the Also header). User C invokes the transfer service (originator of the Bye with the Also header). There are two scenarios in which a dial peer match must have application set to “session” for the transfer to succeed:

• Incoming call from the PSTN—User A originates a call to User C. From the prospective of Gateway 1, this would be an incoming call from the POTS interface so Gateway 1 looks for a POTS dial peer matching the port on which the call came in. Gateway 1 must have a POTS dial peer for User A with application set to “session” if transfer is later invoked by User C.

• Incoming call from IP network—User C calls User A. From the prospective of Gateway 1 this is an incoming call from the IP network. Gateway 1 uses the criteria previously discussed for a VoIP dial peer (match on incoming called-number, answer-address, or destination pattern). Gateway 1 must have one of the following:

– A VoIP dial peer with an incoming called-number of User A

– A VoIP dial peer with answer-address of User C

– A VoIP dial peer with destination-pattern of User C.

The matching dial peer must have application set to “session” if transfer is later invoked by User C.

Note To handle all call transfer situations, you should configure both POTS and VoIP dial peers.

User A User B

User CIP phone

GW1 GW2

IP Network

777-0000 888-0000

999-0000 3391

4

Session Initiation Protocol (SIP) for VoIPCommand Reference


The following example shows how to apply the “session” application to a dial peer:

Router(config)# dial-peer voice 10 potsRouter(config-dial-peer)# application session

The following example shows how to configure the E.164 telephone number 555-7922 for a dial peer:

Router(config)# dial-peer voice 10 potsRouter(config-dial-peer)# destination-pattern +5557922

The following example configures the number (310) 555-9261 as the incoming called number for VoIP dial peer 10:

Router(config)# dial-peer voice 10 potsRouter(config-dial-peer)# incoming called-number 3105559261

The following example configures the E.164 telephone number 555-9626 as the dial peer of an incoming call:

Router(config)# dial-peer voice 10 potsRouter(config-dial-peer)# answer-address +5559626

Command ReferenceThis section documents modified commands. All other commands used with this feature are documented in the Cisco IOS Release 12.2 command reference publications and in the following documents:


For command reference pages for this feature, see the document Call Transfer Capabilities Using the Refer Method.


For command reference pages for this feature, see the document Configurable PSTN Cause Code to SIP Response Mapping.


For command reference pages for this feature, see the document Dual Tone Multifrequency Relay for SIP Calls Using Named Telephone Events.


There are no commands associated with this feature.


For command reference pages for this feature, see the document SIP Gateway Support of RSVP and TEL URL.


For command reference pages for this feature, see the document SIP Diversion Header Implementation for Redirecting Number.











Session Initiation Protocol (SIP) for VoIPCommand Reference



For command reference pages for this feature, see the document SIP Gateway Support for Bind Command.


For command reference pages for this feature, see the document SIP Gateway Support of RSVP and TEL URL.





SIP T.38 Fax Relay

For command reference pages for this feature, see the document SIP T.38 Fax Relay.

SIP User Agent MIB


• debug ccsip all

• debug ccsip calls

• debug ccsip error

• debug ccsip events

• debug ccsip messages

• debug ccsip states

• default

• gw-accounting

• gw-accounting

• max-redirects

• retry invite

• retry invite

• session protocol

• session transport

• show sip-ua

• sip-server

• sip-ua

• timers

• transport






Session Initiation Protocol (SIP) for VoIPaaa username


aaa usernameTo determine the information to populate the username attribute for AAA billing records, use the aaa username command in SIP user agent configuration mode. To achieve default capabilities, use the no form of this command.

aaa username {calling-number | proxy-auth}

no aaa username

Syntax Description

Defaults calling-number

Command Modes SIP user-agent configuration

Command History

Usage Guidelines Parsing of the Proxy-Authorization header, decoding of the PUID and password, and populating of the username attribute with the PUID must be enabled through this command. If this command is not issued, the Proxy-Authorization header is ignored.

The keyword proxy-auth is a nonstandard implementation, and SIP gateways do not normally receive or process the proxy-auth header.

calling-number Uses the FROM: header in the SIP INVITE (default value). This keyword is used in most implementations.

proxy-auth Parses the Proxy-Authorization header. Decodes the Microsoft Passport user ID (PUID) and password, and then populates the PUID into the username attribute and a “.” into the password attribute.

The username attribute is used for billing and the “.” is used for the password, because the user has already been authenticated prior to this point.


12.2(2)X This command was introduced.

12.2(8)T This command was integrated into Cisco IOS Release 12.2(8)T and implemented on Cisco 7200 series routers. Support for the Cisco AS5300 universal access server, Cisco AS5350, Cisco AS5400, and Cisco AS5850 universal gateway is not included in this release.

12.2(11)T This command was integrated Cisco IOS Release 12.2(11)T on the Cisco AS5850 universal gateway.

Session Initiation Protocol (SIP) for VoIPaaa username


Examples The following example shows the processing of the SIP username from the Proxy-Authorization header being enabled:

Router(config)# sip-uaRouter(config-sip-ua)# aaa username proxy-auth

Related Commands Command Description

show call active voice Shows active call information for voice calls or fax transmissions in progress.

show call history voice Displays the voice call history table.

Session Initiation Protocol (SIP) for VoIPdebug ccsip all


debug ccsip allTo enable all SIP-related debugging, enter the debug ccsip all command in EXEC mode. To disable all debugging output, use the no form of this command.

debug ccsip all

no debug ccsip all

Syntax Description This command has no arguments or keywords.

Defaults SIP debugging is not enabled

Command Modes EXEC

Command History

Usage Guidelines The debug ccsip all command enables the following debug SIP commands:


12.1(1)T This command was introduced.

12.1(3)T The output of this command was changed.

12.2(2)XA Support was added for the Cisco AS5400 and AS5350 universal gateways.

12.2(2)XB1 This command was implemented on the Cisco AS5850 universal gateway.



Command Description

debug ccsip calls Shows all SIP Service Provider Interface (SPI) call tracing.

debug ccsip error Shows SIP Service Provider Interface (SPI) errors.

debug ccsip events Shows all SIP Service Provider Interface (SPI) events tracing.

debug ccsip messages Shows all SIP Service Provider Interface (SPI) message tracing.

debug ccsip states Shows all SIP Service Provider Interface (SPI) state tracing.



Examples The following example displays debug output from one side of the call:

Router# debug ccsip all

All SIP call tracing enabledRouter1#*Mar 6 14:10:42: 0x624CFEF8 : State change from (STATE_NONE, SUBSTATE_NONE) to (STATE_IDLE, SUBSTATE_NONE)*Mar 6 14:10:42: Queued event from SIP SPI : SIPSPI_EV_CC_CALL_SETUP*Mar 6 14:10:42: CCSIP-SPI-CONTROL: act_idle_call_setup*Mar 6 14:10:42: act_idle_call_setup:Not using Voice Class Codec

*Mar 6 14:10:42: act_idle_call_setup: preferred_codec set[0] type :g711ulaw bytes: 160 *Mar 6 14:10:42: Queued event from SIP SPI : SIPSPI_EV_CREATE_CONNECTION*Mar 6 14:10:42: 0x624CFEF8 : State change from (STATE_IDLE, SUBSTATE_NONE) to (STATE_IDLE, SUBSTATE_CONNECTING)*Mar 6 14:10:42: REQUEST CONNECTION TO IP:166.34.245.231 PORT:5060

*Mar 6 14:10:42: 0x624CFEF8 : State change from (STATE_IDLE, SUBSTATE_CONNECTING) to (STATE_IDLE, SUBSTATE_CONNECTING)*Mar 6 14:10:42: CCSIP-SPI-CONTROL: act_idle_connection_created*Mar 6 14:10:42: CCSIP-SPI-CONTROL: act_idle_connection_created: Connid(1) created to 166.34.245.231:5060, local_port 54113*Mar 6 14:10:42: sipSPIAddLocalContact*Mar 6 14:10:42: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE*Mar 6 14:10:42: CCSIP-SPI-CONTROL: sip_stats_method*Mar 6 14:10:42: 0x624CFEF8 : State change from (STATE_IDLE, SUBSTATE_CONNECTING) to (STATE_SENT_INVITE, SUBSTATE_NONE)*Mar 6 14:10:42: Sent: INVITE sip:[email protected];user=phone;phone-context=unknown SIP/2.0Via: SIP/2.0/UDP 166.34.245.230:54113From: "3660110" <sip:[email protected]>To: <sip:[email protected];user=phone;phone-context=unknown>Date: Sat, 06 Mar 1993 19:10:42 GMTCall-ID: [email protected]: 2881152943-2184249548-0-483039712User-Agent: Cisco VoIP Gateway/ IOS 12.x/ SIP enabledCSeq: 101 INVITEMax-Forwards: 6Timestamp: 731427042Contact: <sip:[email protected]:5060;user=phone>Expires: 180Content-Type: application/sdpContent-Length: 137

v=0o=CiscoSystemsSIP-GW-UserAgent 1212 283 IN IP4 166.34.245.230s=SIP Callt=0 0c=IN IP4 166.34.245.230m=audio 20208 RTP/AVP 0

*Mar 6 14:10:42: Received: SIP/2.0 100 TryingVia: SIP/2.0/UDP 166.34.245.230:54113From: "3660110" <sip:[email protected]>To: <sip:[email protected];user=phone;phone-context=unknown>Date: Mon, 08 Mar 1993 22:36:40 GMTCall-ID: [email protected]: 731427042Server: Cisco VoIP Gateway/ IOS 12.x/ SIP enabledCSeq: 101 INVITEContent-Length: 0



*Mar 6 14:10:42: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 166.34.245.231:5060*Mar 6 14:10:42: CCSIP-SPI-CONTROL: act_sentinvite_new_message*Mar 6 14:10:42: CCSIP-SPI-CONTROL: sipSPICheckResponse*Mar 6 14:10:42: CCSIP-SPI-CONTROL: sip_stats_status_code*Mar 6 14:10:42: Roundtrip delay 4 milliseconds for method INVITE

*Mar 6 14:10:42: 0x624CFEF8 : State change from (STATE_SENT_INVITE, SUBSTATE_NONE) to (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_PROCEEDING)*Mar 6 14:10:42: Received: SIP/2.0 180 RingingVia: SIP/2.0/UDP 166.34.245.230:54113From: "3660110" <sip:[email protected]>To: <sip:[email protected];user=phone;phone-context=unknown>Date: Mon, 08 Mar 1993 22:36:40 GMTCall-ID: [email protected]: 731427042Server: Cisco VoIP Gateway/ IOS 12.x/ SIP enabledCSeq: 101 INVITEContent-Type: application/sdpContent-Length: 137


*Mar 6 14:10:42: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 166.34.245.231:5060*Mar 6 14:10:42: CCSIP-SPI-CONTROL: act_recdproc_new_message*Mar 6 14:10:42: CCSIP-SPI-CONTROL: sipSPICheckResponse*Mar 6 14:10:42: CCSIP-SPI-CONTROL: sipSPICheckResponse : Updating session description*Mar 6 14:10:42: CCSIP-SPI-CONTROL: sip_stats_status_code*Mar 6 14:10:42: Roundtrip delay 8 milliseconds for method INVITE

*Mar 6 14:10:42: HandleSIP1xxRinging: SDP MediaTypes negotiation successful!Negotiated Codec : g711ulaw , bytes :160Inband Alerting : 0

*Mar 6 14:10:42: 0x624CFEF8 : State change from (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_PROCEEDING) to (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_ALERTING)*Mar 6 14:10:46: Received: SIP/2.0 200 OKVia: SIP/2.0/UDP 166.34.245.230:54113From: "3660110" <sip:[email protected]>To: <sip:[email protected];user=phone;phone-context=unknown>;tag=27D3FCA8-C7FDate: Mon, 08 Mar 1993 22:36:40 GMTCall-ID: [email protected]: 731427042Server: Cisco VoIP Gateway/ IOS 12.x/ SIP enabledContact: <sip:[email protected]:5060;user=phone>CSeq: 101 INVITEContent-Type: application/sdpContent-Length: 137

v=0o=CiscoSystemsSIP-GW-UserAgent 969 7889 IN IP4 166.34.245.231s=SIP Callt=0 0c=IN IP4 166.34.245.231



m=audio 20038 RTP/AVP 0


*Mar 6 14:10:46: CCSIP-SPI-CONTROL: act_recdproc_new_message: SDP MediaTypes negotiation successful!Negotiated Codec : g711ulaw , bytes :160

*Mar 6 14:10:46: CCSIP-SPI-CONTROL: sipSPIReconnectConnection*Mar 6 14:10:46: Queued event from SIP SPI : SIPSPI_EV_RECONNECT_CONNECTION*Mar 6 14:10:46: CCSIP-SPI-CONTROL: recv_200_OK_for_invite*Mar 6 14:10:46: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE*Mar 6 14:10:46: CCSIP-SPI-CONTROL: sip_stats_method*Mar 6 14:10:46: 0x624CFEF8 : State change from (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_ALERTING) to (STATE_ACTIVE, SUBSTATE_NONE)*Mar 6 14:10:46: The Call Setup Information is :

Call Control Block (CCB) : 0x624CFEF8 State of The Call : STATE_ACTIVE TCP Sockets Used : NO Calling Number : 3660110 Called Number : 3660210 Negotiated Codec : g711ulaw Source IP Address (Media): 166.34.245.230 Source IP Port (Media): 20208 Destn IP Address (Media): 166.34.245.231 Destn IP Port (Media): 20038 Destn SIP Addr (Control) : 166.34.245.231 Destn SIP Port (Control) : 5060 Destination Name : 166.34.245.231

*Mar 6 14:10:46: HandleUdpReconnection: Udp socket connected for fd: 1 with 166.34.245.231:5060*Mar 6 14:10:46: Sent: ACK sip:[email protected]:5060;user=phone SIP/2.0Via: SIP/2.0/UDP 166.34.245.230:54113From: "3660110" <sip:[email protected]>To: <sip:[email protected];user=phone;phone-context=unknown>;tag=27D3FCA8-C7FDate: Sat, 06 Mar 1993 19:10:42 GMTCall-ID: [email protected]: 6Content-Type: application/sdpContent-Length: 137CSeq: 101 ACK


*Mar 6 14:10:46: CCSIP-SPI-CONTROL: ccsip_caps_ind*Mar 6 14:10:46: ccsip_caps_ind: Load DSP with codec (5) g711ulaw, Bytes=160*Mar 6 14:10:46: ccsip_caps_ind: set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_INBAND_VOICE*Mar 6 14:10:46: CCSIP-SPI-CONTROL: ccsip_caps_ack*Mar 6 14:10:50: Received: BYE sip:[email protected]:5060;user=phone SIP/2.0



Via: SIP/2.0/UDP 166.34.245.231:54835From: <sip:[email protected];user=phone;phone-context=unknown>;tag=27D3FCA8-C7FTo: "3660110" <sip:[email protected]>Date: Mon, 08 Mar 1993 22:36:44 GMTCall-ID: [email protected]: Cisco VoIP Gateway/ IOS 12.x/ SIP enabledMax-Forwards: 6Timestamp: 731612207CSeq: 101 BYEContent-Length: 0

*Mar 6 14:10:50: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 166.34.245.231:54835*Mar 6 14:10:50: CCSIP-SPI-CONTROL: act_active_new_message*Mar 6 14:10:50: CCSIP-SPI-CONTROL: sact_active_new_message_request*Mar 6 14:10:50: CCSIP-SPI-CONTROL: sip_stats_method*Mar 6 14:10:50: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE*Mar 6 14:10:50: CCSIP-SPI-CONTROL: sip_stats_status_code*Mar 6 14:10:50: CCSIP-SPI-CONTROL: sipSPIInitiateCallDisconnect : Initiate call disconnect(16) for outgoing call*Mar 6 14:10:50: 0x624CFEF8 : State change from (STATE_ACTIVE, SUBSTATE_NONE) to (STATE_DISCONNECTING, SUBSTATE_NONE)*Mar 6 14:10:50: Sent: SIP/2.0 200 OKVia: SIP/2.0/UDP 166.34.245.231:54835From: <sip:[email protected];user=phone;phone-context=unknown>;tag=27D3FCA8-C7FTo: "3660110" <sip:[email protected]>Date: Sat, 06 Mar 1993 19:10:50 GMTCall-ID: [email protected]: Cisco VoIP Gateway/ IOS 12.x/ SIP enabledTimestamp: 731612207Content-Length: 0CSeq: 101 BYE

*Mar 6 14:10:50: Queued event From SIP SPI to CCAPI/DNS : SIPSPI_EV_CC_CALL_DISCONNECT*Mar 6 14:10:50: CCSIP-SPI-CONTROL: act_disconnecting_disconnect*Mar 6 14:10:50: CCSIP-SPI-CONTROL: sipSPICallCleanup*Mar 6 14:10:50: Queued event from SIP SPI : SIPSPI_EV_CLOSE_CONNECTION*Mar 6 14:10:50: CLOSE CONNECTION TO CONNID:1

*Mar 6 14:10:50: sipSPIIcpifUpdate :CallState: 4 Playout: 1755 DiscTime:48305031 ConnTime 48304651

*Mar 6 14:10:50: 0x624CFEF8 : State change from (STATE_DISCONNECTING, SUBSTATE_NONE) to (STATE_DEAD, SUBSTATE_NONE)*Mar 6 14:10:50: The Call Setup Information is :

Call Control Block (CCB) : 0x624CFEF8 State of The Call : STATE_DEAD TCP Sockets Used : NO Calling Number : 3660110 Called Number : 3660210 Negotiated Codec : g711ulaw Source IP Address (Media): 166.34.245.230 Source IP Port (Media): 20208 Destn IP Address (Media): 166.34.245.231 Destn IP Port (Media): 20038 Destn SIP Addr (Control) : 166.34.245.231 Destn SIP Port (Control) : 5060 Destination Name : 166.34.245.231



*Mar 6 14:10:50:

Disconnect Cause (CC) : 16 Disconnect Cause (SIP) : 200

*Mar 6 14:10:50: udpsock_close_connect: Socket fd: 1 closed for connid 1 with remote port: 5060

The following example displays debut output from the other side of the call:

Router# debug ccsip all

All SIP call tracing enabled3660-2#*Mar 8 17:36:40: Received: INVITE sip:[email protected];user=phone;phone-context=unknown SIP/2.0Via: SIP/2.0/UDP 166.34.245.230:54113From: "3660110" <sip:[email protected]>To: <sip:[email protected];user=phone;phone-context=unknown>Date: Sat, 06 Mar 1993 19:10:42 GMTCall-ID: [email protected]: 2881152943-2184249548-0-483039712User-Agent: Cisco VoIP Gateway/ IOS 12.x/ SIP enabledCSeq: 101 INVITEMax-Forwards: 6Timestamp: 731427042Contact: <sip:[email protected]:5060;user=phone>Expires: 180Content-Type: application/sdpContent-Length: 137


*Mar 8 17:36:40: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 166.34.245.230:54113*Mar 8 17:36:40: CCSIP-SPI-CONTROL: sipSPISipIncomingCall*Mar 8 17:36:40: 0x624D8CCC : State change from (STATE_NONE, SUBSTATE_NONE) to (STATE_IDLE, SUBSTATE_NONE)*Mar 8 17:36:40: CCSIP-SPI-CONTROL: act_idle_new_message*Mar 8 17:36:40: CCSIP-SPI-CONTROL: sact_idle_new_message_invite*Mar 8 17:36:40: CCSIP-SPI-CONTROL: sip_stats_method*Mar 8 17:36:40: sact_idle_new_message_invite:Not Using Voice Class Codec

*Mar 8 17:36:40: sact_idle_new_message_invite: Preferred codec[0] type: g711ulaw Bytes :160*Mar 8 17:36:40: sact_idle_new_message_invite: Media Negotiation successful for anincoming call

*Mar 8 17:36:40: sact_idle_new_message_invite: Negotiated Codec : g711ulaw, bytes :160Preferred Codec : g711ulaw, bytes :160

*Mar 8 17:36:40: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE*Mar 8 17:36:40: CCSIP-SPI-CONTROL: sip_stats_status_code*Mar 8 17:36:40: Num of Contact Locations 1 3660110 166.34.245.230 5060

*Mar 8 17:36:40: 0x624D8CCC : State change from (STATE_IDLE, SUBSTATE_NONE) to (STATE_RECD_INVITE, SUBSTATE_RECD_INVITE_CALL_SETUP)



*Mar 8 17:36:40: Sent: SIP/2.0 100 TryingVia: SIP/2.0/UDP 166.34.245.230:54113From: "3660110" <sip:[email protected]>To: <sip:[email protected];user=phone;phone-context=unknown>Date: Mon, 08 Mar 1993 22:36:40 GMTCall-ID: [email protected]: 731427042Server: Cisco VoIP Gateway/ IOS 12.x/ SIP enabledCSeq: 101 INVITEContent-Length: 0

*Mar 8 17:36:40: Queued event From SIP SPI to CCAPI/DNS : SIPSPI_EV_CC_CALL_PROCEEDING*Mar 8 17:36:40: CCSIP-SPI-CONTROL: act_recdinvite_proceeding*Mar 8 17:36:40: Queued event From SIP SPI to CCAPI/DNS : SIPSPI_EV_CC_CALL_ALERTING*Mar 8 17:36:40: CCSIP-SPI-CONTROL: ccsip_caps_ind*Mar 8 17:36:40: ccsip_caps_ind: codec(negotiated) = 5(Bytes 160)*Mar 8 17:36:40: ccsip_caps_ind: Load DSP with codec (5) g711ulaw, Bytes=160*Mar 8 17:36:40: ccsip_caps_ind: set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_INBAND_VOICE*Mar 8 17:36:40: CCSIP-SPI-CONTROL: ccsip_caps_ack*Mar 8 17:36:40: CCSIP-SPI-CONTROL: act_recdinvite_alerting*Mar 8 17:36:40: 180 Ringing with SDP - not likely

*Mar 8 17:36:40: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE*Mar 8 17:36:40: CCSIP-SPI-CONTROL: sip_stats_status_code*Mar 8 17:36:40: 0x624D8CCC : State change from (STATE_RECD_INVITE, SUBSTATE_RECD_INVITE_CALL_SETUP) to (STATE_SENT_ALERTING, SUBSTATE_NONE)*Mar 8 17:36:40: Sent: SIP/2.0 180 RingingVia: SIP/2.0/UDP 166.34.245.230:54113From: "3660110" <sip:[email protected]>To: <sip:[email protected];user=phone;phone-context=unknown>Date: Mon, 08 Mar 1993 22:36:40 GMTCall-ID: [email protected]: 731427042Server: Cisco VoIP Gateway/ IOS 12.x/ SIP enabledCSeq: 101 INVITEContent-Type: application/sdpContent-Length: 137


*Mar 8 17:36:44: Queued event From SIP SPI to CCAPI/DNS : SIPSPI_EV_CC_CALL_CONNECT*Mar 8 17:36:44: CCSIP-SPI-CONTROL: act_sentalert_connect*Mar 8 17:36:44: sipSPIAddLocalContact*Mar 8 17:36:44: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE*Mar 8 17:36:44: CCSIP-SPI-CONTROL: sip_stats_status_code*Mar 8 17:36:44: 0x624D8CCC : State change from (STATE_SENT_ALERTING, SUBSTATE_NONE) to (STATE_SENT_SUCCESS, SUBSTATE_NONE)*Mar 8 17:36:44: Sent: SIP/2.0 200 OKVia: SIP/2.0/UDP 166.34.245.230:54113From: "3660110" <sip:[email protected]>To: <sip:[email protected];user=phone;phone-context=unknown>;tag=27D3FCA8-C7FDate: Mon, 08 Mar 1993 22:36:40 GMTCall-ID: [email protected]: 731427042



Server: Cisco VoIP Gateway/ IOS 12.x/ SIP enabledContact: <sip:[email protected]:5060;user=phone>CSeq: 101 INVITEContent-Type: application/sdpContent-Length: 137


*Mar 8 17:36:44: Received: ACK sip:[email protected]:5060;user=phone SIP/2.0Via: SIP/2.0/UDP 166.34.245.230:54113From: "3660110" <sip:[email protected]>To: <sip:[email protected];user=phone;phone-context=unknown>;tag=27D3FCA8-C7FDate: Sat, 06 Mar 1993 19:10:42 GMTCall-ID: [email protected]: 6Content-Type: application/sdpContent-Length: 137CSeq: 101 ACK


*Mar 8 17:36:44: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 166.34.245.230:54113*Mar 8 17:36:44: CCSIP-SPI-CONTROL: act_sentsucc_new_message*Mar 8 17:36:44: CCSIP-SPI-CONTROL: sip_stats_method*Mar 8 17:36:44: 0x624D8CCC : State change from (STATE_SENT_SUCCESS, SUBSTATE_NONE) to (STATE_ACTIVE, SUBSTATE_NONE)*Mar 8 17:36:44: The Call Setup Information is :

Call Control Block (CCB) : 0x624D8CCC State of The Call : STATE_ACTIVE TCP Sockets Used : NO Calling Number : 3660110 Called Number : 3660210 Negotiated Codec : g711ulaw Source IP Address (Media): 166.34.245.231 Source IP Port (Media): 20038 Destn IP Address (Media): 166.34.245.230 Destn IP Port (Media): 20208 Destn SIP Addr (Control) : 166.34.245.230 Destn SIP Port (Control) : 5060 Destination Name : 166.34.245.230

*Mar 8 17:36:47: Queued event From SIP SPI to CCAPI/DNS : SIPSPI_EV_CC_CALL_DISCONNECT*Mar 8 17:36:47: CCSIP-SPI-CONTROL: act_active_disconnect*Mar 8 17:36:47: Queued event from SIP SPI : SIPSPI_EV_CREATE_CONNECTION*Mar 8 17:36:47: 0x624D8CCC : State change from (STATE_ACTIVE, SUBSTATE_NONE) to (STATE_ACTIVE, SUBSTATE_CONNECTING)*Mar 8 17:36:47: REQUEST CONNECTION TO IP:166.34.245.230 PORT:5060

*Mar 8 17:36:47: 0x624D8CCC : State change from (STATE_ACTIVE, SUBSTATE_CONNECTING) to (STATE_ACTIVE, SUBSTATE_CONNECTING)*Mar 8 17:36:47: CCSIP-SPI-CONTROL: act_active_connection_created



*Mar 8 17:36:47: CCSIP-SPI-CONTROL: sipSPICheckSocketConnection*Mar 8 17:36:47: CCSIP-SPI-CONTROL: sipSPICheckSocketConnection: Connid(1) created to 166.34.245.230:5060, local_port 54835*Mar 8 17:36:47: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE*Mar 8 17:36:47: CCSIP-SPI-CONTROL: sip_stats_method*Mar 8 17:36:47: 0x624D8CCC : State change from (STATE_ACTIVE, SUBSTATE_CONNECTING) to (STATE_DISCONNECTING, SUBSTATE_NONE)*Mar 8 17:36:47: Sent: BYE sip:[email protected]:5060;user=phone SIP/2.0Via: SIP/2.0/UDP 166.34.245.231:54835From: <sip:[email protected];user=phone;phone-context=unknown>;tag=27D3FCA8-C7FTo: "3660110" <sip:[email protected]>Date: Mon, 08 Mar 1993 22:36:44 GMTCall-ID: [email protected]: Cisco VoIP Gateway/ IOS 12.x/ SIP enabledMax-Forwards: 6Timestamp: 731612207CSeq: 101 BYEContent-Length: 0

*Mar 8 17:36:47: Received: SIP/2.0 200 OKVia: SIP/2.0/UDP 166.34.245.231:54835From: <sip:[email protected];user=phone;phone-context=unknown>;tag=27D3FCA8-C7FTo: "3660110" <sip:[email protected]>Date: Sat, 06 Mar 1993 19:10:50 GMTCall-ID: [email protected]: Cisco VoIP Gateway/ IOS 12.x/ SIP enabledTimestamp: 731612207Content-Length: 0CSeq: 101 BYE

*Mar 8 17:36:47: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 166.34.245.230:54113*Mar 8 17:36:47: CCSIP-SPI-CONTROL: act_disconnecting_new_message*Mar 8 17:36:47: CCSIP-SPI-CONTROL: sact_disconnecting_new_message_response*Mar 8 17:36:47: CCSIP-SPI-CONTROL: sipSPICheckResponse*Mar 8 17:36:47: CCSIP-SPI-CONTROL: sip_stats_status_code*Mar 8 17:36:47: Roundtrip delay 4 milliseconds for method BYE

*Mar 8 17:36:47: CCSIP-SPI-CONTROL: sipSPICallCleanup*Mar 8 17:36:47: Queued event from SIP SPI : SIPSPI_EV_CLOSE_CONNECTION*Mar 8 17:36:47: CLOSE CONNECTION TO CONNID:1


*Mar 8 17:36:47: 0x624D8CCC : State change from (STATE_DISCONNECTING, SUBSTATE_NONE) to (STATE_DEAD, SUBSTATE_NONE)*Mar 8 17:36:47: The Call Setup Information is :

Call Control Block (CCB) : 0x624D8CCC State of The Call : STATE_DEAD TCP Sockets Used : NO Calling Number : 3660110 Called Number : 3660210 Negotiated Codec : g711ulaw Source IP Address (Media): 166.34.245.231 Source IP Port (Media): 20038 Destn IP Address (Media): 166.34.245.230



Destn IP Port (Media): 20208 Destn SIP Addr (Control) : 166.34.245.230 Destn SIP Port (Control) : 5060 Destination Name : 166.34.245.230

*Mar 8 17:36:47:




debug ccsip calls Displays all SIP SPI call tracing and traces the SIP call details as they are updated in the SIP call control block.

debug ccsip error Displays SIP SPI errors. This command traces all error messages generated from errors encountered by the SIP subsystem.

debug ccsip events Displays all SIP SPI events tracing and traces the events posted to SIP SPI from all interfaces.

debug ccsip messages Displays all SIP SPI message tracing and traces the SIP messages exchanged between the SIP UA client (UAC) and the access server.

debug ccsip states Displays all SIP SPI state tracing and traces the state machine changes of SIP SPI and displays the state transitions.

Session Initiation Protocol (SIP) for VoIPdebug ccsip calls


debug ccsip callsTo display all SIP SPI call tracing and to trace the SIP call details as they are updated in the SIP call control block, enter the debug ccsip calls command in EXEC mode.

debug ccsip calls


Defaults SIP SPI call tracing is not displayed

Command Modes EXEC

Command History

Usage Guidelines This command traces the SIP call details as updated in the SIP call control block.


Router1# debug ccsip calls

SIP Call statistics tracing is enabledRouter1#*Mar 6 14:12:33: The Call Setup Information is :

Call Control Block (CCB) : 0x624D078C State of The Call : STATE_ACTIVE TCP Sockets Used : NO Calling Number : 3660110 Called Number : 3660210 Negotiated Codec : g711ulaw Source IP Address (Media): 166.34.245.230 Source IP Port (Media): 20644 Destn IP Address (Media): 166.34.245.231 Destn IP Port (Media): 20500

Release Release


12.1(3)T The output of the command was changed.







Destn SIP Addr (Control) : 166.34.245.231 Destn SIP Port (Control) : 5060 Destination Name : 166.34.245.231

*Mar 6 14:12:40: The Call Setup Information is :

Call Control Block (CCB) : 0x624D078C State of The Call : STATE_DEAD TCP Sockets Used : NO Calling Number : 3660110 Called Number : 3660210 Negotiated Codec : g711ulaw Source IP Address (Media): 166.34.245.230 Source IP Port (Media): 20644 Destn IP Address (Media): 166.34.245.231 Destn IP Port (Media): 20500 Destn SIP Addr (Control) : 166.34.245.231 Destn SIP Port (Control) : 5060 Destination Name : 166.34.245.231

*Mar 6 14:12:40:


The following example displays debug output from the other side of the call:

Router2# debug ccsip calls

SIP Call statistics tracing is enabledRouter2#*Mar 8 17:38:31: The Call Setup Information is :

Call Control Block (CCB) : 0x624D9560 State of The Call : STATE_ACTIVE TCP Sockets Used : NO Calling Number : 3660110 Called Number : 3660210 Negotiated Codec : g711ulaw Source IP Address (Media): 166.34.245.231 Source IP Port (Media): 20500 Destn IP Address (Media): 166.34.245.230 Destn IP Port (Media): 20644 Destn SIP Addr (Control) : 166.34.245.230 Destn SIP Port (Control) : 5060 Destination Name : 166.34.245.230

*Mar 8 17:38:38: The Call Setup Information is :

Call Control Block (CCB) : 0x624D9560 State of The Call : STATE_DEAD TCP Sockets Used : NO Calling Number : 3660110 Called Number : 3660210 Negotiated Codec : g711ulaw Source IP Address (Media): 166.34.245.231 Source IP Port (Media): 20500 Destn IP Address (Media): 166.34.245.230 Destn IP Port (Media): 20644 Destn SIP Addr (Control) : 166.34.245.230 Destn SIP Port (Control) : 5060 Destination Name : 166.34.245.230



*Mar 8 17:38:38:



debug ccsip all Enables all SIP-related debugging.





Session Initiation Protocol (SIP) for VoIPdebug ccsip error


debug ccsip errorTo display SIP Service Provider Interface (SPI) errors, enter the debug ccsip error command in EXEC mode.

debug ccsip error


Defaults SIP SPI errors are not displayed

Command Modes EXEC

Command History

Usage Guidelines This command traces all error messages generated from errors encountered by the SIP subsystem.


Router1# debug ccsip error

SIP Call error tracing is enabledRouter1#*Mar 6 14:16:41: CCSIP-SPI-CONTROL: act_idle_call_setup*Mar 6 14:16:41: act_idle_call_setup:Not using Voice Class Codec

*Mar 6 14:16:41: act_idle_call_setup: preferred_codec set[0] type :g711ulaw bytes: 160 *Mar 6 14:16:41: REQUEST CONNECTION TO IP:166.34.245.231 PORT:5060

*Mar 6 14:16:41: CCSIP-SPI-CONTROL: act_idle_connection_created*Mar 6 14:16:41: CCSIP-SPI-CONTROL: act_idle_connection_created: Connid(1) created to 166.34.245.231:5060, local_port 55674*Mar 6 14:16:41: sipSPIAddLocalContact*Mar 6 14:16:41: CCSIP-SPI-CONTROL: sip_stats_method










*Mar 6 14:16:41: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 166.34.245.231:5060*Mar 6 14:16:41: CCSIP-SPI-CONTROL: act_sentinvite_new_message*Mar 6 14:16:41: CCSIP-SPI-CONTROL: sipSPICheckResponse*Mar 6 14:16:41: CCSIP-SPI-CONTROL: sip_stats_status_code*Mar 6 14:16:41: Roundtrip delay 4 milliseconds for method INVITE


*Mar 6 14:16:41: HandleSIP1xxRinging: SDP MediaTypes negotiation successful!Negotiated Codec : g711ulaw , bytes :160Inband Alerting : 0


*Mar 6 14:16:45: CCSIP-SPI-CONTROL: act_recdproc_new_message: SDP MediaTypes negotiation successful!Negotiated Codec : g711ulaw , bytes :160

*Mar 6 14:16:45: CCSIP-SPI-CONTROL: sipSPIReconnectConnection*Mar 6 14:16:45: CCSIP-SPI-CONTROL: recv_200_OK_for_invite*Mar 6 14:16:45: CCSIP-SPI-CONTROL: sip_stats_method*Mar 6 14:16:45: HandleUdpReconnection: Udp socket connected for fd: 1 with 166.34.245.231:5060*Mar 6 14:16:45: CCSIP-SPI-CONTROL: ccsip_caps_ind*Mar 6 14:16:45: ccsip_caps_ind: Load DSP with codec (5) g711ulaw, Bytes=160*Mar 6 14:16:45: ccsip_caps_ind: set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_INBAND_VOICE*Mar 6 14:16:45: CCSIP-SPI-CONTROL: ccsip_caps_ack*Mar 6 14:16:49: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 166.34.245.231:56101*Mar 6 14:16:49: CCSIP-SPI-CONTROL: act_active_new_message*Mar 6 14:16:49: CCSIP-SPI-CONTROL: sact_active_new_message_request*Mar 6 14:16:49: CCSIP-SPI-CONTROL: sip_stats_method*Mar 6 14:16:49: CCSIP-SPI-CONTROL: sip_stats_status_code*Mar 6 14:16:49: CCSIP-SPI-CONTROL: sipSPIInitiateCallDisconnect : Initiate call disconnect(16) for outgoing call*Mar 6 14:16:49: CCSIP-SPI-CONTROL: act_disconnecting_disconnect*Mar 6 14:16:49: CCSIP-SPI-CONTROL: sipSPICallCleanup*Mar 6 14:16:49: CLOSE CONNECTION TO CONNID:1



The following example displays debug output from the other side of the call:

Router2# debug ccsip error

SIP Call error tracing is enabledRouter2#



*Mar 8 17:42:39: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 166.34.245.230:55674*Mar 8 17:42:39: CCSIP-SPI-CONTROL: sipSPISipIncomingCall*Mar 8 17:42:39: CCSIP-SPI-CONTROL: act_idle_new_message*Mar 8 17:42:39: CCSIP-SPI-CONTROL: sact_idle_new_message_invite*Mar 8 17:42:39: CCSIP-SPI-CONTROL: sip_stats_method*Mar 8 17:42:39: sact_idle_new_message_invite:Not Using Voice Class Codec

*Mar 8 17:42:39: sact_idle_new_message_invite: Preferred codec[0] type: g711ulaw Bytes :160*Mar 8 17:42:39: sact_idle_new_message_invite: Media Negotiation successful for anincoming call

*Mar 8 17:42:39: sact_idle_new_message_invite: Negotiated Codec : g711ulaw, bytes :160Preferred Codec : g711ulaw, bytes :160

*Mar 8 17:42:39: CCSIP-SPI-CONTROL: sip_stats_status_code*Mar 8 17:42:39: Num of Contact Locations 1 3660110 166.34.245.230 5060

*Mar 8 17:42:39: CCSIP-SPI-CONTROL: act_recdinvite_proceeding*Mar 8 17:42:39: CCSIP-SPI-CONTROL: ccsip_caps_ind*Mar 8 17:42:39: ccsip_caps_ind: codec(negotiated) = 5(Bytes 160)*Mar 8 17:42:39: ccsip_caps_ind: Load DSP with codec (5) g711ulaw, Bytes=160*Mar 8 17:42:39: ccsip_caps_ind: set DSP for dtmf-relay = CC_CAP_DTMF_RELAY_INBAND_VOICE*Mar 8 17:42:39: CCSIP-SPI-CONTROL: ccsip_caps_ack*Mar 8 17:42:39: CCSIP-SPI-CONTROL: act_recdinvite_alerting*Mar 8 17:42:39: 180 Ringing with SDP - not likely

*Mar 8 17:42:39: CCSIP-SPI-CONTROL: sip_stats_status_code*Mar 8 17:42:42: CCSIP-SPI-CONTROL: act_sentalert_connect*Mar 8 17:42:42: sipSPIAddLocalContact*Mar 8 17:42:42: CCSIP-SPI-CONTROL: sip_stats_status_code*Mar 8 17:42:42: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 166.34.245.230:55674*Mar 8 17:42:42: CCSIP-SPI-CONTROL: act_sentsucc_new_message*Mar 8 17:42:42: CCSIP-SPI-CONTROL: sip_stats_method*Mar 8 17:42:47: CCSIP-SPI-CONTROL: act_active_disconnect*Mar 8 17:42:47: REQUEST CONNECTION TO IP:166.34.245.230 PORT:5060

*Mar 8 17:42:47: CCSIP-SPI-CONTROL: act_active_connection_created*Mar 8 17:42:47: CCSIP-SPI-CONTROL: sipSPICheckSocketConnection*Mar 8 17:42:47: CCSIP-SPI-CONTROL: sipSPICheckSocketConnection: Connid(1) created to 166.34.245.230:5060, local_port 56101*Mar 8 17:42:47: CCSIP-SPI-CONTROL: sip_stats_method*Mar 8 17:42:47: HandleUdpSocketReads :Msg enqueued for SPI with IPaddr: 166.34.245.230:55674*Mar 8 17:42:47: CCSIP-SPI-CONTROL: act_disconnecting_new_message*Mar 8 17:42:47: CCSIP-SPI-CONTROL: sact_disconnecting_new_message_response*Mar 8 17:42:47: CCSIP-SPI-CONTROL: sipSPICheckResponse*Mar 8 17:42:47: CCSIP-SPI-CONTROL: sip_stats_status_code*Mar 8 17:42:47: Roundtrip delay 0 milliseconds for method BYE

*Mar 8 17:42:47: CCSIP-SPI-CONTROL: sipSPICallCleanup*Mar 8 17:42:47: CLOSE CONNECTION TO CONNID:1



Session Initiation Protocol (SIP) for VoIPdebug ccsip events


debug ccsip events To display all Session Initiation Protocol (SIP) Service Provider Interface (SPI) events tracing and traces the events posted to SIP SPI from all interfaces, enter the debug ccsip events command in EXEC mode.

debug ccsip events


Command Modes EXEC

Defaults SIP SPI events tracing is not displayed

Command History

Usage Guidelines This command traces the events posted to SIP SPI from all interfaces.

Examples The following example shows debug output from one side of the call:

Router1# debug ccsip events

SIP Call events tracing is enabledRouter1#*Mar 6 14:17:57: Queued event from SIP SPI : SIPSPI_EV_CC_CALL_SETUP*Mar 6 14:17:57: Queued event from SIP SPI : SIPSPI_EV_CREATE_CONNECTION*Mar 6 14:17:57: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE*Mar 6 14:18:00: Queued event from SIP SPI : SIPSPI_EV_RECONNECT_CONNECTION*Mar 6 14:18:00: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE*Mar 6 14:18:04: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE*Mar 6 14:18:04: Queued event From SIP SPI to CCAPI/DNS : SIPSPI_EV_CC_CALL_DISCONNECT*Mar 6 14:18:04: Queued event from SIP SPI : SIPSPI_EV_CLOSE_CONNECTION








Session Initiation Protocol (SIP) for VoIPdebug ccsip events


The following example shows debug output from the other side of the call:

Router2# deb ccsip events

SIP Call events tracing is enabledRouter2#*Mar 8 17:43:55: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE*Mar 8 17:43:55: Queued event From SIP SPI to CCAPI/DNS : SIPSPI_EV_CC_CALL_PROCEEDING*Mar 8 17:43:55: Queued event From SIP SPI to CCAPI/DNS : SIPSPI_EV_CC_CALL_ALERTING*Mar 8 17:43:55: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE*Mar 8 17:43:58: Queued event From SIP SPI to CCAPI/DNS : SIPSPI_EV_CC_CALL_CONNECT*Mar 8 17:43:58: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE*Mar 8 17:44:01: Queued event From SIP SPI to CCAPI/DNS : SIPSPI_EV_CC_CALL_DISCONNECT*Mar 8 17:44:01: Queued event from SIP SPI : SIPSPI_EV_CREATE_CONNECTION*Mar 8 17:44:01: Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE*Mar 8 17:44:01: Queued event from SIP SPI : SIPSPI_EV_CLOSE_CONNECTION







Session Initiation Protocol (SIP) for VoIPdebug ccsip messages


debug ccsip messagesTo display all Session Initiation Protocol (SIP) Service Provider Interface (SPI) message tracing and to trace the SIP messages exchanged between the SIP UA client (UAC) and the access server, enter the debug ccsip messages command in Privileged EXEC mod.

debug ccsip messages


Defaults SIP SPI message tracing is not displayed

Command Modes EXEC

Command History

Usage Guidelines This command traces the SIP messages exchanged between the SIP user agent client (UAC) and the access server.

Examples The following example shows debug output from one side of the call:

Router1# debug ccsip messages

SIP Call messages tracing is enabledRouter1#*Mar 6 14:19:14: Sent: INVITE sip:[email protected];user=phone;phone-context=unknown SIP/2.0Via: SIP/2.0/UDP 166.34.245.230:55820From: "3660110" <sip:[email protected]>To: <sip:[email protected];user=phone;phone-context=unknown>Date: Sat, 06 Mar 1993 19:19:14 GMTCall-ID: [email protected]: 2881152943-2184249568-0-483551624User-Agent: Cisco VoIP Gateway/ IOS 12.x/ SIP enabledCSeq: 101 INVITE










Max-Forwards: 6Timestamp: 731427554Contact: <sip:[email protected]:5060;user=phone>Expires: 180Content-Type: application/sdpContent-Length: 138


*Mar 6 14:19:14: Received: SIP/2.0 100 TryingVia: SIP/2.0/UDP 166.34.245.230:55820From: "3660110" <sip:[email protected]>To: <sip:[email protected];user=phone;phone-context=unknown>Date: Mon, 08 Mar 1993 22:45:12 GMTCall-ID: [email protected]: 731427554Server: Cisco VoIP Gateway/ IOS 12.x/ SIP enabledCSeq: 101 INVITEContent-Length: 0

*Mar 6 14:19:14: Received: SIP/2.0 180 RingingVia: SIP/2.0/UDP 166.34.245.230:55820From: "3660110" <sip:[email protected]>To: <sip:[email protected];user=phone;phone-context=unknown>Date: Mon, 08 Mar 1993 22:45:12 GMTCall-ID: [email protected]: 731427554Server: Cisco VoIP Gateway/ IOS 12.x/ SIP enabledCSeq: 101 INVITEContent-Type: application/sdpContent-Length: 138


*Mar 6 14:19:16: Received: SIP/2.0 200 OKVia: SIP/2.0/UDP 166.34.245.230:55820From: "3660110" <sip:[email protected]>To: <sip:[email protected];user=phone;phone-context=unknown>;tag=27DBC6D8-1357Date: Mon, 08 Mar 1993 22:45:12 GMTCall-ID: [email protected]: 731427554Server: Cisco VoIP Gateway/ IOS 12.x/ SIP enabledContact: <sip:[email protected]:5060;user=phone>CSeq: 101 INVITEContent-Type: application/sdpContent-Length: 138

v=0o=CiscoSystemsSIP-GW-UserAgent 1193 7927 IN IP4 166.34.245.231



s=SIP Callt=0 0c=IN IP4 166.34.245.231m=audio 20224 RTP/AVP 0

*Mar 6 14:19:16: Sent: ACK sip:[email protected]:5060;user=phone SIP/2.0Via: SIP/2.0/UDP 166.34.245.230:55820From: "3660110" <sip:[email protected]>To: <sip:[email protected];user=phone;phone-context=unknown>;tag=27DBC6D8-1357Date: Sat, 06 Mar 1993 19:19:14 GMTCall-ID: [email protected]: 6Content-Type: application/sdpContent-Length: 138CSeq: 101 ACK


*Mar 6 14:19:19: Received: BYE sip:[email protected]:5060;user=phone SIP/2.0Via: SIP/2.0/UDP 166.34.245.231:53600From: <sip:[email protected];user=phone;phone-context=unknown>;tag=27DBC6D8-1357To: "3660110" <sip:[email protected]>Date: Mon, 08 Mar 1993 22:45:14 GMTCall-ID: [email protected]: Cisco VoIP Gateway/ IOS 12.x/ SIP enabledMax-Forwards: 6Timestamp: 731612717CSeq: 101 BYEContent-Length: 0

*Mar 6 14:19:19: Sent: SIP/2.0 200 OKVia: SIP/2.0/UDP 166.34.245.231:53600From: <sip:[email protected];user=phone;phone-context=unknown>;tag=27DBC6D8-1357To: "3660110" <sip:[email protected]>Date: Sat, 06 Mar 1993 19:19:19 GMTCall-ID: [email protected]: Cisco VoIP Gateway/ IOS 12.x/ SIP enabledTimestamp: 731612717Content-Length: 0CSeq: 101 BYE

The following example show debug output from the other side of the call:

Router2# debug ccsip messages

SIP Call messages tracing is enabledRouter2#*Mar 8 17:45:12: Received: INVITE sip:[email protected];user=phone;phone-context=unknown SIP/2.0Via: SIP/2.0/UDP 166.34.245.230:55820From: "3660110" <sip:[email protected]>To: <sip:[email protected];user=phone;phone-context=unknown>Date: Sat, 06 Mar 1993 19:19:14 GMTCall-ID: [email protected]



Cisco-Guid: 2881152943-2184249568-0-483551624User-Agent: Cisco VoIP Gateway/ IOS 12.x/ SIP enabledCSeq: 101 INVITEMax-Forwards: 6Timestamp: 731427554Contact: <sip:[email protected]:5060;user=phone>Expires: 180Content-Type: application/sdpContent-Length: 138


*Mar 8 17:45:12: Sent: SIP/2.0 100 TryingVia: SIP/2.0/UDP 166.34.245.230:55820From: "3660110" <sip:[email protected]>To: <sip:[email protected];user=phone;phone-context=unknown>Date: Mon, 08 Mar 1993 22:45:12 GMTCall-ID: [email protected]: 731427554Server: Cisco VoIP Gateway/ IOS 12.x/ SIP enabledCSeq: 101 INVITEContent-Length: 0

*Mar 8 17:45:12: Sent: SIP/2.0 180 RingingVia: SIP/2.0/UDP 166.34.245.230:55820From: "3660110" <sip:[email protected]>To: <sip:[email protected];user=phone;phone-context=unknown>Date: Mon, 08 Mar 1993 22:45:12 GMTCall-ID: [email protected]: 731427554Server: Cisco VoIP Gateway/ IOS 12.x/ SIP enabledCSeq: 101 INVITEContent-Type: application/sdpContent-Length: 138


*Mar 8 17:45:14: Sent: SIP/2.0 200 OKVia: SIP/2.0/UDP 166.34.245.230:55820From: "3660110" <sip:[email protected]>To: <sip:[email protected];user=phone;phone-context=unknown>;tag=27DBC6D8-1357Date: Mon, 08 Mar 1993 22:45:12 GMTCall-ID: [email protected]: 731427554Server: Cisco VoIP Gateway/ IOS 12.x/ SIP enabledContact: <sip:[email protected]:5060;user=phone>CSeq: 101 INVITEContent-Type: application/sdpContent-Length: 138




*Mar 8 17:45:14: Received: ACK sip:[email protected]:5060;user=phone SIP/2.0Via: SIP/2.0/UDP 166.34.245.230:55820From: "3660110" <sip:[email protected]>To: <sip:[email protected];user=phone;phone-context=unknown>;tag=27DBC6D8-1357Date: Sat, 06 Mar 1993 19:19:14 GMTCall-ID: [email protected]: 6Content-Type: application/sdpContent-Length: 138CSeq: 101 ACK


*Mar 8 17:45:17: Sent: BYE sip:[email protected]:5060;user=phone SIP/2.0Via: SIP/2.0/UDP 166.34.245.231:53600From: <sip:[email protected];user=phone;phone-context=unknown>;tag=27DBC6D8-1357To: "3660110" <sip:[email protected]>Date: Mon, 08 Mar 1993 22:45:14 GMTCall-ID: [email protected]: Cisco VoIP Gateway/ IOS 12.x/ SIP enabledMax-Forwards: 6Timestamp: 731612717CSeq: 101 BYEContent-Length: 0

*Mar 8 17:45:17: Received: SIP/2.0 200 OKVia: SIP/2.0/UDP 166.34.245.231:53600From: <sip:[email protected];user=phone;phone-context=unknown>;tag=27DBC6D8-1357To: "3660110" <sip:[email protected]>Date: Sat, 06 Mar 1993 19:19:19 GMTCall-ID: [email protected]: Cisco VoIP Gateway/ IOS 12.x/ SIP enabledTimestamp: 731612717Content-Length: 0CSeq: 101 BYE









Command Description

Session Initiation Protocol (SIP) for VoIPdebug ccsip states


debug ccsip statesTo display all Session Initiation Protocol (SIP) Service Provider Interface (SPI) state tracing, and to trace the state machine changes of SIP SPI and to display the stat transitions, enter the debug ccsip states command in EXEC mode.

debug ccsip states


Defaults SIP SPI state tracing is not displayed

Command Modes EXEC

Command History

Usage Guidelines This command traces the state machine changes of SIP SPI and displays the state transitions.







Session Initiation Protocol (SIP) for VoIPdebug ccsip states


Examples The following example shows output for the debug ccsip states command:

Router# debug ccsip states

SIP Call states tracing is enabledUA-1#*Jan 2 18:34:37.793:0x6220C634 :State change from (STATE_NONE, SUBSTATE_NONE) to (STATE_IDLE, SUBSTATE_NONE)*Jan 2 18:34:37.797:0x6220C634 :State change from (STATE_IDLE, SUBSTATE_NONE) to (STATE_IDLE, SUBSTATE_CONNECTING)*Jan 2 18:34:37.797:0x6220C634 :State change from (STATE_IDLE, SUBSTATE_CONNECTING) to (STATE_IDLE, SUBSTATE_CONNECTING)*Jan 2 18:34:37.801:0x6220C634 :State change from (STATE_IDLE, SUBSTATE_CONNECTING) to (STATE_SENT_INVITE, SUBSTATE_NONE)*Jan 2 18:34:37.809:0x6220C634 :State change from (STATE_SENT_INVITE, SUBSTATE_NONE) to (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_PROCEEDING)*Jan 2 18:34:37.853:0x6220C634 :State change from (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_PROCEEDING) to (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_ALERTING)*Jan 2 18:34:38.261:0x6220C634 :State change from (STATE_RECD_PROCEEDING, SUBSTATE_PROCEEDING_ALERTING) to (STATE_ACTIVE, SUBSTATE_NONE)*Jan 2 18:35:09.860:0x6220C634 :State change from (STATE_ACTIVE, SUBSTATE_NONE) to (STATE_DISCONNECTING, SUBSTATE_NONE)*Jan 2 18:35:09.868:0x6220C634 :State change from (STATE_DISCONNECTING, SUBSTATE_NONE) to (STATE_DEAD, SUBSTATE_NONE)*Jan 2 18:28:38.404: Queued event from SIP SPI :SIPSPI_EV_CLOSE_CONNECTION







Session Initiation Protocol (SIP) for VoIPdefault


default To reset the value of a command to its default, enter the default command in SIP user-agent configuration mode.

default {aaa username | max-forwards | retry {invite | response | bye | cancel} | sip-server | timers {trying | connect | disconnect | expires} | transport {tcp | udp}

Syntax Description

Defaults No default behavior or values


Command History

Examples The following example shows how to set max-forwards to its default of 6:

Router(config)# sip-uaRouter(config-sip-ua)# default max-forwards

Related Commands

aaa username Resets AAA related configuration.

max-forwards Resets max-forwards to its default of 6.

retry {invite | response | bye | cancel}

Resets the specified retry to its default. (6 for invite and response; 10 for bye and cancel).

sip-server Resets the sip-server to a null value.

timers {trying | connect | disconnect | expires}

Resets the specified retry to its default (500 for trying, connect, and disconnect; 180000 for expires).

transport {tcp | udp} Turns on the handling of SIP messages via UDP or TCP.







Command Description

cap-list vfc Adds a voice codec overlay file to the capability file list.

sip-ua Enables the SIP user-agent configuration commands, with which you configure the user agent.

Session Initiation Protocol (SIP) for VoIPgw-accounting


gw-accountingTo enable Voice over IP (VoIP) gateway-specific accounting and to define the accounting method, use the gw-accounting command in global configuration mode. To disable gateway-specific accounting, use the no form of this command.

gw-accounting {h323 [vsa] | syslog | voip}

no gw-accounting {h323 [vsa] | syslog | voip}

Syntax Description

Defaults Disabled

Command Modes Global configuration

Command History

Usage Guidelines To collect basic start-stop connection accounting data, the gateway must be configured to support gateway-specific H.323 accounting functionality. The gw-accounting command enables you to send accounting data to the RADIUS server in one of four ways:

• Using standard IETF RADIUS accounting attribute/value (AV) pairs—This method is the basic method of gathering accounting data (connection accounting) according to the specifications defined by the IETF. Use the gw-accounting h323 command to configure the standard IETF RADIUS method of applying H.323 gateway-specific accounting. Table 2 shows the supported IETF RADIUS attributes.

h323 Enables standard H.323 accounting using Internet Engineering Task Force (IETF) RADIUS attributes.

vsa (Optional) Enables H.323 accounting using RADIUS vendor-specific attributes (VSAs).

syslog Enables the system logging facility to output accounting information in the form of a system log message.

voip Enables generic gateway-specific accounting.


11.3(6)NA2 This command was introduced on the Cisco 2500 and Cisco 3600 series routers and the AS5300 universal access server.

12.0(7)T The vsa keyword was added.

12.1(1)T The voip keyword was added.

12.2(2)XA This command was implemented for the Cisco AS5400 and Cisco AS5350.


12.2(8)T This command was integrated into Cisco IOS Release 12.2(8)T and implemented on Cisco 7200 series routers.

12.2(11)T This command was integrated Cisco IOS Release 12.2(11)T for the Cisco AS5850 universal gateway.



For more information about RADIUS and the use of IETF-defined attributes, refer to the Cisco IOS Security Configuration Guide.

• Overloading the Acct-Session-Id field—Attributes that cannot be mapped to standard RADIUS are packed into the Acct-Session-Id attribute field as ASCII strings separated by the character “/”. The Acct-Session-Id attribute is defined to contain the RADIUS account session ID, which is a unique identifier that links accounting records associated with the same login session for a user. To support additional fields, we have defined the following string format for this field:

<session id>/<call leg setup time>/<gateway id>/<connection id>/<call origin>/<call type>/<connect time>/<disconnect time>/<disconnect cause>/<remote ip address>

Table 2 Supported IETF RADIUS Accounting Attributes

Number Attribute Description

30 Called-Station-Id Allows the network access server to send the telephone number that the user called as part of the Access-Request packet (using Dialed Number Identification Service [DNIS] or similar technology). This attribute is supported only on ISDN and modem calls on the Cisco AS5200 and Cisco AS5300 universal access server if used with ISDN PRI.

31 Calling-Station-Id Allows the network access server to send the telephone number that the call came from as part of the Access-Request packet (using Automatic Number Identification or similar technology). This attribute has the same value as “remote-addr” from TACACS+. This attribute is supported only on ISDN, and modem calls on the Cisco AS5200 and Cisco AS5300 universal access server if used with ISDN PRI.

42 Acct-Input-Octets Indicates how many octets have been received from the port over the course of the accounting service being provided.

43 Acct-Output-Octets Indicates how many octets have been sent to the port over the course of delivering the accounting service.

44 Acct-Session-Id Indicates a unique accounting identifier that makes it easy to match start and stop records in a log file. Acct-Session-Id numbers restart at 1 each time the router is power-cycled or the software is reloaded.

47 Acct-Input-Packets Indicates how many packets have been received from the port over the course of this service being provided to a framed user.

48 Acct-Output-Packets Indicates how many packets have been sent to the port in the course of delivering this service to a framed user.



Table 3 shows the field attributes that you use with the overloaded session-ID method and a brief description of each.

Because of the limited size of the Acct-Session-Id string, it is not possible to embed very many information elements in it. Therefore, this feature supports only a limited set of accounting information elements.

Use the gw-accounting h323 command to configure the overloaded session ID method of applying H.323 gateway-specific accounting.

Table 3 Field Attributes in Overloaded Acct-Session-ID

Field Attribute Description

Session-Id Specifies the standard RADIUS account session ID.

Setup-Time Provides the Q.931 setup time for this connection in Network Time Protocol (NTP) format. NTP time formats are displayed as %H: %M: %S %k %Z %tw %tn %td %Y where:

%H is hour (00 to 23).

%M is minutes (00 to 59).

%S is seconds (00 to 59).

%k is milliseconds (000 to 999).

%Z is timezone string.

%tw is day of week (Saturday through Sunday).

%tn is month name (January through December).

%td is day of month (01 to 31).

%Y is year including century (for example, 1998).

Gateway-Id Indicates the name of the underlying gateway in the form “gateway.domain_name.”

Call-Origin Indicates the origin of the call relative to the gateway. Possible values are originate and answer.

Call-Type Indicates the call leg type. Possible values are telephony and VoIP.

Connection-Id Specifies the unique global identifier used to correlate call legs that belong to the same end-to-end call. The field consists of 4 long words (128 bits). Each long word is displayed as a hexadecimal value and is separated by a space character.

Connect-Time Provides the Q.931 connect time for this call leg, in NTP format.

Disconnect-Time Provides the Q.931 disconnect time for this call leg, in NTP format.

Disconnect-Cause Specifies the reason a call was taken offline as defined in the Q.931 specification.

Remote-Ip-Address Indicates the address of the remote gateway port where the call is connected.



• Using vendor-specific RADIUS attributes—The IETF draft standard specifies a method for communicating vendor-specific information between the network access server and the RADIUS server by using the vendor-specific attribute (Attribute 26). Vendor-specific attributes (VSAs) allow vendors to support their own extended attributes not suitable for general use. The Cisco RADIUS implementation supports one vendor-specific option using the format recommended in the specification. The Cisco vendor ID is 9, and the supported option has vendor-type 1, which is named “cisco-avpair.” The value is a string of the format:

protocol: attribute sep value *

“Protocol” is a value of the Cisco “protocol” attribute for a particular type of authorization. “Attribute” and “value” are an appropriate attribute/value (AV) pair defined in the Cisco TACACS+ specification, and “sep” is “=” for mandatory attributes and “*” for optional attributes. This allows the full set of features available for TACACS+ authorization to also be used for RADIUS.

The VSA fields and their ASCII values are listed in Table 4.

Table 4 VSA Fields and Their ASCII Values

IETF RADIUS Attribute

Vendor-Specific Company Code

Subtype Number Attribute Name Description

26 9 23 h323-remote-address Indicates the IP address of the remote gateway.

26 9 24 h323-conf-id Identifies the conference ID.

26 9 25 h323-setup-time Indicates the setup time for this connection in Coordinated Universal Time (UTC) formerly known as Greenwich Mean Time (GMT) and Zulu time.

26 9 26 h323-call-origin Indicates the origin of the call relative to the gateway. Possible values are originating and terminating (answer).

26 9 27 h323-call-type Indicates the call leg type. Possible values are telephony and VoIP.

26 9 28 h323-connect-time Indicates the connection time for this call leg in UTC.

26 9 29 h323-disconnect-time Indicates the time this call leg was disconnected in UTC.

26 9 30 h323-disconnect-cause Specifies the reason a connection was taken offline per the Q.931 specification.

26 9 31 h323-voice-quality Specifies the impairment factor (ICPIF) affecting voice quality for a call.

26 9 33 h323-gw-id Indicates the name of the underlying gateway.



Use the gw-accounting h323 vsa command to configure the VSA method of applying H.323 gateway-specific accounting.

• Using syslog records—The syslog accounting option exports the information elements associated with each call leg through a system log message, which can be captured by a syslog daemon on the network. The syslog output consists of the following:

<server timestamp> <gateway id> <message number> : <message label> : <list of AV pairs>

The syslog message fields are listed in Table 5.

Use the gw-accounting syslog command to configure the syslog record method of gathering H.323 accounting data.

Use this command if you configure the AAA accounting application.

If you enable both h323 and syslog simultaneously, CDRs are generated in both methods.

Examples The following example configures basic H.323 accounting using IETF RADIUS attributes:

gw-accounting h323

The following example configures H.323 accounting using VSA RADIUS attributes:

gw-accounting h323 vsa

The following example enables gateway-specific accounting and defines the accounting method as voip:

gw-accounting voip

Related Commands

Table 5 Syslog Mesage Output Fields

Field Description

server timestamp The time stamp created by the server when it receives the message to log.

gateway id The name of the gateway that emits the message.

message number The number assigned to the message by the gateway.

message label A string used to identify the message category.

list of AV pairs A string that consists of <attribute name> <attribute value> pairs separated by commas.

Command Description

dial-peer voice Enters dial-peer configuration mode and specifies the method of voice-related encapsulation.

Session Initiation Protocol (SIP) for VoIPmax-forwards


max-forwardsTo set the maximum number of proxy or redirect servers that can forward the request, use the max-forwards command in SIP user agent configuration mode. To restore the default value, use the no form of this command.

max-forwards number

no max-forwards

Syntax Description

Defaults 6

Command Modes SIP user agent configuration

Command History

Usage Guidelines To reset this command to the default value, you can also use the default command.

Examples The following is an example of setting the number of forwarding requests to proxy or redirect servers:

sip-uamax-forwards 2

Related Commands

number Number of hops. Possible values are 1 through 15. The default is 6.


12.1(3)T This command was introduced on the Cisco 2600 and Cisco 3600 series routers and on the Cisco AS5300 universal access server.


12.2(2)XB1 This command was introduced on the Cisco AS5850 universal gateway.

12.2(8)T This command was integrated into Cisco IOS Release 12.2(8)T and implemented on Cisco 7200 series routers. This command does not support the Cisco AS5300, Cisco AS5350, Cisco AS5400, and Cisco AS5850 in this release.


Command Description

max-redirects Sets the maximum number of redirects that the user agent allows.

Session Initiation Protocol (SIP) for VoIPmax-redirects


max-redirectsTo set the maximum number of redirect servers that the user agent allows, use the max-redirects command in dial-peer configuration mode. To restore the default value, use the no form of this command.

max-redirects number

no max-redirects

Syntax Description

Defaults 1

Command Modes Dial-peer configuration

Command History

Examples The following is an example of setting the maximum number of redirect servers that the user agent allows:

dial-peer voice 102 voipmax-redirects 2

Related Commands

number Maximum number of redirect servers that a call can traverse. Range is 1 to 10. The default is 1.


12.1(1)T This command was introduced on the Cisco 2600 and Cisco 3600 series routers and on the Cisco AS5300 universal access server.



12.2(8)T This command was integrated into Cisco IOS Release 12.2(8)T and implemented on Cisco 7200 series. This command does not support the Cisco AS5300, Cisco AS5350, Cisco AS5400, and Cisco AS5850 in this release.


Command Description


Session Initiation Protocol (SIP) for VoIPretry bye


retry byeTo configure the number of times that a BYE request is retransmitted to the other user agent, use the retry bye command in SIP user-agent configuration mode. To reset to the default, use the no form of this command.

retry bye number

no retry bye number

Syntax Description

Defaults 10 retries


Command History


Examples In the following example, the number of BYE retries has been set to 5.sip-uaretry bye 5

Related Commands

number Number of BYE retries. Range is 1 to 10. The default is 10.


12.1(1)T This command was introduced on Cisco 2600 and Cisco 3600 series routers and Cisco AS5300 universal access servers.

12.2(2)XA This command was implemented on Cisco AS5350 and Cisco AS5400 universal gateways.

12.2(2)XB1 This command was implemented on Cisco AS5850 universal gateways.

12.2(8)T This command was integrated into Cisco IOS Release 12.2(8)T and implemented on Cisco 7200 series routers. This command was not supported on the Cisco AS5300, Cisco AS5350, Cisco AS5400, and Cisco AS5850 platforms in this release.


Command Description

default Resets the value of a command to its default.


Session Initiation Protocol (SIP) for VoIPretry cancel


retry cancelTo configure the number of times that a CANCEL request is retransmitted to the other user agent, use the retry cancel command in SIP user-agent configuration mode. To reset to the default, use the no form of this command.

retry cancel number

no retry cancel number

Syntax Description

Defaults 10 retries


Command History


Examples In the following example, the number of cancel retries has been set to 5.sip-uaretry cancel 5

Related Commands

number Number of CANCEL retries. Range is 1 to 10. The default is 10.







Command Description


sip-ua Enables the sip-ua configuration commands, with which you configure the user agent.

Session Initiation Protocol (SIP) for VoIPretry invite


retry inviteTo configure the number of times that a Session Initiation Protocol (SIP) INVITE request is retransmitted to the other user agent, use the retry invite command in SIP user-agent configuration mode. To reset to the default, use the no form of this command.

retry invite number

no retry invite number

Syntax Description

Defaults 6 retries


Command History


When configuring SIP using SIP user-agent configuration commands such as the retry invite command, the use of the default values for the commands causes the rotary function to not take effect. The rotary function is when you set up more than one VoIP dial peer for the same destination pattern, and the dial peers are assigned to different targets. The purpose of assigning different targets is if the call cannot be set up with the first dial peer (preference one), the next dial peer can be tried. For example:

dial-peer voice 201 voipdestination-pattern 1234567codec g711ulawsession protocol sipv2session target ipv4:1.2.3.4

dial-peer voice 202 voipdestination-pattern 12345..codec g711ulaw

number Number of INVITE retries. Range is 1 to 10. The default is 6.







Session Initiation Protocol (SIP) for VoIPretry invite


session protocol sipv2session target ipv4:10.2.3.42

To use the rotary function within SIP, set the retry value for the SIP retry invite command to 4 or less. For example:

sip-uaretry invite 4

Examples In the following example, the number of invite retries is set to 5.sip-uaretry invite 5




Session Initiation Protocol (SIP) for VoIPretry response


retry responseTo configure the number of times that the RESPONSE message is retransmitted to the other user agent, use the retry response command in SIP user-agent configuration mode. To reset to the default, use the no form of this command.

retry response number

no retry response number

Syntax Description

Defaults 6 retries


Command History


Examples The following example sets the number of response retries to 5.sip-uaretry response 5

Related Commands

number Number of RESPONSE retries. Range is 1 to 10. Default is 6.







Command Description



Session Initiation Protocol (SIP) for VoIPsession protocol


session protocolTo specify a session protocol for calls between local and remote routers using the packet network, use the session protocol command in dial-peer configuration mode. To reset to the default, use the no form of this command.

session protocol {aal2-trunk | cisco | sipv2 | smtp}

no session protocol

Syntax Description

Defaults No default behaviors or values


Command History

aal2-trunk Dial peer uses ATM adaptation layer 2 (AAL2) nonswitched trunk session protocol.

cisco Dial peer uses the proprietary Cisco Voice over IP (VoIP) session protocol.

sipv2 Dial peer uses the Internet Engineering Task Force (IETF) Session Initiation Protocol (SIP). Use this keyword with the SIP option.

smtp Dial peer uses Simple Mail Transfer Protocol (SMTP) session protocol.


11.3(1)T This command was introduced for VoIP peers on Cisco 3600 series routers.

12.0(3)XG Support was added for Voice over Frame Relay (VoFR) dial peers.

12.0(4)XJ This command was modified for store-and-forward fax on Cisco AS5300 universal access servers.

12.1(1)XA This command was implemented for VoATM dial peers on Cisco MC3810 multiservice access concentrators, and the aal2-trunk keyword was added.

12.1(1)T This command was integrated into Cisco IOS Release 12.1(1)T, and the sipv2 keyword was added.

12.1(2)T This command was integrated into Cisco IOS Release 12.1(2)T.

12.2(2)T This command was implemented on Cisco 7200 series routers.

12.2(4)T This command was introduced on Cisco 1750 access routers.

12.2(8)T This command was introduced on the Cisco 1751, Cisco 2600, Cisco 3600, Cisco 3725,and Cisco 3745 platforms.



Session Initiation Protocol (SIP) for VoIPsession protocol


Usage Guidelines The cisco keyword is applicable only to VoIP on the Cisco 1750, Cisco 1751, Cisco 3600 series, and Cisco 7200 series routers.

The aal2-trunk keyword is applicable only to VoATM on the Cisco MC3810 multiservice access concentrator and the Cisco 7200 series router.

This command applies to both on-ramp and off-ramp store-and-forward fax functions.

Examples The following example shows that AAL2 trunking has been configured as the session protocol:

dial-peer voice 10 voatm session protocol aal2-trunk

The following example shows that Cisco session protocol has been configured as the session protocol:

dial-peer voice 20 voip session protocol cisco

The following example shows that a VoIP dial peer for SIP has been configured as the session protocol for VoIP call signaling:

dial-peer voice 102 voipsession protocol sipv2

Related Commands

12.2(8)T This command was integrated into Cisco IOS Release 12.2(8)T and implemented on Cisco 7200 series routers. This command is not supported on the Cisco AS5300, Cisco AS5350, Cisco AS5400, and Cisco AS5850 in this release.

Note The aal2-trunk and smtp keywords are not supported on Cisco 7200 series routers.



Command Description


session target (VoIP) Configures a network-specific address for a dial peer.

Session Initiation Protocol (SIP) for VoIPsession target (VoIP)


session target (VoIP)To specify a network-specific address for a dial peer, use the session target command in dial-peer configuration mode. To restore default values for this parameter, use the no form of this command.

Note This command applies to all dial peers except plain old telephone service (POTS) dial peers.

session target {sip-server | ipv4:destination-address[:port-number] | dns:[$s$. | $d$. | $e$. | $u$.] host-name | loopback:rtp | loopback:compressed | loopback:uncompressed | ras | settlement provider-number}

no session target {ipv4:destination-address | dns:[$s$. | $d$. | $e$. | $u$.] host-name | loopback:rtp | loopback:compressed | loopback:uncompressed | ras | settlement provider-number}

Syntax Description sip-server Sets the session target to the global SIP server.

ipv4:destination-address Sets the IP address of the dial peer.

port-number (Optional) Specifies the port number to contact to complete the call leg.

dns:[$s$...]host-name Indicates that the domain name server resolves the name of the IP address. Valid entries for this parameter are characters representing the name of the host device.

(Optional) Use one of the following three wildcards with this keyword when defining the session target for Voice over IP (VoIP) peers:

• $s$.—Indicates that the source destination pattern will be used as part of the domain name.

• $d$.—Indicates that the destination number will be used as part of the domain name.

• $e$.—Indicates that the digits in the called number will be reversed, periods will be added between the digits of the called number, and this string will be used as part of the domain name.

• $u$.—Indicates that the unmatched portion of the destination pattern (such as a defined extension number) will be used as part of the domain name.

loopback:rtp Indicates that all voice data will be looped back to the source. This is applicable for VoIP peers.

loopback:compressed Indicates that all voice data will be looped back in compressed mode to the source. This is applicable for POTS peers.

loopback:uncompressed Indicates that all voice data will be looped back in uncompressed mode to the source. This is applicable for POTS peers.

ras Indicates that the registration, admission, and status (RAS) signaling function protocol is being used, meaning that a gatekeeper will be consulted to translate the E.164 address into an IP address.

settlement provider-number

Indicates that the settlement server is the target to resolve the terminating gateway address. Enter the provider IP address for provider- number.



Defaults The default for this command is enabled with no IP address or domain name defined.


Command History

Usage Guidelines Enter the session target command to specify a network-specific address or domain name for a dial peer. Whether you select a network-specific address or a domain name depends on the session protocol you select.

You can enter the session target dns command with or without the specified wild cards. Using the optional wildcards can reduce the number of VoIP dial-peer session targets you need to configure if you have groups of numbers associated with a particular router.

Examples The following example shows how to configure a session target using DNS for a host, “voice_router,” in the domain “cisco.com”:

Router(config)# dial-peer voice 102 voipRouter(config-dial-peer)# session target dns:voice_router.cisco.com

The following example shows how to configure a session target using DNS, with the optional $u$. wildcard. In this example, the destination pattern has been configured to allow for any four-digit extension, beginning with the numbers 1310222. The optional wildcard $u$. indicates that the router will use the unmatched portion of the dialed number—in this case, the four-digit extension—to identify the dial peer. As in the preceding example, the domain is “cisco.com.”



11.3(1)MA Support was added for VoFR, VoATM, VoHDLC, and POTS dial peers on the Cisco MC3810 multiservice concentrator.

12.0(3)T Support was added for VoIP and POTS dial peers on the Cisco AS5300 universal access server. The parameter was added for RAS.

12.0(3)XG Support was added for VoFR dial peers on the Cisco 2600 series and 3600 series routers.

12.0(4)T Support was added for VoFR and POTS dial peers on the Cisco 7200 series routers, and the support added in Cisco IOS Release 12.0(3)XG was integrated into Cisco IOS Release 12.0(4)T.

12.0(4)XJ Support was added for store-and-forward fax on the Cisco AS5300 universal access server platform.

12.1(1)T The sip-server option was added.



12.2(8)T This command was integrated into Cisco IOS Release 12.2(8)T. Support for the Cisco AS5300 universal access server, Cisco AS5350, Cisco AS5400, and Cisco AS5850 universal gateway is not included in this release.




Router(config)# dial-peer voice 10 voipRouter(config-dial-peer)# destination-pattern 1310222....Router(dial-peer-config)# session target dns:$u$.cisco.com

The following example shows how to configure a session target using DNS, with the optional $d$. wildcard. In this example, the destination pattern has been configured for 13102221111. The optional wildcard $d$. indicates that the router will use the destination pattern to identify the dial peer in the “cisco.com” domain.

Router(config)# dial-peer voice 10 voipRouter(config-dial-peer)# destination-pattern 13102221111Router(config-dial-peer)# session target dns:$d$.cisco.com

The following example shows how to configure a session target using DNS, with the optional $e$. wildcard. In this example, the destination pattern has been configured for 12345. The optional wildcard $e$. indicates that the router will reverse the digits in the destination pattern, add periods between the digits, and then use this reverse-exploded destination pattern to identify the dial peer in the “cisco.com” domain.

Router(config)# dial-peer voice 10 voipRouter(config-dial-peer)# destination-pattern 12345Router(config-dial-peer)# session target dns:$e$.cisco.com

The following example shows how to configure a session target using RAS:

Router(config)# dial-peer voice 11 voipRouter(config-dial-peer)# destination-pattern 13102221111Router(config-dial-peer)# session target ras

The following example shows how to configure a session target using the settlement server:

Router(dial-peer-config)# session target settlement:0


dial-peer voice Enters dial-peer configuration mode, and specifies the method of voice-related encapsulation.

sip-server Configures the SIP server interface.

Session Initiation Protocol (SIP) for VoIPsession transport


session transportTo configure the VoIP dial peer to use TCP or User Datagram Protocol (UDP) as the underlying transport layer protocol for Session Initiation Protocol (SIP) messages, use the session transport command in dial-peer configuration mode. To reset this command to the default value, use the no form of this command.

session transport {udp | tcp}

no session transport

Syntax Description

Defaults The SIP dial peer uses UDP.

Note The transport protocol for transport and session transport must be the same.


Command History

Usage Guidelines Use the show sip-ua status command to ensure that the transport protocol that you set using the session transport command matches the protocol set using the transport command.

Examples The following example shows how to configure a VoIP dial peer to use UDP as the underlying transport layer protocol for SIP messages:

Router(config)# dial-peer voice 102 voipRouter(dial-peer-config)# session transport udp

udp Configure the SIP dial peer to use the UDP transport layer protocol. This is the default.

tcp Configure the SIP dial peer to use the TCP transport layer protocol.







Session Initiation Protocol (SIP) for VoIPsession transport



dial-peer voice Enters dial-peer configuration mode, and specifies the method of voice-related encapsulation.

show sip-ua Displays information and settings for the Session Initiation Protocol (SIP) user agent (UA)

transport Configures the Session Initiation Protocol (SIP) user agent (gateway) for SIP signaling messages on inbound calls through the SIP TCP or UDP socket.

Session Initiation Protocol (SIP) for VoIPshow sip-ua


show sip-uaTo display information and settings for the Session Initiation Protocol (SIP) user agent (UA), use the show sip-ua command in privileged EXEC mode.

show sip-ua {map {pstn-sip | sip-pstn} | retry | statistics | status | timers}

Syntax Description


Command Modes Privileged EXEC

Command History

Examples The following example displays output for the show sip-ua retry command:

Router# show sip-ua retry

map Displays the PSTN cause to SIP status code or SIP status code to PSTN cause code mapping table.

pstn-sip (Optional) Displays the PSTN cause to SIP status code mapping table.

sip-pstn (Optional) Display the SIP status code to PSTN cause mapping table

retry Displays SIP protocol retry counts.

statistics Displays SIP UA response, traffic, and retry statistics.

status Displays SIP UA listener status.

timers Displays SIP UA protocol timers.



12.1(3)T The following changes were made:

• The statistics keyword was added.

• The statistics portion of the output from the status keyword was moved from the status keyword to the statistics keyword.

• The output from the timers keyword was changed to reflect the changes in the timers command.







SIP UA Retry Valuesinvite retry count = 2response retry count = 2bye retry count = 2cancel retry count = 1

The following example displays output for the show sip-ua statistics command:

Router# show sip-ua statistics

SIP Response Statistics (Inbound/Outbound) Informational: Trying 0/0, Ringing 0/0, Forwarded 0/0, Queued 0/0, SessionProgress 0/0 Success: OkInvite 0/0, OkBye 0/0, OkCancel 0/0, OkOptions 0/0 Redirection (Inbound only): MultipleChoice 0, MovedPermanently 0, MovedTemporarily 0, SeeOther 0, UseProxy 0, AlternateService 0 Client Error: BadRequest 0/0, Unauthorized 0/0, PaymentRequired 0/0, Forbidden 0/0, NotFound 0/0, MethodNotAllowed 0/0, NotAcceptable 0/0, ProxyAuthReqd 0/0, ReqTimeout 0/0, Conflict 0/0, Gone 0/0, LengthRequired 0/0, ReqEntityTooLarge 0/0, ReqURITooLarge 0/0, UnsupportedMediaType 0/0, BadExtension 0/0, TempNotAvailable 0/0, CallLegNonExistent 0/0, LoopDetected 0/0, TooManyHops 0/0, AddrIncomplete 0/0, Ambiguous 0/0, BusyHere 0/0 Server Error: InternalError 0/0, NotImplemented 0/0, BadGateway 0/0, ServiceUnavail 0/0, GatewayTimeout 0/0, BadSipVer 0/0 Global Failure: BusyEverywhere 0/0, Decline 0/0, NoExistAnywhere 0/0, NotAcceptable 0/0 SIP Total Traffic Statistics (Inbound/Outbound) Invite 0/0, Ack 0/0, Bye 0/0, Cancel 0/0, Options 0/0 Retry Statistics Invite 0, Bye 0, Cancel 0, Response 0

The following example displays output for the show sip-ua status command:

Router# show sip-ua status

SIP User Agent StatusSIP User Agent for UDP :ENABLEDSIP User Agent for TCP :ENABLEDSIP max-forwards :6

The following example displays output for the show sip-ua timers command:

Router# show sip-ua timers

SIP UA Timer Values (millisecs)trying 500, expires 180000, connect 500, disconnect 500



The following example displays output for the show sip-ua map pstn-sip command:

Router# show sip-ua map pstn-sipThe PSTN Cause to SIP Status code mapping table:-

PSTN-Cause Configured Default SIP-Status SIP-Status1 404 4042 404 4043 404 4044 500 5005 500 5006 500 5007 500 5008 500 5009 500 50015 500 50016 500 50017 486 48618 480 48019 480 48020 480 48021 403 40322 410 41026 404 40427 404 404...

The following example displays output for the show sip-ua map sip-pstn command:

doc-7204vxr# show sip-ua map sip-pstnThe SIP Status code to PSTN Cause mapping table:-

SIP-Status Configured Default PSTN-Cause PSTN-Cause400 127 127401 57 57402 21 21403 57 57404 1 1405 127 127406 127 127407 21 21408 102 102409 41 41410 1 1411 127 127413 127 127414 127 127415 79 79420 127 127480 18 18481 127 127...



Session Initiation Protocol (SIP) for VoIPsip-server


sip-serverTo configure a network address for the Session Initiation Protocol (SIP) server interface, use the sip-server command in SIP user-agent configuration mode.

sip-server {dns:[host-name] | ipv4:ip-addr[:port-num]}

Syntax Description

Defaults The default for this command is a null value.


Command History

Usage Guidelines If you use this command, you can then use the session target sip-server command on each dial peer instead of repeatedly entering the SIP server interface address for each dial peer.

To reset this command to a null value, use the default command. This command does not have a no form.

Examples The following example, beginning in global configuration mode, sets the global SIP server interface to the DNS host name “UA-1-f0.sip.com”:

sip-uasip-server dns:UA-1-f0.sip.com

dns: Sets the global SIP server interface to a Domain Name System (DNS) host name. If you do not specify a host name, the default DNS defined by the ip name-server command is used.

host-name (Optional) A valid DNS host name in the following format: name.gateway.xyz.

ipv4:ip-addr Sets the global SIP server interface to an IP address. A valid IP address takes the following format: xxx.xxx.xxx.xxx.

:port-num (Optional) Specifies the port number for the SIP server.





12.2(8)T This command was integrated into Cisco IOS Release 12.2(8)T and implemented on Cisco 7200 series routers. This command is not supported on the Cisco AS5300, Cisco AS5350, Cisco AS5400, and Cisco AS5850 platforms in this release.


Session Initiation Protocol (SIP) for VoIPsip-server



ip name-server Specifies the address of one or more name servers to use for name and address resolution.

session target (VoIP) Specifies a network-specific address for a dial peer.

sip-ua Enters SIP user-agent configuration mode, in order to configure the SIP user agent.

Session Initiation Protocol (SIP) for VoIPsip-ua


sip-uaTo enable the Session Initiation Protocol (SIP) user-agent configuration commands, in order to configure the user agent, use the sip-ua command in global configuration mode. To reset all SIP user-agent configuration commands to their default values, use the no form of this command.

sip-ua

no sip-ua



Command Modes Global configuration

Command History

Usage Guidelines Use the sip-ua command to enter SIP user-agent configuration mode. Table 6 lists the SIP user-agent configuration mode commands:


12.1(1)T This command was introduced on the Cisco 2600, Cisco 3600, and Cisco AS5300 platforms.



12.2(8)T This command was integrated into Cisco IOS Release 12.2(8)T and implemented on Cisco 7200 series routers. This command is not supported on the Cisco AS5300, Cisco AS5350, Cisco AS5400, and Cisco AS5850 platforms in this release.


Table 6 SIP User-Agent Configuration Mode Commands

Command Description

exit Exits SIP user-agent configuration mode.

inband-alerting This command is no longer supported as of Cisco IOS Release 12.2. This command is no longer needed because the gateway handles remote or local ringback on the basis of SIP messaging.

max-forwards Specifies the maximum number of hops for a request.

retry Configures the SIP signaling timers for retry attempts.

sip-server Configures a SIP server interface.

Session Initiation Protocol (SIP) for VoIPsip-ua


Examples The following example, beginning in global configuration mode, enters SIP user-agent configuration mode, configures the SIP user agent, and then returns to global configuration mode:

sip-uaretry invite 2retry response 2retry bye 2retry cancel 2sip-server ipv4:10.0.2.254timers invite-wait-100 500exit

Related Commands

timers Configures the SIP signaling timers.

transport Enables or disables a SIP user agent transport for TCP or UDP that the protocol SIP user agents listen for on port 5060 (default).

Table 6 SIP User-Agent Configuration Mode Commands

Command Description

Command Description

exit Exits SIP user-agent configuration mode.

max-forwards Specifies the maximum number of hops for a request.

retry Configures the retry attempts for SIP messages.

show sip-ua Displays statistics for SIP retries, timers, and current listener status.

sip-server Configures the SIP server interface.

timers Configures the SIP signaling timers.

transport Configures the SIP user agent (gateway) for SIP signaling messages on inbound calls through the SIP TCP or UDP socket.

Session Initiation Protocol (SIP) for VoIPtimers


timersTo configure the Session Initiation Protocol (SIP) signaling timers, use the timers command in the Session Initiation Protocol (SIP) user-agent configuration mode. To restore the default value, use the no form of this command.

timers {trying number | connect number | disconnect number | expires number}

no timers {trying number | connect number | disconnect number | expires number}

Syntax Description

Defaults trying, connect, and disconnect—500expires—180000


Command History

Usage Guidelines If you used the previous version of this command to configure timers, your previous timer settings will be maintained. The output of the show running configuration command will reflect both timers.

To reset this command to the default value, you can also use the default command.

trying number Time (in milliseconds) to wait for a 100 response to an INVITE request. Possible values are 100 to 1000. The default is 500.

connect number Time (in milliseconds) to wait for a 200 response to an ACK request. Possible values are 100 to 1000. The default is 500.

disconnect number Time (in milliseconds) to wait for a 200 response to a BYE request. Possible values are 100 to 1000. The default is 500.

expires number Time (in milliseconds) for which an INVITE request is valid. Possible values are 60000 to 300000. The default is 180000.



12.1(3)T This command was modified to change the names of the parameters. Two of the parameters (invite-wait-180 and invite-wait-200) were combined into one (trying).





Session Initiation Protocol (SIP) for VoIPtimers


Examples The following example shows how to configure the SIP signaling timers to wait 500 milliseconds for a 100 response to an INVITE request:

Router(config)# sip-uaRouter(config-sip-ua)# timers trying 500



Session Initiation Protocol (SIP) for VoIPtransport


transportTo configure the Session Initiation Protocol (SIP) user agent (gateway) for SIP signaling messages on inbound calls through the SIP TCP or UDP socket, use the transport command in SIP user-agent configuration mode. To block reception of SIP signaling messages on a particular socket, use the no form of this command.

transport {udp | tcp}

no transport {udp | tcp}

Syntax Description

Defaults Bboth UDP and TCP transport layer protocols are enabled


Command History

Usage Guidelines This command controls whether messages reach the SIP service provider interface (SPI). By setting udp or tcp as the protocol, this will be the protocol SIP user agents will be listening for on port 5060 (default). To block reception of SIP signaling messages on a specific socket, use the no form of this command.

To reset this command to the default value, use the default command.

Examples The following example shows how to configure the SIP user agent to block reception of SIP signaling messages on the TCP socket:

Router(config)# sip-uaRouter(config-sip-ua)# no transport tcp

udp Configures the SIP user agent to receive SIP messages on UDP port 5060.

tcp Configures the SIP user agent to receive SIP messages on TCP port 5060.



12.1(3)T Support for access platforms was added.





Session Initiation Protocol (SIP) for VoIPtransport




Session Initiation Protocol (SIP) for VoIPGlossary


GlossaryAAA—authentication, authorization, and accounting. AAA is a suite of network security services that provides the primary framework through which access control can be set up on your Cisco router or access server.

ANI—automatic number identification. SS7 (signaling system 7) feature in which a series of digits, either analog or digital, are included in the call, identifying the telephone number of the calling device. In other words, ANI identifies the number of the calling party.

call—In SIP, a call consists of all participants in a conference invited by a common source. A SIP call is identified by a globally unique call ID. A point-to-point IP telephony conversation maps into a single SIP call. For a multicast session, each participant in the session constitutes a unique call. Each call involves a UAC and a UAS application.

Call-ID—A general header field that uniquely identifies a particular invitation or all registrations of a particular client.

call leg— A logical connection between the router and another endpoint.

CAS—channel associated signaling. The transmission of signaling information within the voice channel. CAS signaling often is referred to as robbed-bit signaling because user bandwidth is being robbed by the network for other purposes.

cause code—Defined by ITU Series Q Recommendation 850. Indicates the reason for PSTN call failure or completion.

CCAPI—call control applications programming interface.

CED—called terminal identification tone (2100 Hz sent by a fax receiver for 3 seconds).

CLI—command line interface. Interface that allows the user to interact with the operating system by entering commands and optional arguments. The UNIX operating system and DOS provide CLIs.

CNG—calling tone (1100 Hz sent by fax sender for 500 ms).

CO—central office. Local telephone company office to which all local loops in a given area connect and in which circuit switching of subscriber lines occurs.

codec—coder-decoder. Transforms analog signals into a digital bit stream, and digital signals back into analog signals. In VoIP applications, it specifies the voice coder rate of speech for a dial peer.

COMET—conditions met. A SIP method that indicates if the preconditions for a given call or session have been met.

CPE—customer premises equipment. Terminating equipment, such as terminals, telephones, and modems, supplied by the telephone company, installed at the customer sites, and connected to the telephone company network.

CSM—call switching module.

dial peer—An addressable call endpoint. In Voice over IP (VoIP), there are two types of dial peers: POTS and VoIP.

DCS—Distributed Call Signaling. A set of proposals by the PacketCable Consortium for extending SIP.

DNIS—dialed number identification service (the called number).

DNS—Domain Name System. System used in the Internet for translating names of network nodes into addresses.

DNS SRV—Domain Name System Server. Used to locate servers for a given service.

DSP—digital signal processor.



DTMF—dual tone multifrequency. Use of two simultaneous voice-band tones for dialing (such as touch tone).

E.164—The international public telecommunications numbering plan. A standard set by ITU-T which addresses telephone numbers.

E&M—recEive and transMit (or ear and mouth). Trunking arrangement generally used for two-way switch-to-switch or switch-to-network connections. Cisco’s analog E&M interface is an RJ-48 connector that allows connections to PBX trunk lines (tie lines). E&M is also available on E1 and T1 digital interfaces.

endpoint—An H.323 terminal or gateway. An endpoint can call and be called. It generates and/or terminates the information stream.

Fax Relay—Detecting, encoding, and transmitting fax tones, and regenerating them at the other end.

final-recipient—User agent introduced into a call with the recipient.

FQDN—fully qualified domain name. Complete domain name including the host portion; for example, serverA.companyA.com.

gateway—A gateway allows SIP or H.323 terminals to communicate with terminals configured to other protocols by converting protocols. A gateway is the point where a circuit-switched call is encoded and repackaged into IP packets.

hairpinning—A call routing capability in which an incoming call on a specific gateway is signaled through the IP network and back out the same gateway.

H.323—An International Telecommunication Union (ITU-T) standard that describes packet-based video, audio, and data conferencing. H.323 is an umbrella standard that describes the architecture of the conferencing system and refers to a set of other standards (H.245, H.225.0, and Q.931) to describe its actual protocol.

H.323 RAS—registration, admission, and status. The RAS signaling function performs registration, admissions, bandwidth changes, status and disengage procedures between the VoIP gateway and the gatekeeper.

INVITE—A method that initiates a session. It indicates that a user is invited to participate, provides a session description, indicates the type of media, and provides insight regarding the capabilities of the called and calling parties.

IP— Internet protocol. A connectionless protocol that operates at the network layer (layer 3) of the OSI model. IP provides features for addressing, type-of-service specification, fragmentation and reassemble, and security. Defined in RFC 791. This protocol works with TCP and is usually identified as TCP/IP. See TCP/IP.

ISDN—Integrated Services Digital Network. Communication protocol offered by telephone companies that permits telephone networks to carry data, voice, and other source traffic.

IVR—integrated voice response. When someone dials in, IVR responds with a prompt to get a personal identification number (PIN), and so on.

LEC—local exchange carrier. Local or regional telephone company that owns and operates a telephone network and the customer lines that connect to it.

Location Server—A SIP redirect or proxy server uses a a location service to get information about a caller’s location(s). Location services are offered by location servers.

MF—Multifrequency tones are made of six frequencies that provide 15 two frequency combinations for indication digits 0-9 and KP/ST signals.

MGCP—Media Gateway Control Protocol. A protocol for the control of Voice-over-IP (VoIP) calls by external call-control elements known as media gateway controllers (MGCs) or call agents (CAs).



modem passthrough—The transport of modem signals through a packet network by using pulse code modulation (PCM) encoded packets.

multicast—A process of transmitting PDUs from one source to many destinations. The actual mechanism (that is, IP multicast, multi-unicast, and so forth) for this process might be different for LAN technologies.

multipoint-unicast—A process of transferring PDUs (Protocol Data Units) where an endpoint sends more than one copy of a media stream to different endpoints. This can be necessary in networks which do not support multicast.

node—An H.323 entity that uses RAS to communicate with the gatekeeper, for example, an endpoint such as a terminal, proxy, or gateway.

NSE—named signaling event. Format of RTP packets used for applications such as modem relay and Fax Relay. NSEs have different payload values than Named Telephone Events (NTEs.)

NTE—Named Telephone Event. An event such as DTMF digits that must be encoded and transported in an RTP packet. RFC 2833 specifies the format of the RTP NTE payload.

OGW—originating VoIP gateway.

originator—User agent that initiates the transfer or Refer request with the recipient.

PCM— pulse code modulation.

PDU—protocol data units used by bridges to transfer connectivity information.

POTS—Plain old telephone service. Basic telephone service supplying standard single-line telephones, telephone lines, and access to the PSTN.

PRACK—Provisional Acknowledgement. Allows reliable exchanges of SIP provisional responses between SIP endpoints.

Preamble Flag Sequence V21— Conditioning that proceeds all binary coded signaling. Series of flags are repeated for one second during the start of the fax sequence.

provisional responses—Informational responses that are often used for responding to an INVITE and provide information on call progress. Reliability is not guaranteed when delivered over UDP.

proxy—A SIP UAC or UAS that forwards requests and responses on behalf of another SIP UAC or UAS.

Proxy Server—An intermediary program that acts as both a server and a client for the purpose of making requests on behalf of other clients. Requests are serviced internally or by passing them on, possibly after translation, to other servers. A proxy interprets, and, if necessary, rewrites a request message before forwarding it.

PSTN—public switched telephone network. PSTN refers to the local telephone company.

QoS—Quality of Service. Measure of performance for a transmission system that reflects its transmission quality and service availability. QoS refers to the ability of a network to provide better service to selected network traffic over various underlying technologies. QoS is not inherent in a network infrastructure. Rather, you must institute QoS by strategically deploying features that implement it throughout the network.

RAS—Registration, admission, and status protocol. This is the protocol that is used between endpoints and the gatekeeper to perform management functions.

RBS—robbed bit signaling.

Redirect Server—A redirect server is a server that accepts a SIP request, maps the address into zero or more new addresses and returns these addresses to the client. It does not initiate its own SIP request nor accept calls.



Registrar—A registrar is a server that accepts REGISTER requests. A registrar is typically co-located with a proxy or redirect server and may offer location services.

RSVP—Resource Reservation Protocol.

RTCP—RTP Control Protocol. The protocol monitors an RTP connection and conveys information about the ongoing session.

RTP—Real-Time Transport Protocol. A protocol for transporting multimedia over IP; see RFC 1889, RTP: A Transport Protocol for Real-Time Applications.

session—In SIP, a session is a set of multimedia senders and receivers and the data streams flowing between the senders and receivers. A SIP multimedia conference is an example of a session. A caller can be invited several times, by different calls, to the same session.

SDP—Session Description Protocol. A protocol for defining information needed to establish multimedia transport over IP. SDP transmits information such as session announcement, session invitation, transport addresses, and media types. In a SIP call, SDP messages indicates if NTE will be used, which events will be sent using NTE, and the NTE payload type value. See RFC 2327, SDP: Session Description Protocol.

SIP—Session Initiation Protocol. This is a protocol developed by the IETF MMUSIC Working Group as an alternative to H.323. SIP features are compliant with IETF RFC 2543, published in March 1999. SIP equips platforms to signal the setup of voice and multimedia calls over IP networks.

SIP URL—Session Initiation Protocol Uniform Resource Locator. Used in SIP messages to indicate the originator, recipient, and destination of the SIP request. Takes the basic form of user@host, where user is a name or telephone number, and host is a domain name or network address.

SPI—service provider interface.

TCL IVR— Tool Command Language (TCL) Interactive Voice Response (IVR).

TCP—Transmission Control Protocol. Connection-oriented transport layer protocol that provides reliable full-duplex data transmissions. TCP is part of the TCP/IP protocol stack. See also TCP/IP.

TCP/IP—Transmission Control Protocol/Internet Protocol. Common name for the suite of protocols developed by the US Department of Defense in the 1970s to support the construction of worldwide internetworks. TCP and IP are the two best known protocols in the suite. See also TCP and IP.

TDM—Time-division multiplexing. Technique in which information from multiple channels can be allocated bandwidth on a single wire based on preassigned time slots. Bandwidth is allocated to each channel regardless of whether the station has data to transmit.

TEL URL—Telephone Uniform Resource Locator. Describes voice call connections to a terminal. Can also be any connection through a voice messaging system or a service that can be operated using DTMF tones. Takes the basic form of tel:telephone subscriber number, where tel indicates a URL and requests the local entity to place a voice call, and telephone subscriber number is the number to receive the call.

TGW—terminating VoIP gateway.

T.38 Fax—ITU-T Recommendation for T.38 describes the features necessary to transfer facsimile documents in real-time between two standard Group 3 facsimile terminals over the Internet or other networks, by using IP protocols.

User Agent—A combination of UAS and UAC that initiates and receives calls. See UAS and UAC.

UAC—User Agent Client: A user agent client is a client application that initiates the SIP request.

UAS—User Agent Server (or user agent): A user agent server is a server application that contacts the user when a SIP request is received, then returns a response on behalf of the user. The response accepts, rejects, or redirects the request.



UDP—User Datagram Protocol. Connectionless transport layer protocol in the TCP/IP protocol stack. UDP is a simple protocol that exchanges datagrams without acknowledgments or guaranteed delivery, requiring that error processing and retransmission be handled by other protocols. UDP is defined in RFC 768.

UDPTL—facsimile user datagram protocol transport layer, as defined in ITU-T T.38. Additional transport layer used on top of UDP to make the delivery of the packets more reliable.

Via header—Part of an INVITE; includes information about the transport paths taken by a SIP request.

VoIP—Voice over IP. The ability to carry normal telephone-style voice over an IP-based Internet with POTs-like functionality, reliability, and voice quality. VoIP is a blanket term, which generally refers to Cisco’s standards-based (for example H.323) approach to IP voice traffic.

session initiation protocol (sip) for voip

Documents

cisco sip functionality

cisco as5350

cisco routersto

onthe cisco

cisco iosrelease

sip inviterequest

t sip enhancements

integrated cisco ios