[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