[SR-Users] t_suspend usage in branch_route

[Aymeric Moizard]

Hi!

Tks for all the comments and descriptions.
I've seen the pdf ideas and followed most guidelines.
I've also tried to follow most guidelines from
https://www.ietf.org/id/draft-ietf-sipcore-sip-push-04.txt.

My approach is first to use a long expires ;)
This was to avoid storing the push information in a different table
as everything is available in the "location" database already.

As I described, my goal was to discard forwarding to branches
which has push information in them. However, this is not
mandatory for me: if the UA is reachable, it will receive the
INVITE and the push. If the UA is not reachable any more (on SIP)
it will just receive the push.

This is working well enough for my needs.

In my initial experiments, I have tried to use a avops with a preference
table. But I'm not sure if that database could support many entries for
the same users. And I was worried about automatic management of
the expiration of this entry. The "location" database already have
expiration
management and already contains the tokens...

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...

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!

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?)

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 ;(

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.


Tks
Aymeric


2018-02-09 10:00 GMT+01:00 Vasiliy Ganchev <vancecezar at gmail.com>:

> I am glad that you have something working, but I think you will have some
> issues with your approach.
>
> Some important point regarding push/suspending etc. that I would like to
> emphasize and point your attention:
>
> 1.The modern mobile devices - put your SIP app to "sleep" quite fast. The
> TCP/TLS connection is closed. (are you using UDP?)
>
> 2. So if your location prevents non-alive registrations to live there you
> possibly need:
>   - have a long "Expires" in registration. (remember your app is
> sleeping/killed most of the time, and is unable to refresh the
> registration)
>
> 3. When your location has "non alive registration", after t_relay - INVITE
> will be forked to all branches (including that "non alive"). How can you
> know that the registration is alive?
>  - a possible case - is to send push for every call, without paying
> attention on "aliveness" of the registration
>  Drawback: your app will have to handle case when SIP INVITE and push
> arrive
> at the same time (usually it will by firstly SIP, and in few seconds push)
>
> So my approach to push in kamailio:
> 1. use short "Expires", (300s) - to remove non-refreshed registration from
> location asap.
>
> 2. store all the necessary push data to "htable".  (while REGISTER
> processing)
>    (actually I have 2 tables:
>      a) extension as a key, and list of instances as a value
>      b) instance as a key, and all parameters as a value (here is token,
> type, version etc.)
>
> 3. When INVITE comes
>  a) make lookup(location)
>  b) check if there is something found in location (remember you may have no
> registrations, but there still may be devices that support push and can be
> reachable)
>   b1) NO records in location - t_suspend and push send
>   b2) ts_store and relay to alive branches. When REGISTER from push device
> comes - ts_append
>
> So  the answer to your initial question - ts_suspend is never done in
> branch_route, as we get there only if there are valid registrations (and
> there is no suspend needed)
>
> Hope my insight helped. Good luck in your pushing.
>
> and of course most of the text above is not my invention, but it is based
> on
> Daniel/Federico's job. Their presentations are what was my insight when I
> developed push in our solution:
> http://www.kamailio.org/events/2014-KamailioWorld/
> day2/26-Daniel-Constantin.Mierla-Kamailio.cfg-Async.pdf
> http://www.kamailio.org/events/2015-KamailioWorld/
> Day2/20-Federico.Cabiddu-Kamailio-In-A-Mobile-World.pdf
>
> cheers!
>
>
>
> --
> Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>



-- 
Antisip - http://www.antisip.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20180209/e4489c26/attachment-0001.html>