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
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
