AudioCodes Mediant 500 E-SBC, User Manual

Page: 454 / 920

User's Manual 454 Document #: LTRT-10437
Mediant 500 E-SBC
c. The device checks for common coders between the SDP offered coders and the
Allowed Coders Group list.
For example, assume the following:

The SDP coder offer includes the following coders: G.729, G.711, and G.723.

The source (first) leg includes the following Allowed Coders: G.711 and G.729.
The device selects the common coders, i.e., G.711 and G.729 (with changed preferred
coder priority - highest for G.711). In other words, it removes the coders that are not in the
Allowed Coders list and the order of priority is first according to the Allowed Coders list.
27.4.4 Prioritizing Coder List in SDP Offer
In addition to restricting the use of coders with Allowed coders, you can prioritize the
coders listed in the SDP offer. This feature is referred to as
Coder Preference . This is done
on both SBC legs:

Incoming SDP offer: The device arranges the coder list according to the order in the
Allowed Coders Group table. The coders listed higher up in the table take preference
over ones listed lower down in the table. This feature is enabled by setting the
'Allowed Coders Mode' parameter in the IP Profile table to
Preference or Restriction
and Preference . If set to Preference , in addition to the Allowed coders that are listed
first in the SDP offer, the original coders received in the SDP are retained and listed
after the Allowed coders. Thus, this mode does not necessarily restrict coder use to
Allowed coders, but uses (prefers) the Allowed coders whenever possible.

Outgoing SDP offer: If only Allowed coders are used, the coders are arranged in the
SDP offer as described above.
27.4.5 SRTP-RTP and SRTP-SRTP Transcoding
The device supports transcoding between SRTP and RTP. The device can also enforce
specific SBC legs to use SRTP and/or RTP. The device’s handling of SRTP/RTP is
configured using the IP Profile parameter, SBCMediaSecurityBehaviour, which provides
the following options:

SBC passes the media as is, regardless of whether it’s RTP or SRTP (default).

SBC legs negotiate only SRTP media lines (m=); RTP media lines are removed from
the incoming SDP offer\answer.

SBC legs negotiate only RTP media lines; SRTP media lines are removed from the
incoming offer\answer.

Each SDP offer\answer is extended (if not already) to two media lines for RTP and
SRTP.
If after SDP offer\answer negotiation, one SBC leg uses RTP while the other uses SRTP,
then the device performs RTP-SRTP transcoding. To translate between RTP and SRTP,
the following prerequisites must be met:

At least one supported SDP "crypto" attribute.

The EnableMediaSecurity parameter must be set to 1.
Transcoding where both legs are configured for SRTP is typically required to trans-encrypt
and trans-decrypt. This is relevant when the MKI and Symmetric MKI parameters are
enabled. In other words, both sides need to both encrypt and decrypt the outgoing and
incoming SRTP packets, respectively.
Channel (DSP) resources are not required for RTP and SRTP transcoding.