AudioCodes Mediant 3000, User Manual

Page: 418 / 872

User's Manual 418 Document #: LTRT-89729
Mediant 3000
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.
28.4.9 Multiple RTP Media Streams per Call Session
The device's SBC application supports multiple RTP media streams per SBC call session.
Up to five different media types can be included in a session:

Audio (m=audio)

Video (m=video)

Text (m=text)

Fax (m=image)
Therefore, the device can provide transcoding of various attributes in the SDP offer/answer
(e.g., codec, port, and packetization time) per media type. If the device is unable to perform
transcoding (for example, does not support the codec), it relays the SBC dialog
transparently.
28.4.10 Interworking DTMF Methods
The device supports interworking between various DTMF methods such as RFC 2833, In-
Band DTMF’s, and SIP INFO (Cisco\Nortel\Korea). By default, the device allows the
remote user agents to negotiate (in case of RFC 2833) and passes DTMF without
intervention. However, if two user agents (UA) support different DTMF methods, the device
can interwork these different DTMF methods at each leg.
This DTMF interworking feature is enabled using IP Profiles ( ini file parameter IPProfile):

SBCRFC2833Behavior - affects the RFC 2833 SDP offer\answer negotiation:
•
[0] (default): the device does not intervene in the RFC 2833 negotiation.
•
[1]: each outgoing offer\answer includes RFC 2833 in the offered SDP (the
device adds RFC 2833 only if the incoming offer does not include RFC 2833).
•
[2]: the device removes RFC 2833 from the incoming offer.

SBCAlternativeDTMFMethod – the device's first priority for DTMF method at each leg
is RFC 2833. Therefore, if a specific leg negotiates RFC 2833 successfully, then the
chosen DTMF method for this leg is RFC 2833. For legs where RFC 2833 is not
negotiated successfully, the device uses this parameter to determine the DTMF
method for the leg.
•
[0] (default): the device does not attempt to interwork any special DTMF method
•
[1]: In Band
•
[2]: INFO, Cisco
•
[3]: INFO, Nortel
•
[4]: INFO, Korea
The chosen DTMF method determines (for each leg) which DTMF method is used for
sending DTMF’s. If the device interworks between different DTMF methods and one of the
methods is In-band\RFC 2833, detection and generation of DTMF methods requires DSP
allocation.