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