o Juha Heinanen on 11/21/2011 11:49 PM: 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. yes, sems sends reinvite/update, that fails, and sems closes the call on both sides and removes the entry in the call limit table. 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