1 Jul
2010
1 Jul
'10
1:44 p.m.
Hi Nathan,
thank you for the description.
Hi jasmin,
On 06/30/10 07:25, Iñaki Baz Castillo wrote:
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
2010/6/30 Jasmin
Schnatterbeck<js(a)data-cmr.net>et>:
> 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(a)foo.com".com", "0.9")
append_branch ("ua-b(a)bar.com".com", "0.5")
append_branch ("ua-c(a)baz.com".com", "0.2")
You'd just make sure that you *additionally* had:
append_branch ("ua-a(a)foo.com".com", "0.5")
append_branch ("ua-a(a)foo.com".com", "0.2")
append_branch ("ua-b(a)bar.com".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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev