AudioCodes Mediant 500 E-SBC, User Manual

Page: 450 / 920

User's Manual 450 Document #: LTRT-10437
Mediant 500 E-SBC
27.4 SBC Media Handling
Media behavior includes anything related to the establishment, management and
termination of media sessions within the SIP protocol. Media sessions are created using
the SIP "offer"/"answer" mechanism. If successful, the result is a bi-directional media (RTP)
flow (e.g. audio, fax, modem, DTMF). Each offer/answer may create more than one media
session of different types (e.g. audio and fax). In a SIP dialog, multiple offer/answer
transactions may occur, each may change the media sessions characteristics (e.g. IP
address, port, coders, media types, and RTP mode). The media capabilities exchanged in
an offer/answer transaction include the following:

Media types (Audio, Secure Audio, Video, Fax, Text...)

IP addresses and ports of the media flow

Media flow mode (send receive, receive only, send only, inactive)

Media coders (coders and their characteristics used in each media flow)

Other (standard or proprietary) media and session characteristics
Even though the device usually does not change the negotiated media capabilities (mainly
performed by the remote user agents), it does examine the media exchange to control
negotiated media types (if necessary) and to know how to open the RTP media channels
(IP addresses, coder type, payload type etc.). The device forwards multiple video streams
and text, as is.
The device interworks (normalization) the media (RTP-to-RTP, SRTP-to-RTP, and SRTP-
to-SRTP) between its SBC legs. It "re-builds" specific fields in the RTP header when
forwarding media packets. The main fields include the sequence number, SSRC, and
timestamp.
The device is aware and sometimes active in the offer\answer process due to the following:

NAT traversal: the device changes the SDP address to be its own address, thereby,
resolving NAT problems.

Firewall and security:
•
RTP pin holes - only RTP packets related to a successful offer\answer
negotiation traverse the device: When the device initializes, there are no RTP pin
holes opened, this means that each RTP\RTCP packets destined to the device
are discarded. Once an offer\answer transaction ends successfully, an RTP pin
hole is opened and RTP\RTCP flows between the two remote user agents. Once
a pin hole is opened, the payload type and RTP header version is validated for
each packet. RTP pin holes close if one of the associated SIP dialogs is closed
(may also be due to broken connection).
•
Late rogue detection - once a dialog is disconnected, the related pin holes also
disconnect.
•
Deep Packet inspection of the RTP that flows through the opened pin holes.

Adding of media functionality to SIP user agents:
•
Transcoding (for a description on the transcoding modes, see ''Transcoding
Modes'' on page
453 )
•
Broken connection
According to the above functionalities, the call can be configured to operate in one of the
following modes:

Media Anchoring without Transcoding (Transparent): RTP traverses the device
with minimal RTP packet changes (no DSP resources needed). This is typically used
to solve NAT, firewall, and security issues. In this mode, all the "audio" coders in the
received offer are included in the SBC outgoing offer. The Coder Table configuration
has no effect on the coders in the outgoing offer. For more information, see ''Media
Anchoring without Transcoding (Transparent)'' on page
451 .