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.

-- juha

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,

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

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

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

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