Asymmetric Dynamic Payload Types Enablement

The Enterprise SBC 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 Enterprise SBC. This behavior requires transcoding resources.

The Enterprise SBC'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 Enterprise SBC included in its SDP offer. The Enterprise SBC 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.

Payload type the same for both media flows

The Enterprise SBC 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 Enterprise SBC 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 Enterprise SBC behavior, one-way audio may result.

SDP negotiated with AMR PT 99 and PT 101 on egress

To support the above mentioned call flow, "options +audio-allow-asymmetric-pt" needs to be enabled on the media-manager. This option works only for the already transcoded calls. The asymmetric dynamic PT mapping works as below when this feature is enabled.

SDP negotiated with AMR PT 99 and PT 101 on egress

Configurations for non-Standard PT Cases

This section explains two configuration options you can use to support rare call flow issues associated with payload types. The first scenario includes non-transcoded call flow wherein a UAC presents an unexpected payload type (PT) within the context of a re-INVITE. This flow requires additional logic for the Enterprise SBC to handle the re-INVITE. The second scenario includes the Enterprise SBC handling payload types within the context of matching a codec-policy with traffic even though the sub-names are not the same. Both of these scenarios become supported when you enable their respective configuration options.

Asymmetric PT for Calls without Transcoding

In rare instances, the Enterprise SBC may need to handle a dialog that uses three different PTs for the same codec within a call that does not require transcoding. The Enterprise SBC supports payload type mapping without transcoding when all of the following conditions are met:

The offer/answer codecs are identical.
The offer/answer payload formats (specified by the AMR/AMR-WB octet-align parameter) are identical.
The offer/answer mode-sets (specified by the AMR/AMR-WB mode-set parameter) are identical or intersect.
You have set the audio-payload-type-mapping=yes option in the media-manager.

All of these conditions may be met even though the caller and callee are presenting different PT values. The Enterprise SBC, by default, behaves in compliance with the RFC 3264 (8.3.2 Changing the Set of Media Formats), which recommends against scenarios like the ones this feature accommodates. The Enterprise SBC, however, provides you with configuration options to overcome these scenarios.

Note:

The Enterprise SBC performs PT mapping on both the signaling plane (SDP offer/answer) and the media plane (RTP PT header).

The diagram below presents a case wherein the re-INVITE issue addressed by this feature occurs. This call flow uses a new codec and a previously used PT during a re-INVITE sequence. Ultimately, the UAS issues a previously used PT in its Re-INVITE response causing the Enterprise SBC to be unable to perform payload mapping on the calling (west) flow.

This call flow proceeds as follows:

A caller presents an INVITE during the signaling phase using payload type Z (PT 116 for codec AMR-WB), X (PT 96 for codec AMR).
The callee responds to the INVITE , with payload type Z (PT 116 for codec AMR-WB).
This results in a non-transcoded call established on AMR-WB (116).
Later, the caller issues a Re-INVITE with a new offer that includes PT X (associating now 96 for AMR-WB). Recall that X was initially associated with AMR in the initial offer. Here, the caller endpoint is not compliant with RFC 3264.
To comply with RFC3264, the Enterprise SBC modifies the already used PT X (96) to PT Y (100) in the outgoing INVITE.
The callee responds to the INVITE, but presents the previously used payload type Z (PT 116 for AMR-WB), establishing asymmetric payload type mapping at the egress.
Since the audio-payload-type-mapping feature is enabled, the Enterprise SBC modifies the PT Z (116) to payload X (96) and sends it in the SIP response (200 OK) towards the caller.
At the media level, without this feature enablement, the audio_pt mapping is done as follows.
- Called (east) flow: PT X maps to PT Z (96 to 116)
- Calling (west) Flow: PT Z maps to PT X (116 to 96)
But the callee is an asymmetric endpoint and can accept and send different payload types. Therefore, the callee starts sending RTP on PT Y (100) and expecting RTP on PT Z (116).
At the media level, the Enterprise SBC cannot map the PT Y (100) to the identifier "X" (96) on the calling (west) flow, so the call degrades to one-way audio (OWA).
The RTP on the called (east) side of the call flows correctly.

This flow depicts the default SBC unable to support the PT signaling

To support this call flow, you can set the asymmetric-pt option on realm-config that must support this asymmetric PT function.

ORACLEORACLE(realm-config)#options +asymmetric-pt

This option is applicable only for calls that start as non-transcoded calls, but are faced with a new codec and a previously used PT during a re-INVITE sequence. If you enable the asymmetric-pt option, the use case works properly. In this case, the EP honors the PT sent in the offer and sends the RTP on the same PT. This case results in asymmetric PT mapping on the egress leg.

This flow depicts the SBC using the asymmetric-pt option to support asymmetric PT signaling.

You must exercise caution when considering how the asymmetric-pt option would work in your environment. For example, when you enable it, the use-case below does not work.

Note that an endpoint can be either asymmetric or symmetric. You enable the asymmetric-pt option only when you know that the you need to handle asymmetric endpoints, and therefore need to send and receive RTP on different PTs. The result again is one-way audio (OWA). If the caller endpoint below is symmetric, meaning it sends RTP on the same PT specified in the 200 OK response, you should not enable this option.

This flow depicts the SBC unable to support the PT signaling.

Loose Matching on Subnames

Call flows can use different media profile subnames titled within media-profile objects even though those profiles are essentially the same. Similar to the issue above, you can also configure the Enterprise SBC with the loose-subname-match option on realm-config to support calls when the only variance between codec negotiation are the subnames used. This issue can cause call issues for both transcoded and non-transcoded calls.

Consider the case wherein multiple media-profile objects are applicable to a given call because they are all used with AMR-WB. Note that they all have different subnames.

media-profile
name AMR-WB
subname default31
parameters mode-set="0,1,2"
octet-align=1

Note:

This first profile will not be matched because it has octet-align=1.

media-profile
name AMR-WB
subname default3G
parameters mode-set="0,1,2"
octet-align=0

Note:

This profile will be used, supported by this feature.

media-profile
name AMR-WB
subname defaultA1
parameters mode-set="0,1,2,3,4,5,6,7,"
octet-align=1

Note:

This third profile will not be matched because it has octet-align=1.

media-profile
name AMR-WB
subname defaultAll
parameters mode-set="0,1,2,3,4,5,6,7,"
octet-align=0

Note:

This profile will be used, supported by this feature.

Consider the following sequence, wherein this feature applies:

An initial call is connected with AMR-WB, mode-set = 0,1,2. This occurs during the signaling cycle.
In the Re-INVITE, the caller sends an offer with all mode-set and the callee's 200 OK includes the subset (mode-set = 0,1,2).
Here the outgoing offer matches the "defaultAll" media profile and the response matches default3G. Since the codec, per the profile, does not match, the system does not initiate audio-pt mapping.
Here the outgoing PT 97 matches the profile with subname "defaultAll" media profile and the response to PT 100 matches the profile with subname "default3G".

This image depicts the SBC mapping payload types properly, using the loose subname match configuration

In this flow, the Enterprise SBC converts the the RPT of PT 96 from UAC to RTP PT 100. The Enterprise SBC then also converts RTP 97 from the UAS to RTP 96 towards the UAC.

To support these call flows, you set the loose-subname-match option on the egress realm-config.

ORACLEORACLE(realm-config)#options +loose-subname-match

To have the system perform asymmetric PT mapping and audio PT mapping, along with loose media-profile matching, you enable all three options covered above, including audio-payload-type-mapping=yes, asymmetric-pt, and loose-subname-match.

Note:

If the loose-subname-match is not enabled, then the audio PT mapping does not work and the system forwards PT 100 in re-invite to the Ingress and does not convert the RTP audio PT from Egress to RTP PT 96 on west flow.

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.

Additional applicable features include supporting specific disparate PT mapping and media-policy subname matching.

Before You Begin

Confirm that you are in Superuser mode.

Procedure

Access the media-manager-config configuration element.

ORACLE# configure terminal
ORACLE(configure)# media-manager
ORACLE(media-manager)# media-manager
ORACLE(media-manager-config)#

Type select to begin editing.

ORACLE(media-manager-config)# select

ORACLE(media-manager-config)#

Use the options +audio-allow-asymmetric-pt command to enable support for asymmetric payload types.
```
ACMEPACKET#(media-manager) options +audio-allow-asymmetric-pt
ACMEPACKET#(media-manager)
```
Use the audio-payload-type-mapping option to enable support for AMR-WB payload mapping without using transcoding resources.
```
ACMEPACKET#(media-manager) options +audio-allow-asymmetric-pt
ACMEPACKET#(media-manager)
```
Type done to save your configuration.
To proceed with both PT mapping and subname matching, navigate to the realm-config on which you need those features (call egress).
```
ACMEPACKET#(media-manager) exit
ACMEPACKET#(media-manager)realm-config
ACMEPACKET#(realm-config)select
```
To configure PT mapping when a re-INVITE introduces an unrecognized PT value during a non-transcoded call, set the asymmetric-pt option.
```
ACMEPACKET#(realm-config)options +asymmetric-pt
```
To configure loose subname matching for applying equivalent codec-policy objects to a call in case of PT value mismatches, set the loose-subname-match option
```
ACMEPACKET#(realm-config)options +loose-subname-match
```

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.

The Default Symmetric RFC2833 Interworking diagram is described above.

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. The Asymmetric FRC2833 Interworking diagram is described above.

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.