9 Feb
2018
9 Feb
'18
9:41 a.m.
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_…
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