Media Handling - AudioCodes E-SBC User Manual

CHAPTER 30 SBC Overview
# clear voip register db sbc user John@10.33.2.22
# clear voip register db sbc user John
■ To delete all registered users belonging to a specific IP Group:
# clear voip register db sbc ip-group <ID or name>

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 multiple media sessions of different types (e.g. audio and
fax). In a SIP dialog, multiple offer-answer transactions may occur and each may change the media
session 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 (e.g., audio, secure audio, video, fax, and 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
Typically, the device does not change the negotiated media capabilities (mainly performed by the
remote user agents). However, it does examine and may take an active role in the SDP offer-
answer mechanism. This is done mainly to anchor the media to the device (default) and also to
change the negotiated media type, if configured. Some of the media handling features, which are
described later in this section, include the following:
■ Media anchoring (default)
■ Direct media
■ Audio coders restrictions
■ Audio coders transcoding
■ RTP-SRTP transcoding
■ DTMF translations
■ Fax translations and detection
■ Early media and ringback tone handling
■ Call hold translations and held tone generation
■ NAT traversal
■ RTP broken connections
■ Media firewall
● 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.
Mediant 1000 Gateway & E-SBC | User's Manual
- 729 -