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 Communications 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 Communications 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 Communications 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 Communications 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 Communications 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 Communications 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 Communications 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 Communications 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.