[OpenSER-Devel] discussion: issues with local_route

[Daniel-Constantin Mierla]

Hello,

On 06/12/08 11:14, Iñaki Baz Castillo wrote:
> El Thursday 12 June 2008 09:59:56 Daniel-Constantin Mierla escribió:
>   
>>> In this example I hope "A" is executed for INVITE (as normal) while "B"
>>> is not executed for the dummped MESSAGE since I expect the flag(3) was
>>> just enabled for the INVITE. Is it?
>>>  
>>>       
>> In your example, neither A or B is not executed.
>>
>> Here is the problem. Script flag 3 is set for the environment of INVITE,
>> local_route is executed, and being a top route, for a new SIP request
>> (the MESSAGE sent by m_dump) the script flags are reset to 0. The
>> condition for B is not met, when returning to 'route' scripts flags are
>> 0, so condition for A is not met as well.
>>
>> In my example, if you set a flag in local_route, that flag will be set
>> in 'route' after the call of m_dump.
>>     
>
> Ok, I understand the problem. And what about Message flags?
>
>
> route {
>    setflag(3);
>    if(method=="INVITE")
>        m_dump();
>    if(isflagset(3))
>    {
>          # Is it executed for the incoming INVITE?      <-- A
>    } 
> }
>
>
> local_route {
>    if(isflagset(3))
>    {
>          # Is it executed for the dummped MESSAGE?  <-- B
>    } 
> }
>
>
> In this case (using message flags instead of script flags) is the behaviour 
> the expected? This is:
> - A is executed for the incoming INVITE.
> - B is NOT executed for the dummped MESSAGE.
>   
Message flags are safe as they are kept in a inner field of struct 
sip_msg. The others are in global variables, specific for  the context 
of the script/message.

The branch flags are broken.

route {
   setbflag(3);
   if(method=="INVITE")
       m_dump();
   if(isbflagset(3))
   {
         # Is it executed for the incoming INVITE?      <-- A
   } 
}


local_route {
   if(isbflagset(3))
   {
         # Is it executed for the dummped MESSAGE?  <-- B
   } 
}

in this case, bot A and B are executed.

Cheers,
Daniel

>
> Thanks a lot for your explanation.
>
>
>
>
>   

-- 
http://www.asipto.com