Asymmetric Dynamic Payload Types Enablement
Transcoding Support for Asymmetric Dynamic Payload Types supports calls with asymmetric payload types such that a codec offered with one payload type and answered with another payload type is acceptable to the Oracle® Enterprise Session Border Controller. This behavior requires transcoding resources.
The Oracle® Enterprise Session Border Controller's default behavior when an endpoint answers an SDP offer with a different payload type than offered is to use what the endpoint replied with as if that were what the Oracle® Enterprise Session Border Controller included in its SDP offer. The Oracle® Enterprise Session Border Controller would then expect to receive the same payload type that the endpoint offered. This is referred to as symmetric payload type mapping, whereby the payload type number is the same for both media flows.
The Oracle® Enterprise Session Border Controller needs to support the asymmetric case when codecs with dynamic payload types are used. For example, a call may be set up with the dynamic codec using one payload type value, and a reINVITE may use a different payload type value for the same codec. Because of the range of remote UE equipment's behavior in a reINVITE case, the Oracle® Enterprise Session Border Controller can support this via its Asymmetric Dynamic Payload Type feature. That is, some devices do not necessarily use the currently negotiated payload type, they may use previously negotiated payload types. As such devices interact with the default Oracle® Enterprise Session Border Controller behavior, one-way audio may result.
For transcoded calls, enabling this feature places no additional load on the system. But for calls that are not transcoded, this feature consumes transcoding resources.
Configure Transcoding for Asymmetric Dynamic Payload Types
Transcoding support for asymmetric dynamic payload types enables the Oracle® Enterprise Session Border Controller to perform transcoding when the Real-time Transport Protocol (RTP) is offered with one payload type and is answered with another payload type. Enable transcoding for asymmetric dynamic payload types from the command line.
Before You Begin
- Confirm that you are in Superuser mode.
Procedure
Asymmetric Payload Type Support for RFC2833 Interworking
RFC3264 describes "asymmetric" behavior when each participant of a call leg sends can expect a different payload-type value for the RTP stream. Conversely, when the two participants in a call leg must send and receive an RTP stream using the same Payload Type value, the behavior is symmetric. The Oracle® Enterprise Session Border Controller can be configured to behave in an RFC-compliant manner, which is to support the asymmetric case. Symmetric-only cases are enforced by default.
Default Symmetric RFC2833 Interworking
The Oracle® Enterprise Session Border Controller's default behavior when an endpoint answers an SDP offer with a different payload type value for RFC 2833 telephone-events than what the SBC sent, is to mimic what the Answerer replied with as the payload type value it (the SBC) will expect. This is referred to as symmetric payload type mapping, whereby the SBC sends RTP with the payload type value that the answerer replied with in the signaling phase of the call, and also expects that same payload type value when RTP is sent to it (despite having sent a different value in the initial SDP offer).
The following example shows the default behavior. When the Answerer returns PT 101, the Oracle® Enterprise Session Border Controller is prepared to enforce symmetric-only behavior on the egress realm by expecting RFC2833 packets with Payload Type 101, even though it offered Payload Type 99.
Asymmetric RFC2833 Interworking
Since ingress-side behavior is to reply with the payload type offered, it expects payload type 99 and sends payload type 99. Thus to facilitate RFC2833 interworking, the payload types will be remapped from 99 -> 101 in the eastbound direction and 101 -> 99 in the westbound direction.
The Oracle® Enterprise Session Border Controller supports the asymmetric, RFC-compliant case by configuration. In this case, as the signaling is set up on the egress side of the call, the Oracle® Enterprise Session Border Controller indicates it expects to receive RFC2833 packets with Payload Type 99, while the answerer indicates it expects to receive RFC 2833 packets with Payload Type 101. This valid call state can be accommodated by the SBC when the rfc2833-allow-asymmetric-pt option is configured.
Therefore, the Oracle® Enterprise Session Border Controller being able to support asymmetric payload types for RFC2833 packets, will remap from 99 ->101 in the eastbound direction and not have to remap the payload type value in the westbound direction.
The rfc2833-allow-asymmetric-pt option can be configured on a sip-interface or session-agent where this behavior is desired.
RFC2833 Interworking With and Without Transcoding Resources
In addition to the above behavior, it is important to note that the Oracle® Enterprise Session Border Controller acts differently for forwarding media streams depending on if the call is transcoded or not. If the call is not transcoded, any RTP stream, regardless of the payload type being different from what was negotiated in the signaling phase will be forwarded through the system as is. In either of the above examples, if the Answerer sends RFC2833 packets with payload type 105, that RTP stream will be forwarded to the ingress leg of the call, untouched by payload mapping. This behavior could potentially mask the fact that the Oracle® Enterprise Session Border Controller's egress interface is expecting a different payload type value than what is sent since the traffic is still forwarded to the ingress realm.
If the call is transcoded via codec-policy, any RTP stream that uses an unexpected payload type (as different from what was negotiated in the signaling phase) will be dropped by the system. In the above example, if the Answerer sends RFC2833 packets with payload type 105, that RTP stream will be dropped.