Use Cisco Feature Navigator to find information about platform support and Cisco software image support. To access Cisco Feature Navigator, go to http://www.cisco.com/go/cfn.An account on Cisco.com is not required.

Information About Basic SIP Configuration

SIP Register Support

With H.323, Cisco IOS gateways can register E.164 numbers of a POTS dial peer with a gatekeeper, which informs the gatekeeper of a user's contact information. Session Initiation Protocoal (SIP) gateways allow the same functionality, but with the registration taking place with a SIP proxy or registrar. SIP gateways allow registration of E.164 numbers to a SIP proxy or registrar on behalf of analog telephone voice ports (FXS), IP phone virtual voice ports (EFXS), and local SCCP phones.

When registering dial peers with an external registrar, you can also register with a secondary SIP proxy or registrar to provide redundancy. The secondary registration can be used if the primary registrar fails.

SIP gateways allow registration of E.164 numbers to a SIP proxy or registrar server on behalf of analog telephone voice ports (FXS), IP phone virtual voice ports (EFXS), and local SCCP phones. By default, SIP gateways do not generate SIP Register messages. The following tasks set up the gateway to register E.164 telephone numbers with an external SIP registrar.

Note There are no commands that allow registration between the H.323 and SIP protocols.

SIP Redirect Processing Enhancement

SIP Redirect Processing allows flexibility in the handling of incoming redirect or 3xx class of responses. Redirect responses can be enabled or disabled through the command-line interface, providing a benefit to service providers who deploy Cisco SIP gateways. Redirect processing is active by default, which means that SIP gateways handle incoming 3xx messages in compliance with RFC 2543. RFC 2543 states that redirect response messages are used by SIP user agents to initiate a new Invite when a user agent learns that a user has moved from a previously known location.

In accordance with RFC 2543-bis-04, the processing of 3xx redirection is as follows:

•The uniform resource identifier (URI) of the redirected INVITE is updated to contain the new contact information provided by the 3xx redirect message.

•The transmitted CSeq number found in the CSeq header is increased by one. The new INVITE includes the updated CSeq.

•The To, From, and Call ID headers that identify the call leg remain the same. The same Call ID gives consistency when capturing billing history.

•The UAC retries the request at the new address given by the 3xx Contact header field.

Redirect handling can be disabled by using the no redirection command in SIP user-agent configuration mode. In this case, the user agent treats incoming 3xx responses as 4xx error class responses. The call is not redirected, and is instead released with the appropriate PSTN cause-code message. Table 1 shows the mapping of 3xx responses to 4xx responses.

Table 1 Mapping of 3xx Responses to 4xx Responses

Redirection (3
xx) Response Message

Mapping to 4
xx (Client Error) Response

300 Multiple choices

410 Gone

301 Moved Permanently

410 Gone

302 Moved Temporarily

480 Temporarily Unavailable

305 Use Proxy

410 Gone

380 Alternative Service

410 Gone

<any other 3xx response>

410 Gone

SIP Redirect Processing generates call history information with appropriate release cause codes that maybe used for accounting or statistics purposes. When a 3xx response is mapped to 4xx class of response, the cause code stored in call history is based on the mapped 4xx response code.

Call redirection must be enabled on the gateway for SIP call transfer involving redirect servers to be successful.

The Cisco IOS voice gateway can also use call redirection if an incoming VoIP call matches an outbound VoIP dial peer. The gateway sends a 300 or 302 Redirect message to the call originator, allowing the originator to reestablish the call. Two commands allow you to enable the redirect functionality, globally or on a specific inbound dial peer: redirect ip2ip (dial-peer) andredirect ip2ip (voice service).

Sending SIP 300 Multiple Choice Messages

Originally, when a call was redirected, the SIP gateway would send a 302 Moved Temporarily message. The first longest match route on a gateway (dial-peer destination pattern) was used in the Contact header of the 302 message. Now, if multiple routes to a destination exist for a redirected number (multiple dial peers are matched), the SIP gateway sends a 300 Multiple Choice message, and the multiple routes in the Contact header are listed.

The redirect contact order command gives you the flexibility to choose the order in which routes appear in the Contact header.

•When IP-to-IP redirection is configured in dial-peer configuration mode, the configuration on the specific inbound dial peer takes precedence over the global configuration entered under voice service configuration.

SUMMARY STEPS

1. enable

2. configure terminal

3. dial-peer voice voip

4. application

5. redirect ip2ip

6. exit

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Router> enable

Enters privileged EXEC mode or any other security level set by a system administrator. Enter your password if prompted.

Step 2

configureterminal

Example:

Router# configure terminal

Enters global configuration mode.

Step 3

dial-peer voice tag voip

Example:

Router(config)# dial-peer voice 29 voip

Use this command to enter dial-peer configuration mode. The argument is as follows:

Enables a specific application on a dial peer. The argument is as follows:

•application-name—Name of the predefined application you wish to enable on the dial peer. For SIP, the default Tcl application (from the Cisco IOS image) is session and can be applied to both VoIP and POTS dial peers. The application must support IP-to-IP redirection

Configuring Sending of SIP 300 Multiple Choice Messages

Note If multiple routes to a destination exist for a redirected number (multiple dial peers are matched), the SIP gateway sends a 300 Multiple Choice message and the multiple routes in the Contact header are listed. This configuration allows users to choose the order in which the routes appear in the Contact header.

SUMMARY STEPS

1. enable

2. configureterminal

3. voice service voip

4. sip

5. redirect contact order

6. exit

DETAILED STEPS

Command or Action

Purpose

Step 1

enable

Example:

Router> enable

Enters privileged EXEC mode or any other security level set by a system administrator. Enter your password if prompted.

Step 2

configureterminal

Example:

Router# configure terminal

Enters global configuration mode.

Step 3

voice service voip

Example:

Router(config)# voice service voip

Enters voice-service VoIP configuration mode.

Step 4

sip

Example:

Router(config-voi-serv)# sip

Enters SIP configuration mode.

Step 5

redirect contact order [best-match | longest-match]

Example:

Router(conf-serv-sip)# redirect contact order best-match

Sets the order of contacts in the 300 Multiple Choice Message. Keywords are as follows:

•best-match—Use the current system configuration to set the order of contacts.

•longest-match—Set the contact order by using the destination pattern longest match first, and then the second longest match, the third longest match, and so on. This is the default.

Step 6

exit

Example:

Router(conf-serv-sip)# exit

Exits the current mode.

Configuring SIP Implementation Enhancements

Minor underlying or minimally configurable features are described in the following sections:

Interaction with Forking Proxies

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.

Support for call forking enables the terminating gateway to handle multiple requests and the originating gateway to handle multiple provisional responses for the same call. Interaction with forking proxies applies to gateways acting as a UAC, and takes place when a user is registered to several different locations. When the UAC sends an INVITE message to a proxy, the proxy forks the request and sends it to multiple user agents. The SIP gateway processes multiple 18X responses by treating them as independent transactions under the same call ID. When the relevant dial peers are configured for QoS, the gateway maintains state and initiates RSVP reservations for each of these independent transactions. When it receives an acknowledgment, such as a 200 OK, the gateway accepts the successful acknowledgment and destroys state for all other transactions.

The forking feature sets up RSVP for each transaction only if the dial peers are configured for QoS. If not, the calls proceed as best-effort.

Support for interaction with forking proxies applies only to gateways acting as UACs. It does not apply when the gateway acts as a UAS. In that case, the proxy forks multiple INVITES with the same call ID to the same gateway but with different request URLs.

Also, the forking feature sets up RSVP for each transaction only if the dial peers are configured for QoS. If not, the calls proceed as best-effort.

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 PSTN call routed into the IP network and back out to the PSTN over the same gateway (see Figure 11).

Figure 11 PSTN Hairpinning Example

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 (see Figure 12).

Figure 12 Telephone Line Hairpinning Example

With SIP hairpinning, unique gateways for ingress and egress are unnecessary.

SIP supports plain old telephone service (POTS)-to-POTS hairpinning (which means that the call comes in one voice port and is routed 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 that the SIP gateway cannot take an inbound SIP call and reroute it back to another SIP device using the VoIP dial peers.

Only minimal configuration is required for this feature. To enable hairpinning on the SIP gateway, see the following configuration example for dial peers. Note that:

•The POTS dial peer must have preference 2 defined, and the VoIP dial peer must have preference 1 defined. This ensures that the call is sent out over IP, not Plain Old Telephone Service (POTS).

•The session target is the same gateway because the call is being redirected to it.

!

dial-peer voice 53001 pots

preference 2

destination-pattern 5300001

prefix 5300001

!

dial-peer voice 53002 pots

preference 2

destination-pattern 5300002

prefix 5300002

!

dial-peer voice 530011 voip

preference 1

destination-pattern 5300001

session protocol sipv2

session target ipv4:10.1.1.41

playout-delay maximum 300

codec g711alaw

!

dial-peer voice 530022 voip

preference 1

destination-pattern 5300002

session protocol sipv2

session target ipv4:10.1.1.41

playout-delay maximum 300

codec g711alaw

Verifying SIP Gateway Status

To verify SIP gateway status and configuration, perform the following steps as appropriate (commands are listed in alphabetical order).

SUMMARY STEPS

1. show sip service

2. show sip-ua register status

3. show sip-ua statistics

4. show sip-ua status

5. show sip-ua timers

DETAILED STEPS

Step 1 show sip service

Use this command to display the status of SIP call service on a SIP gateway.

The following sample output shows that SIP call service is enabled:

Router# show sip service

SIP Service is up

The following sample output shows that SIP call service was shut down with the shutdown command:

Router# show sip service

SIP service is shut globally

under 'voice service voip'

The following sample output shows that SIP call service was shut down with the call service stop command:

Router# show sip service

SIP service is shut

under 'voice service voip', 'sip' submode

The following sample output shows that SIP call service was shut down with the shutdown forced command:

Router# show sip service

SIP service is forced shut globally

under 'voice service voip'

The following sample output shows that SIP call service was shut down with the call service stop forced command:

Router# show sip service

SIP service is forced shut

under 'voice service voip', 'sip' submode

Step 2 show sip-ua register status

Use this command to display the status of E.164 numbers that a SIP gateway has registered with an external primary SIP registrar.

Router# show sip-ua register status

Line peer expires(sec) registered

4001 20001 596 no

4002 20002 596 no

5100 1 596 no

9998 2 596 no

Step 3 show sip-ua statistics

Use this command to display response, traffic, and retry SIP statistics, including whether call redirection is disabled.

The following sample shows that four registers were sent:

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,

OkPrack 0/0, OkPreconditionMet 0/0,

OkSubscribe 0/0, OkNOTIFY 0/0,

OkInfo 0/0, 202Accepted 0/0

OkRegister 12/49

Redirection (Inbound only except for MovedTemp(Inbound/Outbound)) :

MultipleChoice 0, MovedPermanently 0,

MovedTemporarily 0/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,

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, RequestCancel 0/0,

NotAcceptableMedia 0/0, BadEvent 0/0,

SETooSmall 0/0

Server Error:

InternalError 0/0, NotImplemented 0/0,

BadGateway 0/0, ServiceUnavail 0/0,

GatewayTimeout 0/0, BadSipVer 0/0,

PreCondFailure 0/0

Global Failure:

BusyEverywhere 0/0, Decline 0/0,

NotExistAnywhere 0/0, NotAcceptable 0/0

Miscellaneous counters:

RedirectRspMappedToClientErr 0

SIP Total Traffic Statistics (Inbound/Outbound)

Invite 0/0, Ack 0/0, Bye 0/0,

Cancel 0/0, Options 0/0,

Prack 0/0, Comet 0/0,

Subscribe 0/0, NOTIFY 0/0,

Refer 0/0, Info 0/0

Register 49/16

Retry Statistics

Invite 0, Bye 0, Cancel 0, Response 0,

Prack 0, Comet 0, Reliable1xx 0, NOTIFY 0

Register 4

SDP application statistics:

Parses: 0, Builds 0

Invalid token order: 0, Invalid param: 0

Not SDP desc: 0, No resource: 0

Last time SIP Statistics were cleared: <never>

The following sample output shows the RedirectResponseMappedToClientError status message. An incremented number indicates that 3xx responses are to be treated as 4xx responses. When call redirection is enabled (default), the RedirectResponseMappedToClientError status message is not incremented.

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,

OkPrack 0/0, OkPreconditionMet 0/0,

OKSubscribe 0/0, OkNotify 0/0,

202Accepted 0/0

Redirection (Inbound only):

MultipleChoice 0, MovedPermanently 0,

MovedTemporarily 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,

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, RequestCancel 0/0

NotAcceptableMedia 0/0, BadEvent 0/0

Server Error:

InternalError 0/0, NotImplemented 0/0,

BadGateway 0/0, ServiceUnavail 0/0,

GatewayTimeout 0/0, BadSipVer 0/0,

PreCondFailure 0/0

Global Failure:

BusyEverywhere 0/0, Decline 0/0,

NotExistAnywhere 0/0, NotAcceptable 0/0

Miscellaneous counters:

RedirectResponseMappedToClientError 1,

SIP Total Traffic Statistics (Inbound/Outbound)

Invite 0/0, Ack 0/0, Bye 0/0,

Cancel 0/0, Options 0/0,

Prack 0/0, Comet 0/0,

Subscribe 0/0, Notify 0/0,

Refer 0/0

Retry Statistics

Invite 0, Bye 0, Cancel 0, Response 0,

Prack 0, Comet 0, Reliable1xx 0, Notify 0

SDP application statistics:

Parses: 0, Builds 0

Invalid token order: 0, Invalid param: 0

Not SDP desc: 0, No resource: 0

Step 4 show sip-ua status

Use this command to display status for the SIP user agent (UA), including whether call redirection is enabled or disabled.

Router# show sip-ua status

SIP User Agent Status

SIP User Agent for UDP : ENABLED

SIP User Agent for TCP : ENABLED

SIP User Agent bind status(signaling): DISABLED

SIP User Agent bind status(media): DISABLED

SIP max-forwards : 6

SIP DNS SRV version: 1 (rfc 2052)

Redirection (3xx) message handling: ENABLED

Step 5 show sip-ua timers

Use this command to display the current settings for the SIP user-agent (UA) timers.

The following sample output shows the waiting time before a register request is sent—that is, the value that is set with the timers register command:

Router# show sip-ua timers

SIP UA Timer Values (millisecs)

trying 500, expires 180000, connect 500, disconnect 500

comet 500, prack 500, rel1xx 500, notify 500

refer 500, register 500

General Troubleshooting Tips

Note For more information on troubleshooting, see the following references:

•Use the debug asnl events command to verify that the SIP subscription server is up. The output displays a pending message if, for example, the client is unsuccessful in communicating with the server.

•Use the debug call fallback family of commands to display details of VoIP call fallback.

•Use the debug cch323 family of commands to provide debugging output for various components within an H.323 subsystem.

•Use the debug ccsip family of commands for general SIP debugging, including viewing direction-attribute settings and port and network address-translation traces. Use any of the following related commands:

•Use the debug rpms-proc preauth command to enable debug tracing on the RPMS process for H.323 calls, SIP calls, or both H.323 and SIP calls.

•Use the debug rtr trace command to trace the execution of an SAA operation.

•Use the debug voip family of commands, including the following:

–debug voip ccapi protoheaders—Displays messages sent between the originating and terminating gateways. If no headers are being received by the terminating gateway, verify that the header-passing command is enabled on the originating gateway.

–debug voip ivr script—Displays any errors that might occur when the Tcl script is run

–debug voip rtp session named-event 101—Displays information important to DTMF-relay debugging, if you are using codec types g726r16 or g726r24. Be sure to append the argument 101 to thecommand to prevent the console screen from flooding with messages and all calls from failing.

•Cisco router access control lists (ACLs)—Define ACLs to allow only explicitly valid sources of calls to the router or gateway, and therefore to prevent unauthorized SIP or H.323 calls from unknown parties to be processed and connected by the router or gateway.

•Close unused SIP and H.323 ports—If either the SIP or H.323 protocol is not used in your deployment, close the associated protocol ports. If a Cisco voice gateway has dial peers configured to route calls outbound to the PSTN using either time division multiplexing (TDM) trunks or IP, close the unused H.323 or SIP ports so that calls from unauthorized endpoints cannot connect calls. If the protocols are used and the ports must remain open, use ACLs to limit access to legitimate sources.

•SIP registration—If SIP registration is available on SIP trunks, turn on this feature because it provides an extra level of authentication and validation that only legitimate sources can connect calls. If it is not available, ensure that the appropriate ACLs are in place.

•SIP Digest Authentication—If the SIP Digest Authentication feature is available for either registrations or invites, turn this feature on because it provides an extra level of authentication and validation that only legitimate sources can connect calls.

•Explicit incoming and outgoing dial peers—Use explicit dial peers to control the types and parameters of calls allowed by the router, especially in IP-to-IP connections on Cisco Unified CME, SRST, and Cisco UBE. Incoming dial peers offer additional control on the sources of calls, and outgoing dial peers on the destinations. Incoming dial peers are always used for calls. If a dial peer is not explicitly defined, the implicit dial peer 0 is used to allow all calls.

•Explicit destination patterns—Use dial peers with more granularity than .T for destination patterns to block disallowed off-net call destinations. Use class of restriction (COR) on dial peers with specific destination patterns to allow even more granular control of calls to different destinations on the PSTN.

•Translation rules—Use translation rules to manipulate dialed digits before calls connect to the PSTN to provide better control over who may dial PSTN destinations. Legitimate users dial an access code and an augmented number for PSTN for certain PSTN (for example, international) locations.

•Tcl and VoiceXML scripts—Attach a Tcl/VoiceXML script to dial peers to do database lookups or additional off-router authorization checks to allow or deny call flows based on origination or destination numbers. Tcl/VoiceXML scripts can also be used to add a prefix to inbound DID calls. If the prefix plus DID matches internal extensions, then the call is completed. Otherwise, a prompt can be played to the caller that an invalid number has been dialed.

•Host name validation—Use the "permit hostname" feature to validate initial SIP Invites that contain a fully qualified domain name (FQDN) host name in the Request Uniform Resource Identifier (Request URI) against a configured list of legitimate source hostnames.

•Dynamic Domain Name Service (DNS)—If you are using DNS as the "session target" on dial peers, the actual IP address destination of call connections can vary from one call to the next. Use voice source groups and ACLs to restrict the valid address ranges expected in DNS responses (which are used subsequently for call setup destinations).

All other trademarks mentioned in this document or website are the property of their respective owners. The use of the word partner does not imply a partnership relationship between Cisco and any other company. (0809R)

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