![]() ![]() |
#1
|
|||
|
|||
![]()
Hi,
on SBCE we received an alarm that said:"Max Concurrent Audio Sessions Limit Reached", we validate the licenses and find that we are using all (100%) My question is: ¿1 single call = 2 sessions? --------------------------------- 1 session----------1 session------------------------------------------------------ Movil <-----> Provider <------------> SBCE <--------------> Session Manager <----> SIP Phone thank you |
#2
|
||||
|
||||
![]()
No, one trunk call = one standard session. If there are remote users registered through the SBC-E, their calls use one standard and one advanced session license. Session limits can also be defined in an application rule.
|
#3
|
|||
|
|||
![]()
Thank you mlombardi1. That clarifies our doubt
|
#4
|
|||
|
|||
![]()
Yes, one call through the SBCE equals one Session. However, the real answer is a bit more complicated.
First, a call involving a SIP Remote Worker often counts as two sessions in the SBCE. (If the call comes into the SBCE and gets to Session Manager (on a PSTN trunk or from a Remote Worker) that counts as one session. Then if the call goes back out the SBCE to Remote Worker, it counts as a second Session. Second, I have doubts that the SBCE is actually limiting calls when the license limit is reached. In version 10.1, it might really be enforcing the licensing, but I have strong doubts about versions 8 or older. Third, the Application Rule is what really limits the quantity of concurrent calls. But even that has some issues. For the following discussion, let's assume the Application Rule, called "App-Rule-50", is set to 50 voice sessions. Issue #1: Double-Counting Counter-intuitively, each call through the SBCE is processed through two Flows (Server Flows and/or Subscriber Flows). And each Flow must invoke a Policy Group containing an Application Rule. If the name of the Policy Group is the same in both flows, then the Application Rule counter gets invoked twice and therefore incremented twice. So instead of allowing 50 concurrent calls, the Application Rule would only allow 25 calls. However, if the name of the Policy Group is different in both flows, then the Application Rule is separated into two rules. So, the counter gets invoked once for each rule and thus the SBCE allows 50 concurrent calls. Note that it is the name of the Policy Group that must be different in each Flow. The same Application Rule (i.e. "App-Rule-50") can be used in all Policy Groups. Issue #2: Delay in Tearing Down Calls Conforming to the rules of SIP, the SBCE is slow to remove a terminated call from the Application Counter. The SBCE does not decrement the counter until 32 seconds after it sees the BYE or CANCEL request. So, the Application Rule might block new calls even though there are fewer calls in progress than the limit set in the rule. So, if your goal is to get up to 50 concurrent calls, you might consider setting the Application Rule's limit to 55 calls. The SBCE admin guide has some stupid math to help you figure out what the limit should be. But I strongly suggest you ignore it because I know the idiot that wrote the example did not understand the SBCE when he wrote it. (If you haven't already guessed, I'm the idiot that wrote the example that somehow found its way into the SBCE Admin guide.) Last edited by jwaber; 10-13-2022 at 02:26 PM. |
![]() |
Thread Tools | Search this Thread |
Display Modes | |
|
|