[SR-Users] t_suspend usage in branch_route

[Vasiliy Ganchev]

> In your setup, you have a small Expires, but you still send call after
> the contact has expired?... May be the user don't want the call any
> more...

If user do NOT want to receive push, there are some options:
 - the app sends the new REGISTER without "token" and all other push
specific parameters (such happened if a user on device disable push for a
specific app)
 -  in our implementation, when user make logout from app, REGISTER with
Expires:0 is sent - and I in kamailio recognize it as push "off" as well.

When push is "off" I remove push data for specific instance from htable.


> As far as I know, after my app is terminated and TCP connection closed
> (or broken), there is no impact in the location database? So UDP/TCP/TLS
> should not make any difference for my setup!

We use this option (set it 1):
http://kamailio.org/docs/modules/5.0.x/modules/usrloc#usrloc.p.handle_lost_tcp

so the UDP and TCP/TLS behave differently. By default - yes location will
store all records until Expires hit. 


> I understand your warning about TCP: If I have only on TCP branch and it
> fails
> I guess I will have a fast " I'm terribly sorry, server error occurred
> (7/SL)" answer
> and no time for my "pushed" app to be already registered. However, I think
> I can sort this out with a trick (for example, a static branch to keep my
> stuff
> alive?)

! yes, that is the point, to cope with such case you will need to "reinvent
the wheel". If you get some rational implementation - share it.


> Up to now, the new registration comes before the failure of the broken TCP
> branch.
> Not sure if I'm lucky or if I can count on this ;(

I would not count on this. As:
- you do not control push server, as a result, you cannot predict what is
the time of delivery.
- also, your app may run on different hardware/software, and time from "push
received" until "REISTER sent out" may be quite different. In our tests for
some "slow" devices it took up to 4! seconds.


> Thus... t_suspend and t_continue don't seems to be required at all for me.
> Also, I haven't been able yet to find any advantage to use a different
> htable.

for now - it is OK, but be aware that there is another way.

Just to summarize: 
I am not saying that my way is "true", as I had a lot of headache with push
data /storage/control/clean-up. 
Another issue was to store push data for several devices per one user.
and a lot of others...

Goals that were reached:
- delete from location non alive registration asap => so when new INVITE
comes - send push, and do not have mess with nonalive branches.
- handle correctly case when there is no alive regsitrations (t_suspend)
 --- sub case here: there is only one registration, it is with push. t_relay
failed, as a result I go to suspend logic as well

So, long story short: do it your way.

cheers



--
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html