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

[Daniel-Constantin Mierla]

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?

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