Table Of Contents
Prerequisites for SIP Gateway Enhancements
Restrictions for SIP Gateway Enhancements
Information About SIP Gateway Enhancements
Call Redirect Enhancements to Support IP-to-IP Calls through the IOS Voice Gateway
Sending 300 Multiple Choice Messages
NOTIFY-Based Out-of-Band DTMF Relay
How to Configure SIP Gateway Enhancements
Configuring Call Redirect Enhancements to Support Calls
Configuring Call Redirect Enhancements to Support Calls Globally
Configuring Call Redirect Enhancements to Support Calls on a Specific VoIP Dial Peer
Configuring Sending 300 Multiple Choice Support
Configuring NOTIFY-Based Out-of-Band DTMF Relay
Configuring SIP Register Support
Configuration Examples for SIP Gateway Enhancements
SIP Gateway Enhancements Example
redirect ip2ip (voice service)
SIP Gateway Enhancements
The SIP Gateway Enhancements feature describes new features for Session Initiation Protocol (SIP) networks.
Feature Specifications for the SIP Gateway Enhancements
Finding Support Information for Platforms and Cisco IOS Software Images
Use Cisco Feature Navigator to find information about platform support and Cisco IOS software image support. Access Cisco Feature Navigator at http://www.cisco.com/go/fn. You must have an account on Cisco.com. If you do not have an account or have forgotten your username or password, click Cancel at the login dialog box and follow the instructions that appear.
Contents
•Prerequisites for SIP Gateway Enhancements
•Restrictions for SIP Gateway Enhancements
•Information About SIP Gateway Enhancements
•How to Configure SIP Gateway Enhancements
•Configuration Examples for SIP Gateway Enhancements
Prerequisites for SIP Gateway Enhancements
The following are general prerequisites for SIP deployment:
•Ensure that the gateway has voice functionality that is configurable for SIP.
•Establish a working IP network.
For more information about configuring IP, refer to the following document:
Cisco IOS IP Configuration Guide, Release 12.2
•Configure VoIP.
For more information about configuring VoIP, refer to the following document:
Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2
•The SIP gateway must support 300 or 302 Redirect messages.
Restrictions for SIP Gateway Enhancements
•To support Skinny Client Control Protocol (SCCP) IP phones, originating and terminating SIP gateways can use NOTIFY-based out-of-band dual-tone multifrequency (DTMF) relay. NOTIFY-based out-of-band DTMF relay is a Cisco proprietary function.
•SIP gateways do not support authentication, and therefore cannot respond to authentication requests for Register messages.
Information About SIP Gateway Enhancements
To configure the SIP Gateway Enhancements feature, you must understand the following concepts:
•Call Redirect Enhancements to Support IP-to-IP Calls through the IOS Voice Gateway
•How to Configure SIP Gateway Enhancements
•NOTIFY-Based Out-of-Band DTMF Relay
Call Redirect Enhancements to Support IP-to-IP Calls through the IOS Voice Gateway
The Cisco IOS Voice Gateway has been enhanced to 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 new commands allow you to enable the redirect functionality, globally or on a specific inbound dial peer. For command-level information, see the appropriate command page.
•redirect ip2ip (voice service)
Sending 300 Multiple Choice Messages
Prior to Cisco IOS Release 12.2(15)ZJ, 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. With release 12.2(15)ZJ, 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.
A new command has been added to give users the flexibility to choose the order in which the routes can appear in the Contact header.
NOTIFY-Based Out-of-Band DTMF Relay
SCCP IP phones do not support in-band DTMF digits; they are capable of sending only out-of-band DTMF digits. To support SCCP devices, originating and terminating SIP gateways can use Cisco proprietary NOTIFY-based out-of-band DTMF relay. In addition, NOTIFY-based out-of-band DTMF relay can also be used by analog phones attached to analog voice ports (FXS) on the router.
NOTIFY-based out-of-band DTMF relay sends message bidirectionally between the originating and terminating gateways for a DTMF event during a call. If multiple DTMF relay mechanisms are enabled on a SIP dial peer and are negotiated successfully, NOTIFY-based out-of-band DTMF relay takes precedence.
The originating gateway sends an Invite message with SIP Call-Info header to indicate the use of NOTIFY-based out-of-band DTMF relay. The terminating gateway acknowledges the message with an 18x/200 Response message, also using the Call-Info header. The Call-Info header for NOTIFY-based out-of-band relay appears as follows:
Call-Info: <sip: address>; method="NOTIFY;Event=telephone-event;Duration=msec"
Note Duration is the interval between NOTIFY messages sent for a single digit and is set through the notify telephone-event command.
After the NOTIFY-based out-of-band DTMF relay mechanism is negotiated by the SIP Invite and 18x/200 Response messages, whenever a DTMF event occurs the gateway sends a SIP NOTIFY message for that event. In response, the gateway expects to receive a 200 OK message.
The NOTIFY-based out-of-band DTMF relay mechanism is similar to the DTMF message format described in RFC 2833. It consists of 4 bytes in a binary encoded format.
Figure 1 Message Format of NOTIFY-based out-of-band DTMF relay
Sending NOTIFY messages
As soon as the DTMF event is recognized, the gateway sends out an initial NOTIFY message for this event with the duration negotiated in the Invite's Call-Info header. For the initial NOTIFY message the end bit is set to zero. Afterward, one of the following can happen:
•If the entire duration of the DTMF event is less than the negotiated duration, the originating gateway sends an end NOTIFY message for this event with the duration field containing the exact duration of the event and the end bit set to one.
•If the duration of the DTMF event is greater than the negotiated duration, then the originating gateway sends another NOTIFY message for this event after the initial timer runs out. The updated NOTIFY message has a duration of twice the negotiated duration. The end bit is set to zero since the event is not yet over. If the event lasts beyond the duration specified in the first updated NOTIFY message, then another updated NOTIFY message is sent with three times the negotiated duration.
•This continues until the DTMF event ends, and an end NOTIFY message is sent. If the event lasts for exactly the negotiated duration, then either of the above two cases can happen, based on whether the end of DTMF event occurred earlier or the timer ran out earlier, respectively.
For example, if the negotiated duration is 600ms, then as soon as a DTMF event occurs, the initial NOTIFY message is sent with duration as 600ms. Then a timer is started for this duration.
•If the DTMF event last only for 300ms, the timer is stopped and an end NOTIFY message is sent with the duration as 300ms.
•If the DTMF event lasts for more than 600ms (1000ms), when the timer expires an updated NOTIFY message is sent with the duration as 1200ms and the timer is restarted. Finally when the DTMF event ends, an end NOTIFY message is sent with the duration set to 1000ms.
Every DTMF event corresponds to at least two NOTIFYs: an initial NOTIFY message and an end NOTIFY. There might be some update NOTIFYs also involved, if the total duration of the event is greater than the negotiated max-duration interval. Since DTMF events generally last for less than 1000ms, setting the duration using notify telephone-event command to more than 1000ms reduces the total number of NOTIFY messages sent. The default value of notify telephone-event command is 2000ms.
Receiving NOTIFY messages
Once a NOTIFY message is received by the terminating gateway, the DTMF tone plays and a timer is set for the value in the duration field. Afterward, one of the following can happen:
•If an end NOTIFY message for a DTMF event is received, the tone is stopped.
•If an update is received, the timer is updated according to the duration field.
•If an update or end NOTIFY message is not received before the timer expires, the tone is stopped and all subsequent NOTIFY messages for the same DTMF-event or DTMF digit are ignored until an end NOTIFY message is received.
•If a NOTIFY message for a different DTMF event is received before an end NOTIFY message for the current DTMF event is received (which is an unlikely case), the current tone is stopped and the new tone is played. This is an unlikely case because for every DTMF event there needs to be a end NOTIFY message, and unless this is successfully sent and a 200 OK received, the gateway cannot send other NOTIFY messages.
Note In-band tones are not passed while NOTIFY-based out-of-band DTMF relay is used as the DTMF relay method.
Two commands allow you to enable or disable NOTIFY-based out-of-band DTMF-relay on a dial peer. The functionality is advertised to other end using Invite messages if it is enabled by the commands, and must be configured on both the originating and terminating SIP gateways. A third command allows you to verify DTMF relay status. For command-level information, see the appropriate command page.
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. SIP gateways now 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.
Note There are no commands that allow registration between the H.323 and SIP protocols.
Several commands have been added to give the user control over enabling, disabling, and monitoring SIP Register messages. For command-level information, see the appropriate command page.
How to Configure SIP Gateway Enhancements
This section contains the following procedures:
•Configuring Call Redirect Enhancements to Support Calls (required)
•Configuring Sending 300 Multiple Choice Support (required)
•Configuring NOTIFY-Based Out-of-Band DTMF Relay (required)
•Configuring SIP Register Support (required)
Configuring Call Redirect Enhancements to Support Calls
This feature can be enabled globally or on a dial-peer basis.
•Configuring Call Redirect Enhancements to Support Calls Globally
•Configuring Call Redirect Enhancements to Support Calls on a Specific VoIP Dial Peer
Configuring Call Redirect Enhancements to Support Calls Globally
To enable global IP-to-IP call redirection for all VoIP dial peers, use voice service configuration mode. The default application on SIP SRST supports IP-to-IP redirection.
SUMMARY STEPS
1. enable
2. configure terminal
3. voice service voip
4. redirect ip2ip
5. exit
DETAILED STEPS
Configuring Call Redirect Enhancements to Support Calls on a Specific VoIP Dial Peer
To specify IP-to-IP call redirection for a specific VoIP dial peer, configure on an inbound dial peer in dial peer configuration mode. The default application on SIP SRST supports IP-to-IP redirection.
Note 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 tag voip
4. application application-name
5. redirect ip2ip
6. exit
DETAILED STEPS
Configuring Sending 300 Multiple Choice Support
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. configure terminal
3. voice service voip
4. sip
5. redirect contact order [best-match | longest-match]
6. exit
DETAILED STEPS
Configuring NOTIFY-Based Out-of-Band DTMF Relay
Cisco proprietary NOTIFY-based out-of-band DTMF relay adds support for devices that do not support in-band DTMF. This configuration must be done on both originating and terminating gateways. With this configuration, DTMF tones are forwarded by using SIP NOTIFY messages in SIP Invites or 18x or 200 Response messages.
Restrictions
This configuration can only be done on a SIP VoIP dial peer.
SUMMARY STEPS
1. enable
2. configure terminal
3. dial-peer voice tag voip
4. dtmf-relay sip-notify
5. exit
6. sip-ua
7. notify telephone-event max-duration time
DETAILED STEPS
Examples
The following output from the show running-config command shows that the dtmf-relay sip-notify command is configured in dial peer 123:
...dial-peer voice 123 voipdestination-pattern [12]...monitor probe icmp-pingsession protocol sipv2session target ipv4:10.8.17.42dtmf-relay sip-notify...The following output from the show sip-ua status command shows that the time interval between consecutive NOTIFY messages for a telephone event is the default of 2000 ms:
Router# show sip-ua statusSIP User Agent StatusSIP User Agent for UDP : ENABLEDSIP User Agent for TCP : ENABLEDSIP User Agent bind status(signaling): DISABLEDSIP User Agent bind status(media): DISABLEDSIP early-media for 180 responses with SDP: ENABLEDSIP max-forwards : 6SIP DNS SRV version: 2 (rfc 2782)NAT Settings for the SIP-UARole in SDP: NONECheck media source packets: DISABLEDMaximum duration for a telephone-event in NOTIFYs: 2000 msSIP support for ISDN SUSPEND/RESUME: ENABLEDRedirection (3xx) message handling: ENABLEDSDP application configuration:Version line (v=) requiredOwner line (o=) requiredTimespec line (t=) requiredMedia supported: audio imageNetwork types supported: INAddress types supported: IP4Transport types supported: RTP/AVP udptlConfiguring SIP Register Support
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.
SUMMARY STEPS
1. enable
2. configure terminal
3. sip-ua
4. registrar {{dns: address | ipv4: destination-address } expires seconds [tcp] [secondary]}
5. retry register number
6. timers register time
7. end
DETAILED STEPS
Examples
The following is sample output from the show sip-ua timers command showing 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 timersSIP UA Timer Values (millisecs)trying 500, expires 180000, connect 500, disconnect 500comet 500, prack 500, rel1xx 500, notify 500
refer 500, register 500The following is sample output from the show sip-ua register status command showing the status of local E.164 registrations:
Router# show sip-ua register statusLine peer expires(sec) registered4001 20001 596 no4002 20002 596 no5100 1 596 no9998 2 596 noThe following is sample output from the show sip-ua statistics command showing four registers were sent:
Router# show sip-ua statisticsSIP Response Statistics (Inbound/Outbound)Informational:Trying 0/0, Ringing 0/0,Forwarded 0/0, Queued 0/0,SessionProgress 0/0Success: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/0OkRegister 12/49Redirection (Inbound only except for MovedTemp(Inbound/Outbound)) :MultipleChoice 0, MovedPermanently 0,MovedTemporarily 0/0, UseProxy 0,AlternateService 0Client 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/0Server Error:InternalError 0/0, NotImplemented 0/0,BadGateway 0/0, ServiceUnavail 0/0,GatewayTimeout 0/0, BadSipVer 0/0,PreCondFailure 0/0Global Failure:BusyEverywhere 0/0, Decline 0/0,NotExistAnywhere 0/0, NotAcceptable 0/0Miscellaneous counters:RedirectRspMappedToClientErr 0SIP 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/0Register 49/16Retry StatisticsInvite 0, Bye 0, Cancel 0, Response 0,Prack 0, Comet 0, Reliable1xx 0, NOTIFY 0Register 4SDP application statistics:Parses: 0, Builds 0Invalid token order: 0, Invalid param: 0Not SDP desc: 0, No resource: 0Last time SIP Statistics were cleared: <never>Configuration Examples for SIP Gateway Enhancements
This section provides the following configuration example.
•SIP Gateway Enhancements Example
Note IP addresses and host names in examples are fictitious.
SIP Gateway Enhancements Example
This section provides a configuration example to match the identified configuration tasks in the previous sections.
Current configuration : 3394 bytes!version 12.2service timestamps debug uptimeservice timestamps log uptimeno service password-encryptionservice internal!memory-size iomem 15ip subnet-zero!!no ip domain lookup!ip dhcp pool vespanetwork 192.168.0.0 255.255.255.0option 150 ip 192.168.0.1default-router 192.168.0.1!!voice call carrier capacity active!voice class codec 1codec preference 2 g711ulaw!!no voice hpi capture bufferno voice hpi capture destination!!fax interface-type fax-mailmta receive maximum-recipients 0!!interface Ethernet0/0ip address 10.8.17.22 255.255.0.0half-duplex!interface FastEthernet0/0ip address 192.168.0.1 255.255.255.0speed autono cdp enableh323-gateway voip interfaceh323-gateway voip id vespa2 ipaddr 10.8.15.4 1718!router ripnetwork 10.0.0.0network 192.168.0.0!ip default-gateway 10.8.0.1ip classlessip route 0.0.0.0 0.0.0.0 10.8.0.1no ip http serverip pim bidir-enable!!tftp-server flash:SEPDEFAULT.cnftftp-server flash:P005B302.bincall fallback active!!call application global default.newcall rsvp-sync!voice-port 1/0!voice-port 1/1!mgcp profile default!!dial-peer voice 1 potsdestination-pattern 5100port 1/0!dial-peer voice 2 potsdestination-pattern 9998port 1/1!dial-peer voice 123 voipdestination-pattern [12]...session protocol sipv2session target ipv4:10.8.17.42dtmf-relay sip-notify!gateway!sip-uaretry invite 3retry register 3timers register 150registrar dns:myhost3.cisco.com expires 3600registrar ipv4:10.8.17.40 expires 3600 secondary!!telephony-servicemax-dn 10max-conferences 4!ephone-dn 1number 4001!!ephone-dn 2number 4002!!line con 0exec-timeout 0 0line aux 0line vty 0 4loginline vty 5 15login!no scheduler allocateendAdditional References
For additional information regarding the SIP protocol or the SIP Gateway Enhancements feature, refer to the following references.
Related Documents
Related Topic Document TitleCisco SIP IP phones
•Cisco IP Phone Documentation for Session Initiation Protocol (SIP)
TCL scripts and programming
•TCL IVR API Version 2.0 Programming Guide
•"Configuring TCL IVR Applications" chapter in Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2
Voice and telephony command reference
Cisco IOS Voice Command Reference, Release 12.2 T
Cisco SIP functionality
Cisco IOS Voice, Video, and Fax Configuration Guide, Release 12.2
Session Initiation Protocol (SIP) for VoIP, Release 12.2(8)T
Session Initiation Protocol Gateway Call Flows, Release 12.2(4)T
Standards
Standards TitleNo new or modified standards are supported by this feature, and support for existing standards has not been modified by this feature.
—
MIBs
MIBs MIBs Link•CISCO-SIP-UA-MIB
To locate and download MIBs for selected platforms, Cisco IOS releases, and feature sets, use Cisco MIB Locator found at the following URL:
RFCs
Technical Assistance
Command Reference
This section documents new and modified commands. All other commands used with this feature are documented in the Cisco IOS Release12.3 command reference publications.
New Commands
•redirect ip2ip (voice service)
Modified Commands
dtmf-relay (Voice over IP)
To specify how an H.323 or Session Initiation Protocol (SIP) gateway relays dual tone multifrequency (DTMF) tones between telephony interfaces and an IP network, use the dtmf-relay command in dial-peer configuration mode. To remove all signaling options and send the DTMF tones as part of the audio stream, use the no form of this command.
dtmf-relay [cisco-rtp] [h245-alphanumeric] [h245-signal] [rtp-nte] [sip-notify]
no dtmf-relay [cisco-rtp] [h245-alphanumeric] [h245-signal] [rtp-nte] [sip-notify]
Syntax Description
Defaults
DTMF tones are disabled and sent inband. That is, they are left in the audio stream.
Command Modes
Dial-peer configuration
Command History
Usage Guidelines
DTMF is the tone generated when you press a button on a touch tone phone. This tone is compressed at one end of a call; when the tone is decompressed at the other end, it can become distorted, depending on the codec used. The DTMF relay feature transports DTMF tones generated after call establishment out-of-band using either a standard H.323 out-of-band method or a proprietary RTP-based mechanism. For SIP calls, the most appropriate methods to transport DTMF tones are RTP-NTE or SIP-NOTIFY.
The SIP-NOTIFY method sends NOTIFY messages bidirectionally between the originating and terminating gateways for a DTMF event during a call. If multiple DTMF relay mechanisms are enabled on a SIP dial peer and are negotiated successfully, the SIP-NOTIFY method takes precedence.
SIP NOTIFY messages are advertised in an Invite message to the remote end only if the dtmf-relay command is set.
For SIP, the gateway chooses the format according to the following priority:
1. sip-notify
2. rtp-nte
3. None—DTMF sent in-band
The gateway sends DTMF tones only in the format that you specify if the remote device supports it. If the H.323 remote device supports multiple formats, the gateway chooses the format according to the following priority:
1. cisco-rtp (highest priority)
2. h245-signal
3. h245-alphanumeric
4. rtp-nte
5. None—DTMF sent in-band
The principal advantage of the dtmf-relay command is that it sends DTMF tones with greater fidelity than is possible in-band for most low-bandwidth codecs, such as G.729 and G.723. Without the use of DTMF relay, calls established with low-bandwidth codecs may have trouble accessing automated DTMF-based systems, such as voice mail, menu-based Automatic Call Distributor (ACD) systems, and automated banking systems.
Note•The cisco-rtp keyword is a proprietary Cisco implementation and operates only between two Cisco AS5800 access concentrators that are running Cisco IOS Release 12.0(2)XH or between Cisco AS5800 access concentrators or Cisco 2600 series or Cisco 3600 series routers that are running Cisco IOS Release 12.0(2)XH or later releases. Otherwise, the DTMF relay feature does not function, and the gateway sends DTMF tones in-band.
•The cisco-rtp keyword of the dtmf-relay command is supported on Cisco 7200 series routers.
•The h245-alphanumeric and h245-signal DTMF settings on a Cisco MC3810 multiservice access concentrator require a high-performance compression module (HCM) and are not supported on a Cisco MC3810 with a non-HCM voice compression module (VCM).
•The sip-notify keyword is available only if the VoIP dial peer is configured for SIP.
Examples
The following example configures DTMF relay with the cisco-rtp keyword when sending DTMF tones to dial peer 103:
dial-peer voice 103 voipdtmf-relay cisco-rtpThe following example configures DTMF relay with the cisco-rtp or h245-signal keywords when DTMF tones are sent to dial peer 103:
dial-peer voice 103 voipdtmf-relay cisco-rtp h245-signalThe following example configures the gateway to send DTMF in-band (the default) when DTMF tones are sent to dial peer 103:dial-peer voice 103 voipno dtmf-relayThe following example configures DTMF relay with the rtp-nte keyword when DTMF tones are sent to dial peer 103:
dial-peer voice 103 voipdtmf-relay rtp-nteThe following example configures the gateway to send DTMF tones using SIP NOTIFY messages to dial peer 103:
dial-peer voice 103 voipsession protocol sipv2dtmf-relay sip-notifyRelated Commands
Command Descriptionnotify telephone-event
Configures the maximum interval between two consecutive NOTIFY messages for a particular telephone-event.
notify telephone-event
To configure the maximum interval between two consecutive NOTIFY messages for a particular telephone-event, use the notify telephone-event command in SIP user-agent configuration mode. To reset the interval to the default, use the no form of this command.
notify telephone-event max-duration time
no notify telephone-event
Syntax Description
max-duration time
Time interval between consecutive NOTIFY messages for a single DTMF event, in milliseconds. Range is from 500 to 3000. Default is 2000.
Defaults
2000 milliseconds
Command Modes
SIP user-agent configuration
Command History
Usage Guidelines
The notify telephone-event command works with the dtmf-relay sip-notify command. The
dtmf-relay sip-notify command forwards out-of-band DTMF tones by using SIP NOTIFY messages. The notify telephone-event command sets the maximum time interval between consecutive NOTIFY messages for a single DTMF event. The maximum time is negotiated between two SIP endpoints and the lowest duration value is the one selected. This duration is negotiated during call establishment as part of negotiating the SIP-NOTIFY DTMF relay.The originating gateway sends an indication of DTMF relay in an Invite message using the SIP Call-Info header. The terminating gateway acknowledges the message with an 18x/200 Response message, also using the Call-Info header. The set duration appears in the Call-Info header in the following way:
Call-Info: <sip: address>; method="Notify;Event=telephone-event;Duration=msec"For example, if the maximum duration of gateway A is set to 1000 ms, and gateway B is set to 700 ms, the resulting negotiated duration would be 700 ms. Both A and B would use the value 700 in all of their NOTIFY messages for DTMF events.
Examples
The following example sets the maximum duration for a DTMF event to 500 ms.
Router(config)# sip-ua
Router(config-sip-ua)# notify telephone-event max-duration 500
Related Commands
redirect contact order
To set the order of contacts in the "300 Multiple Choice" message, use the redirect contact order command in SIP configuration mode. To reset to the default, use the no form of this command.
redirect contact order [best-match | longest-match]
no redirect contact order
Syntax Description
Defaults
longest-match
Command Modes
SIP configuration
Command History
Usage Guidelines
This command applies when a "300 Multiple Choice" message is sent by a SIP gateway indicating that the call has been redirected and there are multiple routes to the destination.
Enter SIP configuration mode after entering voice service VoIP configuration mode as shown in the following example.
Examples
The following example shows how to set up the redirect contact order command to use the current system configuration to set the order of contact:
Router(config)# voice service voipRouter(config-voi-srv)# sipRouter(conf-serv-sip)# redirect contact order best-matchRelated Commands
redirect ip2ip (dial-peer)
To redirect SIP phone calls to SIP phone calls on a specific VoIP dial peer using the Cisco IOS Voice Gateway, use the redirect ip2ip command in dial-peer configuration mode. To disable redirection, use the no form of this command.
redirect ip2ip
no redirect ip2ip
Syntax Description
This command has no arguments or keywords.
Defaults
Disabled
Command Modes
Dial-peer configuration
Command History
Usage Guidelines
The redirect ip2ip (dial-peer) command must be configured on the inbound dial peer of the gateway. This command enables, per dial peer, IP-to-IP call redirection for the gateway.
To enable global IP-to-IP call redirection for all VoIP dial peers, use voice service configuration mode. To specify IP-to-IP call redirection for a specific VoIP dial peer, configure the dial peer in dial-peer configuration mode.
Note When IP-to-IP redirection is configured in dial-peer configuration mode, the configuration for the specific dial peer is activated only if the dial peer is an inbound dial peer. To enable globally, use redirect ip2ip (voice service) command.
Examples
The following example specifies that on VoIP dial peer 99, IP-to-IP redirection is set:
dial-peer voice 99 voipredirect ip2ipRelated Commands
Command Descriptionredirect ip2ip (voice service)
Redirects SIP phone calls to SIP phone calls globally on a gateway using the Cisco IOS Voice Gateway.
redirect ip2ip (voice service)
To redirect SIP phone calls to SIP phone calls globally on a gateway using the Cisco IOS Voice Gateway, use the redirect ip2ip command in voice service configuration mode. To disable, use the no form of this command.
redirect ip2ip
no redirect ip2ip
Syntax Description
This command has no arguments or keywords.
Defaults
Disabled
Command Modes
voice service configuration
Command History
Usage Guidelines
Use this command to enable IP-to-IP call redirection globally on a gateway. Use the redirect ip2ip (dial-peer) command to configure on a specific inbound dial peer.
Examples
The following example specifies that all VoIP dial peers use IP-to-IP redirection:
voice service voipredirect ip2ipRelated Commands
Command Descriptionredirect ip2ip (dial-peer)
Redirects SIP phone calls to SIP phone calls on a specific VoIP dial peer using the Cisco IOS Voice Gateway.
registrar
To enable Session Initiation Protocol (SIP) gateways to register E.164 numbers on behalf of analog telephone voice ports (FXS), IP phone virtual voice ports (EFXS), and SCCP phones with an external SIP proxy or SIP registrar, use the registrar command in SIP user-agent configuration mode. To disable registration of E.164 numbers, use the no form of this command.
registrar {{dns: address | ipv4: destination-address} expires seconds [tcp] [secondary]}
no registrar [secondary]
Syntax Description
Defaults
3600 seconds
Command Modes
SIP user-agent configuration
Command History
Usage Guidelines
By default, SIP gateways do not generate SIP Register messages. This command enables the gateway to register E.164 telephone numbers with primary and secondary external SIP registrars.
Examples
The following is example output for the show running-config command.
sip-uaretry invite 3retry register 3timers register 150registrar ipv4:10.8.17.40 expires 3600 secondaryRelated Commands
retry register
To set the total number of Session Initiation Protocol (SIP) Register messages that the gateway should send, use the retry register command in SIP user-agent configuration mode. To reset this number to the default, use the no form of this command.
retry register number
no retry register
Syntax Description
Defaults
10 retries
Command Modes
SIP user-agent configuration
Command History
Usage Guidelines
Use the default number of 10 when possible. Lower values such as 1 can lead to an increased chance of the message not being received by the other user agent.
Examples
The following example specifies that the gateway sends nine Register messages.
sip-uaretry invite 9retry register 9timers register 150Related Commands registrar ipv4:10.8.17.40 expires 3600 secondary
show sip-ua register status
To display the status of E.164 numbers that a Session Initiation Protocol (SIP) gateway has registered with an external primary SIP registrar, use the show sip-ua register status command in privileged EXEC mode.
show sip-ua register status [secondary]
Syntax Description
secondary
(Optional) Displays the status of E.164 numbers that a SIP gateway registered with an external secondary SIP registrar.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
SIP gateways can register E.164 numbers on behalf of analog telephone voice ports (FXS), IP phone virtual voice ports (EFXS), and SCCP phones with an external SIP proxy or SIP registrar.
Examples
The following is sample output from this command:
Router# show sip-ua register statusLine peer expires(sec) registered4001 20001 596 no4002 20002 596 no5100 1 596 no9998 2 596 noTable 2 describes significant fields shown in this output.
Related Commands
show sip-ua statistics
To display response, traffic, and retry Session Initiation Protocol (SIP) statistics, use the show sip-ua statistics command in privileged EXEC mode.
show sip-ua statistics
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use the show sip-ua statistics command to verify SIP configurations.
Examples
The following is sample output from this command:
Router# show sip-ua statisticsSIP Response Statistics (Inbound/Outbound)Informational:Trying 0/0, Ringing 0/0,Forwarded 0/0, Queued 0/0,SessionProgress 0/0Success: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/0OkRegister 12/49Redirection (Inbound only except for MovedTemp(Inbound/Outbound)) :MultipleChoice 0, MovedPermanently 0,MovedTemporarily 0/0, UseProxy 0,AlternateService 0Client 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/0Server Error:InternalError 0/0, NotImplemented 0/0,BadGateway 0/0, ServiceUnavail 0/0,GatewayTimeout 0/0, BadSipVer 0/0,PreCondFailure 0/0Global Failure:BusyEverywhere 0/0, Decline 0/0,NotExistAnywhere 0/0, NotAcceptable 0/0Miscellaneous counters:RedirectRspMappedToClientErr 0SIP 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/0Register 49/16Retry StatisticsInvite 0, Bye 0, Cancel 0, Response 0,Prack 0, Comet 0, Reliable1xx 0, NOTIFY 0Register 4SDP application statistics:Parses: 0, Builds 0Invalid token order: 0, Invalid param: 0Not SDP desc: 0, No resource: 0Last time SIP Statistics were cleared: <never>Command output, listed in Table 3, includes a reason phrase and a count describing the SIP messages received and sent. When x/x is included in the reason phrase field, the first number is an inbound count, and the second number is an outbound count. The description field headings are based on the SIP response code xxx, which the SIP protocol uses in determining behavior. SIP response codes are classified into one of the following six categories:
•1xx: Informational. Indicates call progress.
•2xx: Success. Indicates successful receipt or completion of a request.
•3xx: Redirection. Indicates that a redirect server has returned possible locations.
•4xx: Client error. Indicates that a request cannot be fulfilled as it was submitted.
•5xx: Server error. Indicates that a request has failed because of an error by the server. The request may be retried at another server.
•6xx: Global failure. Indicates that a request has failed and should not be tried again at any server.
Table 3 describes significant fields shown in this output, in alphabetical order.
Related Commands
show sip-ua status
To display status for the Session Initiation Protocol (SIP) user agent (UA), use the show sip-ua status command in privileged EXEC mode.
show sip-ua status
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use this command to verify SIP configurations.
Examples
The following is sample output from this command:
Router# show sip-ua statusSIP User Agent StatusSIP User Agent for UDP : ENABLEDSIP User Agent for TCP : ENABLEDSIP User Agent bind status(signaling): DISABLEDSIP User Agent bind status(media): DISABLEDSIP early-media for 180 responses with SDP: ENABLEDSIP max-forwards : 6SIP DNS SRV version: 2 (rfc 2782)NAT Settings for the SIP-UARole in SDP: NONECheck media source packets: DISABLEDMaximum duration for a telephone-event in NOTIFYs: 2000 msSIP support for ISDN SUSPEND/RESUME: ENABLEDRedirection (3xx) message handling: ENABLEDSDP application configuration:Version line (v=) requiredOwner line (o=) requiredSession name line (s=) requiredTimespec line (t=) requiredMedia supported: audio imageNetwork types supported: INAddress types supported: IP4Transport types supported: RTP/AVP udptlTable 4 describes significant fields shown in this output.
Related Commands
show sip-ua timers
To display the current settings for the Session Initiation Protocol (SIP) user-agent (UA) timers, use the show sip-ua timers command in privileged EXEC mode.
show sip-ua timers
Syntax Description
This command has no arguments or keywords.
Command Modes
Privileged EXEC
Command History
Usage Guidelines
Use this command to verify SIP configurations.
Examples
The following is sample output from this command:
Router# show sip-ua timersSIP UA Timer Values (millisecs)trying 500, expires 180000, connect 500, disconnect 500comet 500, prack 500, rel1xx 500, notify 500
refer 500, register 500Table 5 describes significant fields shown in this output.
Related Commands
timers register
To set how long the Session Initiation Protocol (SIP) user agent (UA) waits before sending register requests, use the timers register command in SIP user-agent configuration mode. To reset to the default, use the no form of this command.
timers register time
no timers register
Syntax Description
Defaults
500 milliseconds
Command Modes
SIP user-agent configuration
Command History
Examples
The following example sends register requests every 500 milliseconds:
sip-uaretry invite 9retry register 9timers register 500Related Commands
Glossary
call—In SIP, a call consists of all participants in a conference who are invited by a common source. A SIP call is identified by a globally unique call identifier. A point-to-point IP telephony conversation maps into a single SIP call.
DNS—Domain Name System. Used to translate H.323 IDs, URLs, or e-mail IDs to IP addresses. DNS is also used to assist in locating remote gatekeepers and to reverse-map raw IP addresses to host names of administrative domains.
DNS SRV—Domain Name System Server. Used to locate servers for a given service.
DTMF—dual-tone multifrequency. Tones that 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.
DTMF relay— DTMF relay provides reliable digit relay between VoIP gateways when a low-bandwidth codec is used. DTMF relay provides a standardized means of transporting DTMF tones in Real-Time Transport Protocol (RTP) packets and is identified by dynamic payload types in the SDP.
INVITE—A SIP message that initiates a SIP session. It indicates that a user is invited to participate, provides a session description, indicates the type of media, and provides information regarding the capabilities of the called and calling parties.
NOTIFY—SIP NOTIFY messages report when certain events occur, such as DTMF events.
proxy—A SIP UAC or UAS that forwards requests and responses on behalf of another SIP UAC or UAS.
PSTN—public switched telephone network. PSTN refers to the local telephone company network.
SCCP—Skinny Client Control Protocol. SCCP is the Cisco standard for real-time calls and conferencing over IP. This generalized messaging set allows Cisco IP phones to coexist in an H.323 environment. The savings in memory size, processor power, and complexity makes the protocol desirable.
session—A SIP session includes a set of multimedia senders and receivers and the data streams that flow between the senders and receivers. A SIP multimedia conference is an example of a session. The called party can be invited several times by different calls to the same session.
SIP—Session Initiation Protocol. An application-layer protocol originally developed by the Multiparty Multimedia Session Control (MMUSIC) working group of the Internet Engineering Task Force (IETF). Their goal was to equip platforms to signal the setup of voice and multimedia calls over IP networks. SIP features are compliant with IETF RFC 2543, published in March 1999.
SRST—Survivable Remote Site Telephony.
URI—Uniform Resource Identifier. Takes a form similar to an e-mail address, indicates the user's SIP identity, and is used for redirection of SIP messages.
URL—Uniform Resource Locator. Standard address of any resource on the Internet that is part of the World Wide Web (WWW).
VoIP—Voice over IP. The ability to carry normal telephone-style voice over an IP-based network.
Note Refer to the Internetworking Terms and Acronyms for terms not included in this glossary.
Copyright © 2003 Cisco Systems, Inc. All rights reserved.