Translation Evaluation

After SDP has been negotiated, the Oracle Communications Session Border Controller determines what types of DTMF translation takes place for the call. The Oracle Communications Session Border Controller sequentially evaluates the following rules for each call leg to determine what DTMF indication type it will forward to an endpoint.

RFC 2833—When the SDP offer/answer exchange resolves to both the Oracle Communications Session Border Controller and the endpoint supporting RFC 2833 on one side of the call, the Oracle Communications Session Border Controller will send DTMF indications in RFC 2833 format.
DTMF audio tones—Three conditions must be met for the Oracle Communications Session Border Controller to support DTMF audio tones, as transcoded from another DTMF indication form:
- The applicable codec policy’s dtmf in audio parameter is set to preferred
- The endpoint and Oracle Communications Session Border Controller have negotiated to a DTMFable codec (G711)
- Transcoding resources are available
  
  Note:
  Because of rule number one, rule number two can not happen if RFC 2833 is supported in SDP—Only one media-based DTMF transfer method, RFC 2833 or DTMF audio tones may be used on a call leg.
If neither RFC 2833 nor DTMF Audio tones are supported on a call leg, as a result of SDP negotiation, then the Oracle Communications Session Border Controller forwards DTMF indication messages to that side in signaling message format (SIP INFO).

In the following images that illustrate DTMF transfer scenarios, a gears icon appears when relevant. This icon indicates that the Oracle Communications Session Border Controller performs DTMF indication processing, creating DTMF audio tones or RFC 2833 telephone-event messages from another form of DTMF indication.

RFC 2833 Sent by Offerer

In the following three examples, the SDP offerer sends DTMF indication messages in RFC 2833 format. The SDP answerer can receive DTMF indications in the format identified in each example.

RFC 2833 to RFC 2833

When the SDP offer and answer sides of a call both support RFC 2833, the Oracle Communications Session Border Controller forwards RFC 2833 messages between both sides of the call. No processing is used to transform these DTMF-indication massages to another format.

Note:

When the audio stream is transcoded, DTMF audio is completely removed from the audio stream.

The RFC 2833 to RFC 2833 diagram is described above.

A SIP INFO message received from either the offerer or answerer is forwarded unconverted to the other side of the call.

If there is no audio transcoding enabled for this call, and the egress side is set to dual, a received SIP INFO message will not be converted to both RFC 2833 and SIP INFO messaged for sending to the other side of the call.

If DTMF audio tones are received from either the offerer or answer, they are forwarded unconverted to the other side (when the audio portion of the call is not transcoded).

RFC 2833 to DTMF Audio Tones

When the SDP offer side supports RFC 2833, and the SDP answer side supports the three DTMF Audio Tone conditions and does not support RFC 2833, the Oracle Communications Session Border Controller converts from RFC 2833 to DTMF audio tones for the call.

A SIP INFO message received by the Oracle Communications Session Border Controller from either the offerer or answerer is converted into the DTMF transfer method that the previous diagram shows for the egress side of the message. In this case, transcoding resources are used.

RFC 2833 to SIP INFO

When the SDP offer side supports RFC 2833 and the SDP answer side does not support the DTMF conditions nor RFC 2833, the Oracle Communications Session Border Controller converts from RFC 2833 to SIP INFO.

If a SIP message is received from the offerer, it is forwarded unconverted to the answerer.

DTMF Audio Tones Sent by Offerer

In the following three examples, the SDP offerer sends DTMF indication messages in DTMF audio tones format. The SDP answerer can receive DTMF indications in the format identified in each example.

DTMF Audio to DTMF Audio

If the SDP offer and answer sides both support the same type of G711 codec, the audio stream is forwarded between the two sides without processing.

If the two sides of the call support DTMF audio tones, but use different audio codecs, and the SDP answer side supports the three DTMF Audio Tone conditions and does not support RFC 2833 then the Oracle Communications Session Border Controller will preserve DTMF audio tone indication across the call.

Transcoding resources are used only if different audio codecs are used or the Override Preferred DTMF Audio feature is enabled.

DTMF Audio to RFC 2833

When the SDP offer side supports DTMF audio tones, and the SDP answer side supports RFC 2833, and transcoding resources are available, and does NOT support either or both of the first two DTMF Audio tone conditions, then the Oracle Communications Session Border Controller will convert incoming DTMF audio tones to outgoing RFC 2833 packets.

Transcoding resources are always required in this scenario.

DTMF Audio to SIP

When the SDP offer side supports DTMF audio tones, and the SDP answer side does not support RFC 2833, and does not support the three DTMF Audio Tone conditions, then the Oracle Communications Session Border Controller converts incoming DTMF audio tones to SIP INFOmessages.

Transcoding resources are always required in this scenario.

SIP INFO Sent By Offerer

In the following three examples, the SDP offerer sends DTMF indication messages in SIP INFO message format. The SDP answerer can receive DTMF indications in the format identified in each example.

SIP INFO to RFC 2833

When the SDP offer side sends a SIP INFO message, and the SDP answer side supports RFC 2833, then the Oracle Communications Session Border Controller will convert incoming SIP INFO messages to outgoing RFC 2833 packets.

SIP INFO to DTMF Audio

SIP INFO will only be converted to DTMF audio tones only if RFC 2833 is not supported, dtmf-in-audio is enabled, the answer side supports a G711 codec, and transcoding resources are available.

Transcoding resources are always required in this scenario.

SIP INFO to SIP INFO

When the SDP offer side sends a SIP INFO message and the SDP answer side does not support RFC 2833 and does not support the three DTMF audio tone conditions, the SIP INFO message will always be forwarded as the like SIP INFO message.