> 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 _______________________________________________ Kamailio (SER) - Users Mailing List [email protected] https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
