[Users] Call Hunting: use Avpop or LCR module ?

[Alexandre Snarskii]

On Thu, Jun 01, 2006 at 01:20:28PM +0300, Daniel-Constantin Mierla wrote:
> 
> 
> On 06/01/06 12:53, Alexandre Snarskii wrote:
> >On Wed, May 31, 2006 at 12:04:41AM +0300, Daniel-Constantin Mierla wrote:
> >  
> >>Hello,
> >>
> >>On 05/30/06 19:47, Rafael J. Risco G.V. wrote:
> >>    
> >>>hi
> >>>I would like to read some opinions to know which method its better to
> >>>implement Call Hunting, using serial forking with 'avpops' or 'lcr'
> >>>module 'load_contacts()/next_contact()' functions, does someone has an
> >>>example of any of these methods?
> >>>      
> >>if it is a global scope you can use any of them, Which is better? 
> >>Depends on your environment and how you organize  your data.
> >>
> >>If is per user, then avpops is more suitable. An example of using avpops 
> >>you can find at:
> >>
> >>http://www.voice-system.ro/docs/avpops/ar01s08.html#ex_serial_forking
> >>    
> >
> >It is suitable, but for some scenarios it require much more complicated
> >config, which is not easy to understand.
> >
> >Scenario: 
> >User A (PSTN side) calls user B (SIP). With avpops we select some numbers 
> >for this user, trying original number (returns 486/BUSY), hunting to next 
> >number (creating new transaction on router).
> it does not create a new transaction, just adds a new branch to it.
> > Phone B2 starts with 
> >100/Trying 180/Ringing, then user A hangs. 
> >CANCEL message first visits original number, which returns 
> >481/Call leg/transaction does not exists [1],
> you mean that sends CANCEL to B1? I do not think so, CANCEL is not sent 
> to completed branches, just to ones that haven't received a final response.
> > then hunts to second
> >number and successfully cancel's call. But, at point [1], first transaction
> >_does not store_ new reply code (modules/tm/t_reply.c, line 762 just logs
> >message 
> >        LOG(L_ERR, "ERROR: t_should_relay_response: status rewrite by UAS: 
> >        "
> >            "stored: %d, received: %d\n",
> >            Trans->uac[branch].last_received, new_code );
> >        goto discard;
> >), and again hunts, so, third number of user B starts ringing... 
> >  
> What version of openser do you use?

ser 0.9.6, freebsd 6.1, database backend is postgresql. 
Did not tried that setup with openser yet. 
Initial question was in ser-users mailing list..

> >The only solution for this which I found yet is: 
> >
> >#The only way to really check return code is to check it in onreply_route,
> >#then set flag which will permit failure_route to hunt this call again.
> >#You can't check status with t_check_status within failure_route, 
> >#because t_check_status in failure_route returns the lowest value 
> >#of all branches.. 
> >onreply_route[1] { 
> >        if(status=~"40[48]" || status=~"486") {
> >                #not-so-fatal response, should hunt 
> >                setflag(2);
> >        };
> >}
> >failure_route[1] { 
> >        if(isflagset(2)) {
> >                resetflag(2);
> >                if(avp_pushto("$ruri","$serial_fork")) { 
> >#and then everytingh should work as in example. 
> >  
> 
> You can use t_was_cancelled() in failure route: 
> http://openser.org/docs/modules/1.1.x/tm.html#AEN479 . It will ensure 
> that you get the proper status of canceled transactions.
> 
> >But, this config is not yet complete - with this configuration 
> >CANCEL's does not hunt after 481 Call leg does not exists, so, 
> >in situation when we need to cancel call on second or third number,
> >we're not able to do that :( 
> >Just adding another code (481) to our list of not-so-fatal response
> >does nothing but returns us to initial problem, and the only 
> >solution found is to complicate configuration again to: 
> >
> >#main post-routing code
> >route[1] { 
> >	if(method=="CANCEL") { 
> >		t_on_reply("2");
> >	} else { 
> >		t_on_reply("1");
> >	};
> >	t_on_failure("1");
> >	t_relay();
> >};
> >
> >onreply_route[1] { #onreply for everyting but CANCEL
> >        if(status=~"40[48]" || status=~"486") {
> >                #not-so-fatal response, should hunt 
> >                setflag(2);
> >        };
> >}
> >onreply_route[2] { #onreply for CANCEL's
> >        if(status=~"481") {
> >                #not-so-fatal response, should hunt 
> >                setflag(2);
> >        };
> >}
> >
> >failure_route[1] { 
> >        if(isflagset(2)) {
> >                resetflag(2);
> >                if(avp_pushto("$ruri","$serial_fork")) { 
> >
> >
> >Please note, that config is in pre-production stage, tested, but
> >without really massive tests. Also, note that this is not complete
> >config, just parts to allow serial hunting without noted problem. 
> >
> >If anyone knows more elegant solution for my problem - please, let
> >me know. Also, if anyone can see a problem with my config - let me
> >know how to test it...
> >  
> 
> Could you try the latest version of OpenSER CVS, it is now in 
> frozen/testing phase, just to be release in a few weeks. Any feedback 
> will help to fix eventual issues. The part with reply code selections 
> and CANCEL processing was refurbished and should have fixed some old issues.
> 
> Cheers,
> Daniel
> 
> 
> >PS: another problem may arise with maximal number of branches. 
> >With default configuration of ser (config.h, #define MAX_BRANCHES 12)
> >maximum number of hunts is limited to 11. If you need more hunts than
> >this - you need to recompile ser. 
> >
> >
> >