8 Feb
2018
8 Feb
'18
4:09 p.m.
Hi,
I'm trying to use t_suspend in my kamailio.cfg from a branch_route.
I'm using kamailio 5.1.1 on debian jessie from
http://deb.kamailio.org/kamailio51
From the documentation:
http://www.kamailio.org/docs/modules/5.1.x/modules/tmx.html#tmx.f.t_suspend
i can see that "This function can be used from ANY_ROUTE ."
However, the INVITE is still forwarded for this branch. So obviously the
"outgoing transaction" is not suspended.
May be "t_suspend" is only suspending "incoming transactions"?
I tried to call "drop()". This prevent the INVITE from being sent. But in
such case, i have an answer
is sent immediatly to the caller (SIP/2.0 500 I'm terribly sorry, server
error occurred (6/SL))
I want the script to wait as expected after my "t_suspend". And in the
block indicated by t_continue,
i want to append a new branch.
Any way to do this?
Otherwise, do you advise me to control the list of branch before t_relay? I
guess I can access
the list. Not sure how.. so if you have any tips...
Tks
Aymeric
--
Antisip - http://www.antisip.com
8 Feb
8 Feb
4:25 p.m.
Hi!
I am not sure that t_suspend is expected to work from branch_route.
Why not suspend it from the main route?
Describe in more details what are you going to achieve with the suspend.
cheers
--
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
5:04 p.m.
2018-02-08 16:25 GMT+01:00 Vasiliy Ganchev <vancecezar(a)gmail.com>om>:
Hi!
Tks for answering!
I am not sure that t_suspend is expected to work from
branch_route.
Why not suspend it from the main route?
Describe in more details what are you going to achieve with the suspend.
Objective:
I'm working on implementing a configuration to support push notification
for mobile devices.
Those devices are sending REGISTER with push information inside the
URI-PARAMS of
the Contact header.
My way to acheive it:
I have a "location" database containing many "Contact" headers for a
UA.
Some of those destinations don't have the "push" informations and I want
to forward
the INVITE to them.
Some of those destinations has "push" information in the URI: such as
pn-provider, pn-param, pn-prid.
I consider those UA as not available and don't want to forward the INVITE
to them. In the
branch route, I have this code:
branch_route[MANAGE_BRANCH]
{
if (!strempty($(ru{uri.param,pn-provider})) &&
!strempty($(ru{uri.param,pn-param})) &&
!strempty($(ru{uri.param,pn-prid}))) {
if ($(ru{uri.param,pn-provider}) == "fcm" &&
$(ru{uri.param,pn-param})
== "xxxxxxxxx") {
route(SENDPUSH);
}
}
route(INVITETOFORWARD);
}
It's very easy to check for each branch the URI parameters of $ru. So I can
send a PUSH NOTIFICATION to every
one of them.
Tks!
Aymeric
cheers
--
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Antisip - http://www.antisip.com
11:33 p.m.
Hi,
I ended up using ts_store and ts_append as this seems to be more convenient.
I guess t_suspend was not built to support what I tried. May be the
documentation
should be changed to indicate that it should be used only in request route
block
(and may be reply route block), but not in branch.
I was able to loop over the destination URI in the request route block
after my lookup
by using $ru for the main branch, and $(branch(uri)[$var(i)] for all the
others.
It worked perfectly!
Tks,
Aymeric
www.antisip.com
2018-02-08 17:04 GMT+01:00 Aymeric Moizard <amoizard(a)gmail.com>om>:
2018-02-08 16:25 GMT+01:00 Vasiliy Ganchev <vancecezar(a)gmail.com>om>:
--
Antisip - http://www.antisip.com
Hi!
Tks for answering!
I am not sure that t_suspend is expected to work
from branch_route.
Why not suspend it from the main route?
Describe in more details what are you going to achieve with the suspend.
Objective:
I'm working on implementing a configuration to support push notification
for mobile devices.
Those devices are sending REGISTER with push information inside the
URI-PARAMS of
the Contact header.
My way to acheive it:
I have a "location" database containing many "Contact" headers for a
UA.
Some of those destinations don't have the "push" informations and I want
to forward
the INVITE to them.
Some of those destinations has "push" information in the URI: such as
pn-provider, pn-param, pn-prid.
I consider those UA as not available and don't want to forward the INVITE
to them. In the
branch route, I have this code:
branch_route[MANAGE_BRANCH]
{
if (!strempty($(ru{uri.param,pn-provider})) &&
!strempty($(ru{uri.param,pn-param})) && !strempty($(ru{uri.param,pn-prid})))
{
if ($(ru{uri.param,pn-provider}) == "fcm" &&
$(ru{uri.param,pn-param})
== "xxxxxxxxx") {
route(SENDPUSH);
}
}
route(INVITETOFORWARD);
}
It's very easy to check for each branch the URI parameters of $ru. So I
can send a PUSH NOTIFICATION to every
one of them.
Tks!
Aymeric
cheers
--
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Antisip - http://www.antisip.com
9 Feb
9 Feb
10 a.m.
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…
http://www.kamailio.org/events/2015-KamailioWorld/Day2/20-Federico.Cabiddu-…
cheers!
--
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
1:49 p.m.
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(a)gmail.com>om>:
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(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Antisip - http://www.antisip.com
3:41 p.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
5:54 p.m.
2018-02-09 15:41 GMT+01:00 Vasiliy Ganchev <vancecezar(a)gmail.com>om>:
Good point for me! So i'll keep away from this option. ;)
If you get some rational implementation - share it.
it's a good trick. If I wish to have a clean control: I "append_branch" to
a UDP localhost.
I could plug an app that will reply 110 Called is Parked and after a some
controlled time
send 408 Timeout.
t_suspend and t_continue seems similar, but I don't see the ability to
configure timeout
for example.
> 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.
;)
Tks for sharing.
Aymeric
> cheers
> --
> Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html
>
_______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users(a)lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
Antisip - http://www.antisip.com
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". 
8:31 p.m.
Aymeric Moizard wrote on 09.02.2018 13:49:
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
usrloc's handle_lost_tcp is a good tip. we're using these in a push
notification config for webrtc [0]:
set_forward_no_connect();
t_set_disable_internal_reply(1);
and then if t_relay() fails ts_store and t_suspend the transaction
which I believe works.
Stefan
[0]
https://github.com/saycel/kamailio-config/blob/fc17b58369af5a487d131dd67ac3…
11:14 p.m.
Hi Stephan!
Nice to year about you ;)
I have just tried:
set_forward_no_connect()
t_set_disable_internal_reply(1)
I wasn't aware that the code located
after the t_relay failure would run after
the branch failure.
Great to know about this.
I will experiment t_suspend and t_continue
in this use-case!
Tks a lot for the tip!
Aymeric
2018-02-09 20:31 GMT+01:00 Stefan Sayer <stefan.sayer(a)googlemail.com>om>:
Aymeric Moizard wrote on 09.02.2018 13:49:
--
Antisip - http://www.antisip.com
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
usrloc's handle_lost_tcp is a good tip. we're using these in a push
notification config for webrtc [0]:
set_forward_no_connect();
t_set_disable_internal_reply(1);
and then if t_relay() fails ts_store and t_suspend the transaction
which I believe works.
Stefan
[0]
https://github.com/saycel/kamailio-config/blob/
fc17b58369af5a487d131dd67ac3c6a8628d1b29/kamailio.cfg#L695
2291
days inactive
2292
days old
9 comments
3 participants
participants (3)
-
Aymeric Moizard -
Stefan Sayer -
Vasiliy Ganchev