Capability Negotiation

SDP capability negotiation is the first phase of enabling DTMF transfer. The completion of the SDP offer/answer exchange yields a set of supported codecs between each UA and the Oracle® Enterprise Session Border Controller .

For DTMF transfer consideration, SDP manipulation is directed by parameters set in one of three configuration elements:

• codec policy
• signaling interface’s RFC 2833 mode
• session agent’s RFC 2833 mode

The Oracle® Enterprise Session Border Controller performs SDP manipulation (addition, removal, or modification of supported codecs) toward the called party first by any applicable codec policies. If one or more of the actions which define telephone-event Modification by Codec Policy occurs, then SDP manipulation is only performed by the codec policy configuration, not by RFC 2833 mode parameters in the signaling interface or session agent.

If a codec policy attached to either the ingress or egress realm triggers SDP manipulation, then the other realm uses codec policy for any telephone-event SDP manipulation; none of the RFC 2833 Mode configurations are used for SDP manipulation.

Note:

If the call does not trigger the evaluation of any codec policies, all DTMF transfer processing is only subject to RFC 2833 Mode rules.

If none of the telephone-event Modification by Codec occur, then the Oracle® Enterprise Session Border Controller performs SDP manipulation according to the RFC 2833 Mode parameters in the signaling interface or session agent.

SDP Manipulated by Codec Policy

When a call is received, any applicable codec policies are applied and evaluated. If telephone-event SDP is modified by codec policies, then SDP manipulation by RFC 2833 Mode is not performed for either side of the call.

telephone-event Modification by Codec Policy

For qualifying if telephone-event modification in SDP was performed by codec policy, one of the following events had to have happened:

• Codec policy explicitly deleted telephone-event by configuring allow telephone-event:no
• Codec policy explicitly added telephone-event by configuring add-on-egress telephone-event
• Codec policy implicitly denied telephone-event by allowing one or more codecs but not adding telephone-event to the allow list
• Codec policy has audio:no configured in the allow list

The following three cases highlight how codec policies can manipulate telephone-event SDP. Once any of these cases occurs, SDP manipulation by RFC 2833 Mode parameter will not be performed.

1. telephone-event added to SDP: The codec policy adds telephone-event to the SDP sent to the egress realm. The UA supports telephone-event.
2. telephone-event maintained in SDP: The codec policy maintains the offered telephone-event in the SDP sent into the egress realm. Although telephone-event was not answered in the egress realm, telephone-event is added back to the offerer-side SDP because of the add-on-egress setting in the ingress realm.
   
3. telephone-event removed from SDP: codec policy removes telephone-event from the initial SDP offer. telephone-event is not forwarded to the Answerer, and subsequently not returned from the answerer, or forwarded again to the offerer.
   

SDP Manipulated by RFC 2833 Mode

If none of the telephone-event Modification by Codec Policy events occur, as previously explained, SDP may still be modified by RFC 2833 Mode parameter if preferred or dual mode is configured.

The RFC 2833 mode parameter functions similarly to the add-on-egress parameter; it suggests telephone-event support, by adding it in SDP if not already there. This parameter must be set to preferred or dual to add telephone-event to SDP.

Transparent RFC 2833 Support

Setting a signaling interface or session agent’s RFC 2833 mode to transparent disables the addition of RFC 2833 telephone-event to SDP upon egress. The Oracle® Enterprise Session Border Controller passes the offered SDP capabilities to the next-hop signaling element.

Preferred RFC 2883 Support

Setting a signaling interface or session agent’s RFC 2833 mode to preferred indicates that the RFC 2833 telephone-event DTMF transfer method is the preferred method for sending a DTMF indication. In the capability negotiation phase a telephone-event media type will be inserted in the outgoing SDP offer, if it was not present in the original offer.

1. In the following example RFC 2833 mode is set to preferred on the egress side of the call. Because there is no telephone-event in the SDP, and RFC 2833 mode is set to preferred, the Oracle® Enterprise Session Border Controller adds telephone-event to the SDP offer.
   
2. In the following example, RFC 2833 is set to preferred mode on the SDP offer side of the call. The Oracle® Enterprise Session Border Controller maintains the telephone-event support even though telephone-event is not supported on the SDP answerer’s side of the call.
   

RFC 2833 Payload Type Mapping

The Oracle® Enterprise Session Border Controller does not require that call legs use the same media type for telephone-event. If each call leg uses a different media type value, the Oracle® Enterprise Session Border Controller facilitates payload type mapping to ensure the telephone-event media stream be reliably transported across the call.

• On the SDP offer side, when the Oracle® Enterprise Session Border Controller returns its SDP answer, it uses the same media type that the SDP offerer offered.
• The Oracle® Enterprise Session Border Controller forwards the originally offered telephone-event media type to the SDP answerer. If telephone-event was added by RFC 2833 mode, the Oracle® Enterprise Session Border Controller adds telephone-event with the media type value configured in the RFC 2833 payload parameter. If telephone-event was added by a codec policy, the Oracle® Enterprise Session Border Controller adds telephone-event with the media type value configured in the media profile.
• If the SDP answerer returns a new value for telephone-event, the Oracle® Enterprise Session Border Controller still supports RFC 2833 on that side of the call and uses the media type that the answerer sent.