> 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
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
- 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):
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
> 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
! 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
> 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
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
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.
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
Kamailio (SER) - Users Mailing List