AudioCodes Mediant 500L MSBR

User's Manual 520 Document #: LTRT-10466
Mediant 500L MSBR
31.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)
• Broken connection