SIP User's Manual 502 Document #: LTRT-12804
Mediant 800 MSBG
If two SBC legs (after offer\answer negotiation) use different security types (i.e., one RTP
and the other SRTP), then the device performs RTP-SRTP transcoding.
To transcode between RTP and SRTP, the following prerequisites must be met:
At least one supported SDP "crypto" attribute and parameters
EnableMediaSecurity must be set to 1
If one of the above transcoding prerequisites is not met:
Any value other than “As is” is discarded.
If the incoming offer is SRTP, force transcoding, coder transcoding, and DTMF
extensions are not applied.
Transcoding between RTP and SRTP does not require any DSP allocation. SRTP to SRTP
does not require DSP allocation.
8.4.5.8 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.
8.4.6 SIP Dialog Admission Control
The device allows you to limit the number of concurrent calls (SIP dialogs). These call
limits can be applied per SRD and/or IP Group, and per user (identified by its registered
contact). This is especially important for MSBG applications where VoIP and Data traffic
contend on the WAN throughput, which may be limited by itself. For example, DSL WAN
access interface is very limited in the uplink. Therefore, by controlling the number of calls
allowed, bandwidth can be reserved for Data applications. In addition, this feature can be
useful for implementing Service Level Agreements (SLA) policies.
The SIP dialog limits can be defined per SIP request type and direction (inbound or
outbound). These relate to requests that initiate SIP dialogs and not the subsequent
requests that can be of different type and direction. The SIP dialog-initiating request types
can include SIP INVITEs, REGISTER, and/or SUBSCRIBE, or it can be configured to
include all dialogs. Requests that supersede the defined limit are rejected with a SIP 486
"Busy Here" response.
SIP-dialog rate control can also be configured using the “token bucket” mechanism. The
token bucket is a control mechanism that dictates the rate of SIP-dialog setups based on
the presence of tokens in the bucket – a logical container that holds aggregate SIP dialogs
to be accepted or transmitted. Tokens in the bucket are removed ("cashed in") for the
ability to setup a dialog. Therefore, a flow can set up dialogs up to its peak burst rate if
there are adequate tokens in the bucket and if the burst threshold is configured
appropriately:
Every SIP dialog setup request must attempt to take a token from the bucket.
To Next Page
Loading...
