[Serusers] parallel forking best practice?

Vitaly Nikolaev vitaly at voipsonic.com
Wed Feb 23 20:28:13 CET 2005


Hi

I have both working, but I call second thing: step by step routing or follow
me feature :)

That the example:

In route procedure I have:

append_urihf("CC-Diversion: ", "\r\n");
exec_dset("/usr/local/ser/bin/getroute_a_t 1");
t_on_failure("1");

in failure_route[1] I  have:
      if (t_check_status("486")) { 
                xlog("L_INFO", "%ci: BUSY, getroute_a_t 2 busy\n");
                exec_dset("/usr/local/ser/bin/getroute_a_t 2 busy");
        } else if (t_check_status("408")) { 
                xlog("L_INFO", "%ci: Request timeout, getroute_a_t 2
timeout\n");
                exec_dset("/usr/local/ser/bin/getroute_a_t 2 timeout");
        } else if (t_check_status("404")) { 
                xlog("L_INFO", "%ci: Not found, 2 notfound\n");
                exec_dset("/usr/local/ser/bin/getroute_a_t 2 notfound");
        } else if (t_check_status("500")) {
                xlog("L_INFO", "%ci: Not found, 2 disconnected\n");
                exec_dset("/usr/local/ser/bin/getroute_a_t 2 disconnected");
        } else{
                xlog("L_INFO", "%ci: Other. getroute_a_t 2 other\n");
                exec_dset("/usr/local/ser/bin/getroute_a_t 2 other");
        }

        append_branch();
        t_on_failure("2");


I execute getroute_a_t with parametr 2 that means second step and disconnect
couse to distinct busy from other resons and make customer choose to forward
call if busy, if no answer if something else


In failure_route[2] I have:

        exec_dset("/usr/local/ser/bin/getroute_a_t 3 other");
        append_branch();
        t_on_failure("3");

and so on until 5 :)

 
on any step getroute can return few URI and it working for me (it send call
to different destinations)

There will be problem if durint parallel forking u havce device behind NAT
and not... but could be avoided by having all clients working thru rtpproxy
(I do not do it yet but thinking)





-----Original Message-----
From: Jev [mailto:jev at ecad.org] 
Sent: Wednesday, February 23, 2005 1:17 PM
To: Vitaly Nikolaev
Cc: serusers at lists.iptel.org
Subject: Re: [Serusers] parallel forking best practice?

Hi Vitaly,

Thank you for your reply,

But do you have parallel forking working this way? So two or more phones 
ring at once. As opposed to one phone ringing for N seconds, and then 
another ringing (sequential forking).

Is it possible to do parallel forking with exec_dset()? I did not think 
that it was.


Thanks,
-Jev

Vitaly Nikolaev wrote:
> Hi,
> 
> I do not know that it is best, I even sure that it is not :) but it very
> useful and very flexible to execute external application that will return
> list of URI.
> 
> Why it flexible - because you can do, for example, balancing of whatever
you
> use for termination all (in my case b2bua) plus I use nagios that testing
my
> b2buas/gws/voicemails and then my "routing" script uses this info to avoid
> bad destinations
> 
> Plus different features like, call return, redial, call forward, step by
> step routing (like first call ring on your SIP device, if it fail it ring
on
> your office phone and if it fail goes to your cell phone and same time to
> your gf cell phone :)) My script taking all this info from MSSQL database,
> of course it add some delay to your call (PDD) but that the price, you can
> always use few boxes with this setup in parallel (replicate) and do
> redundant SQL server for fast answer
> 
> 
> 
> 
> 
> 
> -----Original Message-----
> From: serusers-bounces at iptel.org [mailto:serusers-bounces at lists.iptel.org] On
> Behalf Of Jev
> Sent: Wednesday, February 23, 2005 11:01 AM
> To: serusers at lists.iptel.org
> Subject: [Serusers] parallel forking best practice?
> 
> Hi All,
> 
> For the 0_9_0 branch, what is the 'best practice' for implementing 
> parallel forking?
> 
> We used to be able to point one alias at several accounts, but that 
> feature has regressed.
> 
> 
> Thanks,
> -Jev
> 
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
> 
> 




More information about the sr-users mailing list