Hello list,
for a few weeks now I am thinking about the idea of something like "delayed branches".
For example if one INVITE lookup results in 2 contacts/branches, then the first branch should be executed directly but the second should experience a delay of some seconds, until the INVITE is being sent out to the 2nd contact.
Such a feature would be really useful for users, if they would like to configure their delayed redirects server-side and not client-side (devices).
I have some doubts, whether it's reasonable in general, if a sip proxy behaves like this (delays requests...) - what do you think?
Best Regards Jasmin
Jasmin Schnatterbeck writes:
For example if one INVITE lookup results in 2 contacts/branches, then the first branch should be executed directly but the second should experience a delay of some seconds, until the INVITE is being sent out to the 2nd contact.
you can do this using serial forking if there is a sleep() function (i don't remember if such exists).
-- juha
Hi Juha,
thanks for your response
There is such a sleep function:
http://kamailio.org/docs/modules/3.0.x/modules_k/cfgutils.html#id2753004
"The module provides as well functions to delay the execution of the server. The functions “sleep” and “usleep” could be used to let the server wait a specific time interval."
Hmm...letting the whole server sleep would not really be the idea ;-)
Do you know of other functions like this?
Best Regards Jasmin
Jasmin Schnatterbeck writes:
For example if one INVITE lookup results in 2 contacts/branches, then the first branch should be executed directly but the second should experience a delay of some seconds, until the INVITE is being sent out to the 2nd contact.
you can do this using serial forking if there is a sleep() function (i don't remember if such exists).
-- juha
Am 30.06.2010 15:25, schrieb Juha Heinanen:
Jasmin Schnatterbeck writes:
Hmm...letting the whole server sleep would not really be the idea ;-)
i don't think that the whole server will get to sleep, but just the process handling the request at hand.
So if 4 user have delayed calling, 4 processes are sleeping, thats not good.
Klaus Darilion writes:
Hmm...letting the whole server sleep would not really be the idea ;-)
i don't think that the whole server will get to sleep, but just the process handling the request at hand.
So if 4 user have delayed calling, 4 processes are sleeping, thats not good.
it is not good, but such "sleeps" can happen also when an ua is not responding immediately, when you do an http query, etc.
unfortunately a function execute_next_function_asynchronously() does not exit.
-- juha
Hi,
What is the goal of a "delayed branch"? What you can do (and could do for many versions now) is the serial forking together with a defined timeout of some seconds for each branch... (e.g. first try location 1 for a few seconds, then try location 2 for few seconds, ...).
Carsten
2010/6/30 Juha Heinanen jh@tutpro.com
Klaus Darilion writes:
Hmm...letting the whole server sleep would not really be the idea ;-)
i don't think that the whole server will get to sleep, but just the process handling the request at hand.
So if 4 user have delayed calling, 4 processes are sleeping, thats not good.
it is not good, but such "sleeps" can happen also when an ua is not responding immediately, when you do an http query, etc.
unfortunately a function execute_next_function_asynchronously() does not exit.
-- juha
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hi,
the idea is to do parallel forking (not wait for reply or timeout), but wait (for each branch) a specific amount of seconds, before sending out the INVITE request to the contact.
This could be useful, if a user - has a mailbox <somewhere>, which answers the call without waiting (like many cell phone providers' mailboxes do, if a call gets forwarded to them) - would like to predefine multiple destinations, for example tel. exchange and users phone, but the users phone should only ring _additionally_ , if the call was not answered for <x> seconds by the tel. exchange. - ...
there are many use cases, but a function would be needed, which delays further script processing for specific branches only or (that could be the better solution) the definition of a special branch-individual avp which holds the seconds to wait and which is evaluated by tm.
Jasmin
Hi,
What is the goal of a "delayed branch"? What you can do (and could do for many versions now) is the serial forking together with a defined timeout of some seconds for each branch... (e.g. first try location 1 for a few seconds, then try location 2 for few seconds, ...).
Carsten
2010/6/30 Juha Heinanen jh@tutpro.com Klaus Darilion writes:
> >> Hmm...letting the whole server sleep would not really be the idea ;-) > > > > i don't think that the whole server will get to sleep, but just the > > process handling the request at hand. > > So if 4 user have delayed calling, 4 processes are sleeping, thats not > good. it is not good, but such "sleeps" can happen also when an ua is not responding immediately, when you do an http query, etc. unfortunately a function execute_next_function_asynchronously() does not exit. -- juha _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev-- Carsten Bock Schomburgstr. 80 22767 Hamburg Germany
Mobile +49 179 2021244 Home +49 40 34927217 Fax +49 40 34927218 mailto:carsten@bock.info
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Jasmin Schnatterbeck wrote:
Hi,
the idea is to do parallel forking (not wait for reply or timeout), but wait (for each branch) a specific amount of seconds, before sending out the INVITE request to the contact.
This could be useful, if a user
- has a mailbox <somewhere>, which answers the call without waiting
(like many cell phone providers' mailboxes do, if a call gets forwarded to them)
- would like to predefine multiple destinations, for example tel.
exchange and users phone, but the users phone should only ring _additionally_ , if the call was not answered for <x> seconds by the tel. exchange.
- ...
there are many use cases, but a function would be needed, which delays further script processing for specific branches only or (that could be the better solution) the definition of a special branch-individual avp which holds the seconds to wait and which is evaluated by tm.
Jasmin
Hello
Have you checked TM's t_suspend() and t_continue() [1]? ATM, they are only usable internally from modules, but I think they can provide the building blocks for what you want.
[1] http://kamailio.org/docs/modules/stable/modules/tm.html#t_suspend
Marius
Hi,
What is the goal of a "delayed branch"? What you can do (and could do for many versions now) is the serial forking together with a defined timeout of some seconds for each branch... (e.g. first try location 1 for a few seconds, then try location 2 for few seconds, ...).
Carsten
2010/6/30 Juha Heinanen jh@tutpro.com Klaus Darilion writes:
> >> Hmm...letting the whole server sleep would not really be the idea ;-) > > > > i don't think that the whole server will get to sleep, but just the > > process handling the request at hand. > > So if 4 user have delayed calling, 4 processes are sleeping, thats not > good. it is not good, but such "sleeps" can happen also when an ua is not responding immediately, when you do an http query, etc. unfortunately a function execute_next_function_asynchronously() does not exit. -- juha _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev-- Carsten Bock Schomburgstr. 80 22767 Hamburg Germany
Mobile +49 179 2021244 Home +49 40 34927217 Fax +49 40 34927218 mailto:carsten@bock.info
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
2010/6/30 Jasmin Schnatterbeck js@data-cmr.net:
Hi,
the idea is to do parallel forking (not wait for reply or timeout), but wait (for each branch) a specific amount of seconds, before sending out the INVITE request to the contact.
This could be useful, if a user
- has a mailbox <somewhere>, which answers the call without waiting
(like many cell phone providers' mailboxes do, if a call gets forwarded to them)
- would like to predefine multiple destinations, for example tel.
exchange and users phone, but the users phone should only ring _additionally_ , if the call was not answered for <x> seconds by the tel. exchange.
- ...
there are many use cases, but a function would be needed, which delays further script processing for specific branches only or (that could be the better solution) the definition of a special branch-individual avp which holds the seconds to wait and which is evaluated by tm.
I cannot understand why you don't use the very usual and common serial forking for such purpose. Any reason?
Hi,
with serial/parallel forking you can process contacts based on timeouts or receiving a reply via onreply or onfailure route.
As I understand it, it is not possible to trigger the processing of "next" contacts (according to the q-value) by a timer only - that means to trigger next contacts delayed while the higher-priority-contacts are still ringing (onreply route would be called directly after receiving a reply)...
Jasmin
2010/6/30 Jasmin Schnatterbeck js@data-cmr.net:
Hi,
the idea is to do parallel forking (not wait for reply or timeout), but wait (for each branch) a specific amount of seconds, before sending out the INVITE request to the contact.
This could be useful, if a user
- has a mailbox <somewhere>, which answers the call without waiting
(like many cell phone providers' mailboxes do, if a call gets forwarded to them)
- would like to predefine multiple destinations, for example tel.
exchange and users phone, but the users phone should only ring _additionally_ , if the call was not answered for <x> seconds by the tel. exchange.
- ...
there are many use cases, but a function would be needed, which delays further script processing for specific branches only or (that could be the better solution) the definition of a special branch-individual avp which holds the seconds to wait and which is evaluated by tm.
I cannot understand why you don't use the very usual and common serial forking for such purpose. Any reason?
Hi jasmin,
On 06/30/10 07:25, Iñaki Baz Castillo wrote:
2010/6/30 Jasmin Schnatterbeckjs@data-cmr.net:
Hi,
the idea is to do parallel forking (not wait for reply or timeout), but wait (for each branch) a specific amount of seconds, before sending out the INVITE request to the contact.
if I understand you correctly,
You have 3 contacts: UA-A, UA-B, UA-C
You want:
INVITE to UA-A [no response then] INVITE UA-A *and* UA-B [no response then] INVITE UA-A *and* UA-B *and* UA-C So its a serial set of parallel forks?
In that case, its just a case of loading up your branches correctly.
I am not an expert, and my experience is with kamailio 1.5, but it seems that from your initial contact lookup you should have 3 contacts with different q values.
For example, if we were building it by hand, it might be:
append_branch ("ua-a@foo.com", "0.9") append_branch ("ua-b@bar.com", "0.5") append_branch ("ua-c@baz.com", "0.2")
You'd just make sure that you *additionally* had: append_branch ("ua-a@foo.com", "0.5")
append_branch ("ua-a@foo.com", "0.2") append_branch ("ua-b@bar.com", "0.2")
When you do the t_load_contacts, it would sort all the branches into 3 sets (0.9, 0.5, 0.2), with increasing numbers of contacts (a, a+b, a+b+c)
your failure route just re-arms itself and loads the next group of contacts: failure_route[1] {
t_on_failure("1"); if (t_next_contacts()) { t_relay(); }
2010/6/30 Nathan Angelacos nangelacos@genericconf.com:
I am not an expert, and my experience is with kamailio 1.5, but it seems that from your initial contact lookup you should have 3 contacts with different q values.
For example, if we were building it by hand, it might be:
append_branch ("ua-a@foo.com", "0.9") append_branch ("ua-b@bar.com", "0.5") append_branch ("ua-c@baz.com", "0.2")
You'd just make sure that you *additionally* had: append_branch ("ua-a@foo.com", "0.5")
append_branch ("ua-a@foo.com", "0.2") append_branch ("ua-b@bar.com", "0.2")
When you do the t_load_contacts, it would sort all the branches into 3 sets (0.9, 0.5, 0.2), with increasing numbers of contacts (a, a+b, a+b+c)
your failure route just re-arms itself and loads the next group of contacts: failure_route[1] { t_on_failure("1"); if (t_next_contacts()) { t_relay();
It would be a bit ugly as the proxy would generate 3 consecutive calls to UA-A (3 missed calls in UA-A) and two to UA-B.
Isn't there something like route_timer in 3.X? In this way a timer could be armed for the first branch so the second would be generated and so on.
Hi Nathan,
thank you for the description.
Hi jasmin,
On 06/30/10 07:25, Iñaki Baz Castillo wrote:
2010/6/30 Jasmin Schnatterbeckjs@data-cmr.net:
Hi,
the idea is to do parallel forking (not wait for reply or timeout), but wait (for each branch) a specific amount of seconds, before sending out the INVITE request to the contact.
if I understand you correctly,
You have 3 contacts: UA-A, UA-B, UA-C
You want:
INVITE to UA-A [no response then] INVITE UA-A *and* UA-B [no response then] INVITE UA-A *and* UA-B *and* UA-C
in this case it would be possible to realize it with serial/parallel forks - as you have stated.
But in the case I am thinking of, UA-B and UA-C do not have to wait for a timeout of UA-A. They are completely independent and have separate timers, which trigger their INVITEs...
Jasmin
So its a serial set of parallel forks?
In that case, its just a case of loading up your branches correctly.
I am not an expert, and my experience is with kamailio 1.5, but it seems that from your initial contact lookup you should have 3 contacts with different q values.
For example, if we were building it by hand, it might be:
append_branch ("ua-a@foo.com", "0.9") append_branch ("ua-b@bar.com", "0.5") append_branch ("ua-c@baz.com", "0.2")
You'd just make sure that you *additionally* had: append_branch ("ua-a@foo.com", "0.5")
append_branch ("ua-a@foo.com", "0.2") append_branch ("ua-b@bar.com", "0.2")
When you do the t_load_contacts, it would sort all the branches into 3 sets (0.9, 0.5, 0.2), with increasing numbers of contacts (a, a+b, a+b+c)
your failure route just re-arms itself and loads the next group of contacts: failure_route[1] {
t_on_failure("1"); if (t_next_contacts()) { t_relay(); }
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
2010/7/1 Jasmin Schnatterbeck js@data-cmr.net:
Hi Nathan,
thank you for the description. But in the case I am thinking of, UA-B and UA-C do not have to wait for a timeout of UA-A. They are completely independent and have separate timers, which trigger their INVITEs...
Look for route_event in Kamailio/SR 3.X. Perhaps it's possible.
On Wednesday 30 June 2010, Klaus Darilion wrote:
Am 30.06.2010 15:25, schrieb Juha Heinanen:
Jasmin Schnatterbeck writes:
Hmm...letting the whole server sleep would not really be the idea ;-)
i don't think that the whole server will get to sleep, but just the process handling the request at hand.
So if 4 user have delayed calling, 4 processes are sleeping, thats not good.
Hi Klaus,
indeed, it will block this specific process for other requests. So at the moment i think its mainly useful with small timeouts and probably for debugging.
Cheers,
Henning
Just to be sure what you want: You want to start another branch, but keep the original branch still alive - thus a mixture of parallel and sequential forking (I would call it delayed parallel forking).
Nice idea. I think there are currently no means to accomplish that.
regards Klaus
Am 30.06.2010 14:34, schrieb Jasmin Schnatterbeck:
Hello list,
for a few weeks now I am thinking about the idea of something like "delayed branches".
For example if one INVITE lookup results in 2 contacts/branches, then the first branch should be executed directly but the second should experience a delay of some seconds, until the INVITE is being sent out to the 2nd contact.
Such a feature would be really useful for users, if they would like to configure their delayed redirects server-side and not client-side (devices).
I have some doubts, whether it's reasonable in general, if a sip proxy behaves like this (delays requests...) - what do you think?
Best Regards Jasmin
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-
Carsten Bock -
Henning Westerholt -
Iñaki Baz Castillo -
Jasmin Schnatterbeck -
Juha Heinanen -
Klaus Darilion -
marius zbihlei -
Nathan Angelacos