RFC 2833 DTMF Interworking
This section explains the Oracle® Enterprise Session Border Controller’s support of transporting Dual Tone Multi-Frequency (DTMF) in Real-Time Transport Protocol (RTP) packets (as described in RFC 2833) to H.245 User Input Indication (UII) or SIP INFO method interworking.
Multimedia devices and applications must exchange user-input DTMF information end-to-end over IP networks. The Oracle® Enterprise Session Border Controller provides the interworking capabilities required to interconnect networks that use different signaling protocols. Also, the Oracle® Enterprise Session Border Controller provides DTMF translation to communicate DTMF across network boundaries.
The Oracle® Enterprise Session Border Controller supports:
- RFC 2833 to H.245 UII translation for H.323-to-H.323 calls, when one side is a version 4 H.323 device requiring RFC-2833 DTMF event packets, and the other side is a pre-version 4 H.323 device that only uses H.245 UII.
- RFC 2833 to H.245 UII or INFO translation of H.323 to SIP (and SIP to H.323) IWF calls, when one side is a version 4 H.323 device requiring RFC 2833 DTMF event packets and the SIP endpoint only supports INFO messages. Or when one side is a pre-version 4 H.323 device that only uses H.245 UII and the SIP endpoint supports RFC-2833 DTMF event packets.
About RFC 2833
RFC 2833 specifies a way of encoding DTMF signaling in RTP streams. It does not encode the audio of the tone itself, instead a signal indicates the tone is being sent. RFC 2833 defines how to carry DTMF events in RTP packets. It defines a payload format for carrying DTMF digits used when a gateway detects DTMF on the incoming messages and sends the RTP payload instead of regular audio packets.
About H.245 UII
H.245 provides a capability exchange functionality to allow the negotiation of capabilities and to identify a set of features common to both endpoints. The media and data flows are organized in logical channels. H.245 provides logical channel signaling to allow logical channel open/close and parameter exchange operations. The H.245 signaling protocol is reliable, which ensures that the DTMF tones will be delivered.
H.245 User Input Indication (UII) plays a key role in all the services that require user interaction. For video messaging, typical uses of UII include selection of user preferences, message recording and retrieval, and typical mailbox management functions. H.245 UII provides two levels of UII, alphanumeric and signal.
About RFC 2833 to H.245 UII Interworking
The Oracle® Enterprise Session Border Controller provides 2833 to H.245-UII interworking by checking 2833-enabled RTP streams for packets matching the payload type number for 2833. It then sends the captured packet to the host for processing and translation to H.245 UII messages. A H.245 UII message received by the Oracle® Enterprise Session Border Controller is translated to 2833 packets and inserted into the appropriate RTP stream.
About DTMF Transfer
DTMF transfer is the communication of DTMF across network boundaries. It is widely used in applications such as interactive voice response (IVR) and calling card applications.
The multiple ways to convey DTMF information for packet-based communications include:
- In-band audio: DTMF digit waveforms are encoded the same as voice packets. This method is unreliable for compressed codecs such as G.729 and G.723
- Out-of-band signaling events:
H.245 defines out-of-band signaling events (UII) for transmitting DTMF information. The H.245 signal or H.245 alphanumeric methods separate DTMF digits from the voice stream and send them through the H.245 signaling channel instead of through the RTP channel. The tones are transported in H.245 UII messages.
All H.323 version 2 compliant systems are required to support the H.245 alphanumeric method, while support of the H.245 signal method is optional.
SIP INFO – uses the SIP INFO method to generate DTMF tones on the telephony call leg. The SIP INFO message is sent along the signaling path of the call. Upon receipt of a SIP INFO message with DTMF content, the gateway generates the specified DTMF tone on the telephony end of the call.
- RTP named telephony events (NTE): uses NTE to relay DTMF tones, which provides a standardized means of transporting DTMF tones in RTP packets according to section 3 of RFC 2833.
Of the three RTP payload formats available, the Oracle® Enterprise Session Border Controller supports RTP NTE. NTE is most widely used for SIP devices but is also supported in H.323 version 4 or higher endpoints.
RFC 2833 defines the format of NTE RTP packets used to transport DTMF digits, hookflash, and other telephony events between two peer endpoints. With the NTE method, the endpoints perform per-call negotiation of the DTMF transfer method. They also negotiate to determine the payload type value for the NTE RTP packets.
The NTE payload takes the place of codec data in a standard RTP packet. The payload type number field of the RTP packet header identifies the contents as 2833 NTE. The payload type number is negotiated per call. The local device sends the payload type number to use for 2833 telephone event packets using a SDP or H.245 Terminal Capability Set (TCS), which tells the other side what payload type number to use when sending the named event packets to the local device. Most devices use payload type number 101 for 2833 packets, although no default is specified in the standard.
The 2833 packet’s RTP header also makes use of the timestamp field. Because events often last longer than the 2833 packets sending interval, the timestamp of the first 2833 packet an event represents the beginning reference time for subsequent 2833 packets for that same event. For events that span multiple RTP packets, the RTP timestamp identifies the beginning of the event. As a result, several RTP packets might carry the same timestamp.
See RFC 2833 and draft-ietf-avt-rfc2833bis-07.txt for more information.
Preferred and Transparent 2833
To support preferred (signaled) 2833 and transparent 2833, the Oracle® Enterprise Session Border Controller provides 2833 detection and generation (if necessary) when the endpoint signals support for 2833.
- Preferred: the Oracle® Enterprise Session Border Controller only generates and detects 2833 for endpoints if they negotiate support for 2833 through signaling
- Transparent: the Oracle® Enterprise Session Border Controller offers and answers based on end-to-end signaling and transparently relaying 2833
Preferred 2883 Support
If one side of the call, or a SIP interface, or a session agent, is configured for preferred 2833, the Oracle® Enterprise Session Border Controller only generates and detects 2833 for endpoints if they signal support for 2833. The Oracle® Enterprise Session Border Controller will offer 2833 in the TCS SDP, even if the originating caller did not.
- When the
Oracle® Enterprise Session Border Controller manages calls originating from a preferred source
going to a preferred target, it:
Performs 2833 translation for an endpoint when the originating side requests 2833 but the target does not negotiate 2833
Allows 2833 to pass through if the originating side and target of the call are configured as preferred and negotiate 2833
- When the
Oracle® Enterprise Session Border Controller manages calls originating from a preferred source
going to a transparent target, it:
Performs 2833 translation when the originating side requests 2833 but the target is configured as transparent and does not negotiate 2833.
Allows 2833 to pass through if the originating side and the target of the call are configured as transparent and negotiate 2833. The Oracle® Enterprise Session Border Controller does not perform active translation because both ends support 2833.
If one SIP endpoint does not signal 2833 capability, but the other SIP or H.323 endpoints do, the Oracle® Enterprise Session Border Controller does not perform 2833 translation.
Transparent 2833 Support
The default configuration of the Oracle® Enterprise Session Border Controller for H.323 is transparent 2833. The Oracle® Enterprise Session Border Controller passes on the offered capabilities to the next-hop signaling element. If the next-hop endpoint is for a transparent 2833 target, typical capability negotiation determines the DTMF method. The Oracle® Enterprise Session Border Controller transparently relays the DTMF as it has in previous releases.
With transparent 2833, the Oracle® Enterprise Session Border Controller acts as a typical B2BUA or B2BGW/GK. However when the target of the call is configured as preferred 2833, the Oracle® Enterprise Session Border Controller:
- Relays the 2833 packets if the originating endpoint signals 2833 and the next-hop endpoint for the preferred target signals 2833
- Performs 2833 translation if the originating endpoint does not signal 2833 and the next-hop endpoint for the preferred target does signal 2833
- Does not perform 2833 translation or transparently relay 2833 if the originating endpoint signals 2833 and the next-hop endpoint for the preferred target (or even a transparent 2833 target) does not signal 2833.
Payload Type Handling
The Oracle® Enterprise Session Border Controller supports the RTP NTE for telephony events such as transport of DTMF digits and hook flash. Using RTP NTE, endpoints perform per-call negotiation of the DTMF transfer method and negotiate payload type value for the RTP NTE packets.
Although most endpoints use payload type number 101, the RTP payload type formats can become asymmetrical when being interworked between SIP and H.323 because there is no default standard and endpoints use different types. This means that the payload type negotiated on one side of the Oracle® Enterprise Session Border Controller, and that ends up being used for the call, might not be the same payload type negotiated on the other side of the Oracle® Enterprise Session Border Controller. And while certain endpoints handle the asymmetry well, others do not.
Consider the simplified example of an IWF call initiated in SIP and translated to H.323. In this scenario, the SIP endpoint negotiates the payload type 106 with the Oracle® Enterprise Session Border Controller. And despite the fact that the H.323 endpoint negotiates payload type 101, the Oracle® Enterprise Session Border Controller returns type 106 and the call proceeds using type 106.
However, you can enable forced symmetric payload type handling so the Oracle® Enterprise Session Border Controller changes the payload type of RFC 2833 packets to avoid using asymmetrical payload types.
For H.323 session agents and H.323 interfaces (stacks), you can configure an option that forces symmetric payload type use. The Oracle® Enterprise Session Border Controller can detect when the payload types negotiated by the SIP and H.323 endpoints are symmetrical and when they are not. When it detects asymmetrical payload type use, the Oracle® Enterprise Session Border Controller forces the remote endpoint to use the RFC 2833 payload type you configure in the SIP interface.
Basic RFC 2833 Negotiation Support
If H.323, SIP, or session agents on either side of the call are configured for preferred 2833 support, the Oracle® Enterprise Session Border Controller supports end-to-end signaled negotiation of DTMF on a call-by-call basis. If the calling party is not configured for preferred support but sends 2833, the Oracle® Enterprise Session Border Controller sends 2833 to the next-hop called party. If the calling party sends H.245 signals or alphanumeric UII, the Oracle® Enterprise Session Border Controller sends H.245 signals or alphanumeric UII to the next-hop called party (if it is an H.323 next-hop).
The Oracle® Enterprise Session Border Controller also supports hop-by-hop negotiation of DTMF capability on a call-by-call basis, if the signaling protocols or session agents on either side of the call are configured for preferred 2833 support.
H.323 to H.323 Negotiation
The Oracle® Enterprise Session Border Controller serves as the H.323 called gateway. It answers RFC 2833 audio telephony event capability in the version 4 H.323/H.245 TCS when it receives a call from an H.323 endpoint configured for preferred RFC 2833.
If the Oracle® Enterprise Session Border Controller is the answering device, configured for preferred support, and the calling device sends 2833, the Oracle® Enterprise Session Border Controller accepts the 2833 regardless of the next-hop’s DTMF capabilities. The received dynamic RTP payload type is used for detecting 2833 packets, while the response dynamic payload type is used for generating 2833 packets.
The Oracle® Enterprise Session Border Controller supports:
- RFC-2833 audio telephony events in the version 4 H.323/H.245 TCS as the H.323 calling gateway, when the Oracle® Enterprise Session Border Controller calls an H.323 endpoint configured for preferred RFC 2833 support. The Oracle® Enterprise Session Border Controller sends 2833 to the called party regardless of whether the calling party sends it.
- H.245 UII and RFC-2833 packets sent at the same time, to the same endpoint, even if only half of the call is being provided 2833 support by the
Oracle® Enterprise Session Border Controller.
If one half of the call supports H.245 UII, and the other half is being provided 2833 translation by the Oracle® Enterprise Session Border Controller, the Oracle® Enterprise Session Border Controller can also forward the H.245 UII it receives to the 2833 endpoint. For example, when the signaling goes through a gatekeeper or third party call control, sending the H.245 UII in the signaling path allows those devices to learn the DTMF digits pressed.
Signal and Alpha Type Support
The Oracle® Enterprise Session Border Controller supports:
- H.245 signal and alpha type UII in the H.323/H.245 TCS as the H.323 calling gateway when the:
Oracle® Enterprise Session Border Controller calls an H.323 endpoint configured for transparent 2833 support
calling endpoint’s target is configured as preferred
If the originating preferred side also sends 2833, the Oracle® Enterprise Session Border Controller forwards it to the transparent side. The Oracle® Enterprise Session Border Controller sends signal and alpha UII support to the called party regardless of whether the calling party sends it, if the call originates from a preferred side to a transparent side.
- H.245 alphanumeric UII for DTMF for H.323 endpoints that do not signal 2833 or contain explicit H.245 UII capability, for stacks configured for transparent 2833 support.
When the other half of the call is an H.323 endpoint of a stack configured for preferred 2833, the Oracle® Enterprise Session Border Controller translates incoming H.245 UII on the transparent side, to 2833 packets on the preferred side, and vice versa. If the other half of the call is an H.323 endpoint of a transparent stack, the Oracle® Enterprise Session Border Controller relays the H.245 UII messages.
- H.245 signal type UII for DTMF for H.323 endpoints that do not signal 2833, but do signal explicit H.245 UII capability, for stacks configured for transparent 2833 support.
When the other half of the call is an H.323 endpoint of a stack configured for preferred 2833, the Oracle® Enterprise Session Border Controller translates incoming H.245 signaled UII on the transparent side, to 2833 packets on the preferred side, and vice versa. If the other half of the call is an H.323 endpoint of a transparent stack, the Oracle® Enterprise Session Border Controller relays the H.245 UII messages if both sides support it.
H.323 Non-2833 Interworking with SIP
RFC 2833 and the SIP INFO method can be used for conveying DTMF information for SIP based-services. (RFC 2833 is the most widely used.) To provide end-to-end DTMF for SIP devices supporting RFC-2833 interworking with H.323 devices that do not, an RFC 2833 to H.323 UII interworking function is provided.
How H.323 to SIP Calls Work
For H.323 to SIP IWF calls, if 2833-related information is to be sent in the INVITE, the SIP interface of the SIP session agent has to be configured with the rfc2833-mode parameter set to preferred.
The following example shows an INVITE without 2833 in the SDP:
Apr 5 04:28:50.073 On 127.0.0.1:5070 sent to 127.0.0.1:5060
INVITE sip:780@192.168.200.6:5060 SIP/2.0
Via: SIP/2.0/UDP 127.0.0.1:5070;branch=z9hG4bKIWF0000gl2018604agg71c0;acme_irealm=external;acme_sa=192.168.1.6
Contact: "jdoe"<sip:127.0.0.1:5070>
GenericID: 114421133000000@000825010100
Supported: 100rel^M
From: "msmith"<sip:192.168.200.68:5060>;tag=000000ab00011940
To: <sip:780@192.168.200.6:5060>
Call-ID: 7f00000113ce000000ab000101d0@127.0.0.1
CSeq: 2 INVITE
Content-Length: 225
Content-Type: application/sdp
v=0
o=IWF 3 3 IN IP4 192.168.1.6
s=H323 Call
c=IN IP4 192.168.1.6
t=0 0
m=audio 5214 RTP/AVP 0 18
a=rtpmap:0 PCMU/8000/1
a=rtpmap:18 G729/8000/1
a=fmtp:18 annexb=no
m=video 5216 RTP/AVP 31
a=rtpmap:31 H261/9000/1SIP INFO—RFC 2833 Conversion
The Oracle® Enterprise Session Border Controller can perform SIP INFO—RFC 2833 conversion. The Oracle® Enterprise Session Border Controller also provides a way for you to enable a dual conversion mode, where the Oracle® Enterprise Session Border Controller:
- Inserts telephone-event in the SDP offer
- Generates both RFC 2833 event packets and SIP INFO messages regardless of whether or not the SDP offer indicates RFC 2833
You can enable this feature either for SIP interfaces or session agents. The following apply:
- If the next hop SIP interface or session agent’s
rfc2833-mode is set to preferred, then the SD inserts RFC 2833 into the SDP offer/answer. This occurs regardless of whether:
- The original SDP on the opposite side of the call does not support RFC 2833
- The opposite side’s SIP interface or session agent is set to transparent mode
- If the next hop SIP interface or session agent is set to transparent, then the behavior of the
Oracle® Enterprise Session Border Controller depends on the previous hop.
- If the previous hop is a SIP interface or session agent configured for transparent mode, then the S Oracle® Enterprise Session Border Controllerdoes not perform any conversion.
- If the previous hop is a SIP interface or session agent configured for preferred mode, the Oracle® Enterprise Session Border Controller does not insert RFC-2833 into the SDP on the transparent side. It does, however, translate from RFC 2833 to SIP INFO if the originating endpoint supports RFC 2833.
IPv6 SIP INFO to RFC 2833 Telephone Event Interworking
The Oracle® Enterprise Session Border Controller can interwork SIP INFO and RFC Telephone Event messages for IPv4, IPv6—or for any session requiring interworking between IPv4 and IPv6. Other than installing the applicable lisences on your Oracle® Enterprise Session Border Controller and enabling IPv6 support in your system configuration (system-config), you do not have to perform any configuration steps for this capability to work.
RFC 2833 Interworking Configuration
This section explains how to configure RFC 2833 to H.245 User Input Indication (UII) or SIP INFO method interworking.
Configuring the SIP Interface
You configure the 2833 mode and payload for the SIP interface. You must configure the payload the Oracle® Enterprise Session Border Controllerwill use for RFC 2833 packets, while interworking 2833 and INFO/UII.
To configure the SIP interface:
Configuring Session Agents
You configure session agents with:
- payload type the
Oracle® Enterprise Session Border Controller wants to use for RFC 2833 packets while interworking 2833 and UII.
The default value for this attribute is 0. When this value is zero, the global rfc2833-payload configured in the h323-configuration element will be used instead. For SIP session agents, the payload defined in the SIP interface is used, if the SIP interface is configured with the preferred RFC 2833 mode.
- 2833 mode
A value of transparent or preferred for the session agent’s 2833 mode will override any configuration in the h323-stack configuration element.
To configure session agents:
Enabling Payload Type Handling
You can configure H.323 session agents and H.323 interfaces (stacks) with an option that forces symmetric payload type use. For Payload Type Handling to work properly, you must set the following SIP interface and the global H.323 configuration parameters with these values:
- rfc2833-mode—Set this parameter to preferred; the default is transparent.
- rfc2833-payload—Set this parameter to the payload type you want forced for the remote endpoint. Your entry will be between
96 and
127, with
101 as the default.
To enable forced symmetric payload type handling for an H.323 session agent:
DTMF Transparency for IWF
In certain vendors’ implementations of DTMF during SIP/H.323 IWF, there have been discrepancies between the RFC 2833 and UII/INFO negotiations and what type of messages actually get sent. Instead of correcting these errors on its own end, the Oracle® Enterprise Session Border Controller has perpetuated these inaccuracies.
To ensure that the Oracle® Enterprise Session Border Controller always sends the correctly negotiated protocols, a media-manager-config parameter called translate-non-rfc2833-event has been created. When translate-non-rfc2833-event is enabled, the Oracle® Enterprise Session Border Controller always sends the type of messages that were initially negotiated, regardless of the type of messages it may be receiving.
RFC 2833 Packet Sequencing
You can configure your Oracle® Enterprise Session Border Controller to generate either the entire start-interim-end RFC 2833 packet sequence or only the last three end 2833 packets for non-signaled digit events.
Enhanced H.245 to 2833 DTMF Interworking
Enhanced H.245 to 2833 and SIP INFO to 2833 DTMF interworking addresses issues experienced where the way the Oracle® Enterprise Session Border Controller timestamps audio RTP packets result in dropped digits and digits with a stutter pattern. These occurrences can cause other network devices to deem the packets unrecoverable (due to jitter), meaning that they will never render the digit.
The Oracle® Enterprise Session Border Controller offers the following:
- Timestamp is based on the current time—The Oracle® Enterprise Session Border Controller can compute the timestamp of the egress 2833 packets using the actual time elapsed in milliseconds since the last RTP packet (rather than incrementing the time by 1 sample). Not only does the Oracle® Enterprise Session Border Controller fill out the timestamp field more accurately, but it also recalculates the checksum.
- End-event 2833 messages default behavior—The
Oracle® Enterprise Session Border Controller’s new default behavior is to send three end-event 2833 packets only if the DTMF event is received for:
- An alphanumeric UII or SIP INFO with no duration
- A signaled UII or SIP INFO with a duration less than the minimum signal duration (the value you configure using the new media manager configuration min-signal-duration option)
For a signaled UII or SIP INFO with a duration greater than the minimum signal duration, the Oracle® Enterprise Session Border Controller behaves as it does in prior releases: It sends the initial event packets, any interim packets (if they exist), and the three end packets.
- Configurable duration for the 2833 event—Without the enhancements being configured, the
Oracle® Enterprise Session Border Controller uses a 250 millisecond duration for the 2833 event when it receives an alphanumeric UII or a SIP INFO with no specified duration. The result is that 2833 packets are sent at 50-millisecond intervals until the 250 millisecond time expires; then the three end-event packets are sent.
Now the Oracle® Enterprise Session Border Controller allows you to set the duration of these 2833 events using a new default-2833-duration parameter (with a 100 millisecond default) in the media manager configuration. In addition, the Oracle® Enterprise Session Border Controller uses this configured value (instead of the duration sent in the signaling message) when it receives an UII or SIP INFO with a duration less than the minimum signal duration. It checks to make sure that the value for the default-2833-duration parameter is greater than the minimum signal duration.
- Configurable minimum signal duration value—Without this configured, the
Oracle® Enterprise Session Border Controller accepts and uses the duration it receives in the UII or SIP INFO for the 2833 event. However, you can configure this value using the
min-signal-duration option in the media manager configuration. If the duration the
Oracle® Enterprise Session Border Controller receives is less than the threshold, it uses the value configured in the
default-2833-duration parameter.
If you do not configure this option, then there is no signaling duration threshold.
Note:
Timestamp changes and duration changes only take effect when the 2833 timestamp (rfc-2833-timestamp) is enabled in the media manager configuration.