Cisco Unified Border Element (SP Edition) Configuration Guide: Unified Model

Implementing Interworking DTMF

---

Cisco Unified Border Element (SP Edition) enables interworking between in-channel real-time transport protocol (RTP) signaling using the audio/telephone-event MIME type (RFC 2833) to and from out-of-band signaling using the SIP INFO or SIP NOTIFY method.

The Dual Tone Multifrequency (DTMF) Method Interworking and ACCEPT Header Handling feature introduces an adjacency setting that modifies the only auto detection behavior for INFO method.

Cisco Unified Border Element (SP Edition) was formerly known as Integrated Session Border Controller, and may be commonly referred to as the session border controller (SBC) in this document.

For a complete description of the commands used in this chapter, refer to the Cisco Unified Border Element (SP Edition) Command Reference: Unified Model at:

http://www.cisco.com/en/US/docs/ios/sbc/command/reference/sbcu_book.html

For information about all Cisco IOS commands, use the Command Lookup Tool at http://tools.cisco.com/Support/CLILookup or a Cisco IOS master commands list.

Feature History for Implementing Interworking DTMF on Cisco Unified Border Element (SP Edition)

Contents

This chapter contains the following sections:

• Restrictions
• Prerequisites—Implementing Interworking DTMF
• Information About Interworking DTMF
• Implementing Interworking DTMF
• DTMF Relay Using SIP NOTIFY Messages
• DTMF Method Interworking and ACCEPT Header Handling

Restrictions

The following are restrictions of the Implementing Interworking DTMF feature:

• When the SBC inspects the accept header in the endpoint’s messages, the absence of the accept header means “application/sdp” is supported.
• When audio transcoding is in operation, the SBC does not support sending and receiving RFC 2833 in-band packets to and from the SBC and interworking RFC 2833 packets with out-of-band SIP INFO or SIP NOTIFY Relay messages on the other call leg.
• The SBC does not support the scenario where a caller only supports sending RFC 2833 in-band packets to a callee that supports both RFC 2833 and out-of-band SIP INFO and SIP NOTIFY Relay. In this case, the DTMF digits received out-of-band on the callee side is not able to be translated into RFC 2833 packets on the caller side.
• The SBC does not support configurable outbound RFC 2833 payload type for SIP to SIP calls when the inbound call side does not support RFC 2833.

Prerequisites—Implementing Interworking DTMF

The following prerequisites are required to implement interworking DTMF:

Before implementing interworking DTMF, Cisco Unified Border Element (SP Edition) must already be configured.

Information About Interworking DTMF

Cisco Unified Border Element (SP Edition) automatically selects the best DTMF Interworking technique based on the combined capabilities of the endpoints in a call. See Figure 13-1 for a sample call flow.

The SBC supports the signaling of DTMF using the following modes:

• Media-stream signalling using RTP payload (RFC2833)
• INFO-based DTMF relay (RFC 2976)
• NOTIFY-based DTMF relay

The SBC can interwork between any of these modes using the most performance efficient methods.

DTMF interworking for RFC 2833 in-band packets when transcoding is not supported.

Inspection of the arriving INVITE helps determine the caller’s support for DTMF interworking.

To determine whether the caller supports the INFO method, the SBC inspects the Allow header for the INFO method if the Allow header is present. However, the INVITE must also contain an Accept header that contains application/dtmf-relay for the SBC to detect support for DTMF in the INFO method.

Support for the unsolicited NOTIFY method can be determined by the presence of a Call-Info header indicating the NOTIFY method.

An INFO or NOTIFY message is expected to carry a single DTMF tone with an optional duration. If no duration is specified, the default is 250 milliseconds (ms) for an INFO message and 200 ms for a NOTIFY message.

If the SBC determines that either the INFO method or the NOTIFY method for DTMF is supported by the originator, support for both INFO and NOTIFY methods are advertised by the presence of Call-Info and Accept headers on the outbound call. Interworking between these methods is efficient and improves the probability of finding a suitable method for DTMF interworking.

In the case of interworking of DTMF relay using Network Terminating Equipment (NTE) (RFC 2833) and out-of-band DTMF using SIP INFO or SIP NOTIFY, Cisco Unified Border Element (SP Edition) intercepts the NTE packets with DTMF digits and converts them into the appropriate signaling methods through the Route Processor (RP). In the reverse direction, the RP instructs the Cisco Unified Border Element (SP Edition) to inject NTE DTMF packets into an RTP stream.

DTMF Packet Detection

To detect DTMF NTE packets, Cisco Unified Border Element (SP Edition) looks at the payload type of every RTP packet and compares it with that of NTE. In case of a match, Cisco Unified Border Element (SP Edition) looks at the event number to determine that it is a DTMF digit. Cisco Unified Border Element (SP Edition) then copies these packets to the RP. Figure 13-1 illustrates this process.

Figure 13-1 Sample Call Flow with INFO (RFC-2833) DTMF Interworking

Implementing Interworking DTMF

The following section describes how to configure the default duration of a DTMF event.

Note that Cisco Unified Border Element (SP Edition) may require you to configure header Allow, header Accept, and method INFO as shown below:

DTMF Relay Using SIP NOTIFY Messages

In Cisco IOS XE Release 2.4, Cisco Unified Border Element (SP Edition) adds support for DTMF Relay Using SIP NOTIFY Messages. This is an out-of-band procedure for DTMF relay and is sometimes referred to as NOTIFY-based DTMF Relay.

DTMF tones are the tones that are generated when a telephone key is pressed on a touchtone phone. Sometimes the called endpoint needs to hear those tones, such as when you enter digits during the call in response to a menu. However, low-bandwidth codecs can distort the sound. DTMF relay allows that tone information to be reliably passed from one endpoint to the other. By default, SIP uses in-band signaling, sending the DTMF information in the voice stream. If no DTMF relay method is configured, the tones are sent in-band. However, you can configure DTMF relay to use SIP NOTIFY messages for transmitting DTMF tone information.

Cisco Unified Border Element (SP Edition) supports two out-of-band procedures for DTMF relay. One uses SIP INFO methods, and the other uses SIP NOTIFY methods. The SIP INFO method sends DTMF digits in INFO messages. It is always enabled. When a gateway receives an INFO message containing DTMF relay information, it sends the corresponding tone.

SIP NOTIFY DTMF relay is negotiated by including a Call-Info field in the SIP INVITE and response messages, on a per-adjacency basis. This field indicates an ability to use NOTIFY for DTMF tones and the duration of each tone in milliseconds. When a DTMF tone is generated, the caller sends a NOTIFY message to the callee. When the callee receives the NOTIFY, it responds with SIP 200 OK and plays the DTMF tone.

Note For Cisco IOS XE Release 2.4 and later, this feature is supported in the unified model only.

You can configure a preferred SIP signaling DTMF transport method for endpoints on an adjacency. If Cisco Unified Border Element (SP Edition) has received DTMF information on a call and is sending it to an endpoint on the adjacency, Cisco Unified Border Element (SP Edition) uses a preferred DTMF method to send the information, provided the endpoint supports this method. You can set one of the following DTMF relay methods as the preferred method:

• SIP NOTIFY DTMF Relay (default value)
• SIP INFO DTMF Relay

Use the dtmf prefer sip [info | notify] command to configure the preferred relay method.

The default on the Cisco Unified Border Element (SP Edition) is the SIP-NOTIFY relay method. However, Cisco Unified Border Element (SP Edition) uses the RTP-NTE in-band DTMF relay method if the other side does not support SIP-NOTIFY. If no DTMF relay method is configured, the tones are sent in-band.

When SIP NOTIFY relay is enabled on an adjacency, then:

• The SBC accepts in-call, out-of-subscription NOTIFY messages with a DTMF Payload. These messages are not required to contain a Subscription-State header.
• The SBC accepts a Call-Info header in an INVITE message specifying a telephone-event that indicates support for SIP NOTIFY DTMF Relay.
• Configure the NOTIFY interval. You need to configure the maximum interval in milliseconds that the SBC waits between NOTIFY messages for a single DTMF event.

In this case, the SBC has not received an inbound Call-Info header specifying the negotiated duration, so this value is used instead.

Use the dtmf sip notify interval command.

• You can also configure a default duration. This specifies the duration in milliseconds that the SBC advertises on the outbound DTMF transport method if the inbound side of the call does not supply a duration.

Use the dtmf sip default duration command.

DTMF Method Interworking and ACCEPT Header Handling

The SBC can be configured to perform the following functions to support the INFO method in any circumstance:

• Automatically detect support for DTMF in INFO (default behavior).
• Does not send DTMF in INFO, and rejects DTMF in INFO, if received.
• Accepts that DTMF in INFO is supported, regardless of the indication in the Accept header.

Auto detection does not detect support for DTMF-based relay in the following events:

• The Allow header contains the INFO method, but does not have the Accept header.
• The Accept header is present, but does not contain the application/dtmf-relay information. Therefore, the SBC can be configured to assume support of DTMF in INFO.