User's Manual 664 Document #: LTRT-27055
Mediant 1000B Gateway & E-SBC
29.5.8 Multiple RTP Media Streams per Call Session
The device's SBC application supports multiple RTP media streams per SBC call session.
It supports the negotiation of up to five media streams ('m=' line) in the SDP offer/answer
model per session. The media can include a combination of any of the following types:
Audio, indicated in the SDP as 'm=audio'
Video, indicated in the SDP as 'm=video'
Text, indicated in the SDP as 'm=text'
Fax, indicated in the SDP as 'm=image'
Binary Floor Control Protocol (BFCP), indicated in the SDP as 'm=application <port>
UDP/BFCP'
Therefore, the device supports 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 (e.g., does not support the coder), it relays the SBC dialog transparently.
29.5.9 Interworking Miscellaneous Media Handling
This section describes various interworking features relating to media handling.
29.5.9.1 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 the parameter to determine the DTMF
method for the leg.
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.
29.5.9.2 Interworking RTP Redundancy
The device supports interworking of RTP redundancy (according to RFC 2198) between
SIP entities. Employing IP Profiles, you can configure RTP redundancy handling per SIP
entity:
Generate RFC 2198 redundant packets (IpProfile_RTPRedundancyDepth parameter).
Determine RTP redundancy support in the RTP redundancy negotiation in SDP
offer/answer (IpProfile_SBCRTPRedundancyBehavior parameter). If not supported,