[SR-Users] Limiting simultaneous calls

[Stefan Sayer]

o Juha Heinanen on 11/21/2011 11:49 PM:
> Stefan Sayer writes:
>
>> if it's acceptable for you to use an external B2BUA, you could send
>> the calls through SEMS' sbc, activating session timers there and using
>> parallel calls cc_pcalls to limit.
>
> what if parties of the call do not support session timers and do not
> (for one reason or another) send byes to terminate the call?  can your
don't confuse support for SIP session timers with doing the actual 
refresh.

if both endpoints do support session timers, then they will according 
to the algorithmus in SST negotiate the refresh timer value and who is 
going to have the refresher role.

if only one endpoint supports SST, that one is always going to be the 
one who is taking on the refresher role.

so, if the endpoints on either leg don't support SST, then it's always 
SEMS who is doing the refresh on that leg, if it hasn't been refreshed 
before (e.g. by an end-to-end refresh from the other side).

Any endpoint could do session refresh (reinvite, update) any time it 
wants to. SST support just help to prevent that both endpoint do the 
refresh, because by negotiating it, both know who is doing it, and at 
what interval. The other can then drop the call when session expired.

What you can do in a call stateful proxy is to enforce that SST are 
used, and also enforce maximum timer values. The problem with forcing 
SST in the proxy is of course that the call will fail of none of the 
endpoints supports SST. You can then also use the timer value to e.g. 
reset your concurrent call limit; if no refresh came up to that point, 
you know that the call is dead anyway (but you don't know whether 
clever endpoints are trying to trick your proxy).

What you exactly can't do in a call stateful proxy - as opposed to a 
b2bua - is to make all this work if both parties don't support SST.

> example configuration still detect that the parties have gone away
> (assuming that only signaling goes through sems)?
yes, sems sends reinvite/update, that fails, and sems closes the call 
on both sides and removes the entry in the call limit table.

>
> limit_calls_sst.sbcprofile.conf:
>    call_control=parallel_calls
>    parallel_calls_module=cc_pcalls
>    parallel_calls_uuid=$fU
>    parallel_calls_max_calls=1
>    # enable session timers - will refresh
>    # even if endpoint doesnt support it
>    enable_session_timer=yes
>    # refresh every minute
>    session_expires=120
>
> if not, i guess one needs to replace enable_session_timer with call
> call_timer_timer.  if so, how expensive are call_timer_timers from
> implementation point of view?
if you additionally want to set an absolute maximum call timer, you 
can also do that with the call_timer call control module.
  call_control=parallel_calls,call_timer
  call_timer_module=call_timer
  call_timer_timer=3600
  parallel_calls_module=...

call_timer are not very expensive - it's one (long time) timer per 
call (compared to SST where it's two timers if SEMS is refresher, 
otherwise one).

Stefan

>
> -- juha
>