AudioCodes Mediant 500 E-SBC, User Manual

Page: 473 / 920

User's Manual 28. SBC Configuration
Version 6.8 473 Mediant 500 E-SBC
sip:cjones@example.net
</identity>
<target uri="sip:line3@host3.example.net">
<param pname="actor" pval="attendant"/>
<param pname="automaton" pval="false"/>
</target>
</remote>
</dialog>
</dialog-info>
28.2 Configuring Admission Control
The Admission Control table lets you configure up to 100 Call Admission Control rules
(CAC). CAC rules define the maximum number of concurrent calls (SIP dialogs) permitted
per IP Group or SRD, and per user (identified by its registered contact) belonging to these
entities. CAC rules also define a guaranteed (
reserved ) number of concurrent calls. Thus,
CAC rules can be useful for implementing Service Level Agreements (SLA) policies.
CAC rules can be applied per SIP request type and SIP dialog direction (inbound and/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 INVITE, REGISTER, and/or SUBSCRIBE messages, or it can be configured to
include the total number of all dialogs.
This feature also provides support for SIP-dialog rate control, 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. Thus, a flow can setup 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.

If there are no tokens, the request is dropped.

New tokens are added to the bucket at a user-defined rate (token rate).

If the bucket contains the maximum number of tokens, tokens to be added at that
moment are dropped.
Reserved capacity is especially useful when the device operates with multiple SIP entities
such as in a contact center environment handling multiple customers. For example, if the
total call capacity of the device is 200 call sessions, a scenario may arise where one SIP
entity may reach the maximum configured call capacity of 200 and thereby, leaving no
available call resources for the other SIP entities. Thus, reserved capacity guarantees a
minimum capacity for each SIP entity. If the reserved call capacity of a SIP entity is
threatened by a new call for a different SIP entity, the device rejects the call to safeguard
the reserved capacity.
Reserved call capacity can be configured for both an SRD and each of its associated IP
Groups. In such a setup, the SRD's reserved call capacity must be greater or equal to the
summation of the reserved call capacity of all these IP Groups. In other words, the SRD
serves as the "parent" reserved call capacity. If the SRD's reserved call capacity is greater,
the extra call capacity can be used as a shared pool between the IP Groups for unreserved
calls when they exceed their reserved capacity. For example, assume that the reserved
capacities for an SRD and its associated IP Groups are as follows:

SRD reserved call capacity: 40

IP Group ID 1 reserved call capacity: 10

IP Group ID 2 reserved call capacity: 20