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

Daniel-Constantin Mierla daniel at voice-system.ro
Thu Jun 1 13:38:06 CEST 2006



On 06/01/06 14:32, Alexandre Snarskii wrote:
> 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..
>   

it seems that was doubled posted, I answered to users at openser.org and 
overlooked that is for serusers, too.

Cheers,
Daniel


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




More information about the sr-users mailing list