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

[Alexandre Snarskii]

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). 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], 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... 

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. 

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...

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.