[Devel] Patch: cpl-c bug fix for nat flag in branches

Bogdan-Andrei Iancu bogdan at voice-system.ro
Mon Nov 13 18:56:57 CET 2006


ups....my mistake on the flag mask problem....it looks like when passing 
the flag to append_branch, the shift operator was missing.....so you 
were right! :)

regards,
bogdan

Bogdan-Andrei Iancu wrote:

> Hi John,
>
> I did some reviewing of the patch.
>
> first of all, there was no bug about flag processing. The variable was 
> keeping the flag index and the function setflag() takes an index; for 
> append_branch() the mask was computed.
> but I agree that keeping the mask is a much better approach.
>
> secondly, yes, there was a bug in pushing the NAT flag into messages 
> when only the branches were nated.
>
> I will apply your patch a slightly modified version. Thanks again for it!
>
> regards,
> bogdan
>
> Bogdan-Andrei Iancu wrote:
>
>> Hi John,
>>
>> at a first look it might be correct what you are saying....I will 
>> take a closer look in the next days (right now I'm deep involved with 
>> the OpenSER Summit) and if ok, I will commit it on CVS.
>>
>> regards,
>> bogdan
>>
>> John Riordan wrote:
>>
>>> Hi,
>>>
>>>
>>> Issue:
>>>
>>> In CPL, during a proxy to a location set the
>>> value of the branch flag being passed to append_branch
>>> is currently the configured value for "nat_flag" (ie 6).
>>> However, append_branch is expecting a bit mapped flag value (ie 0x40).
>>>
>>> Also in CPL, the nat flag is getting set for the msg
>>> if any branches have the nat flag set. This can cause
>>> the RURI branch to have the nat flag set when the
>>> location associated with the RURI branch does not
>>> have the branch flag set.
>>>
>>>
>>> Patch:
>>>
>>> Addressed the two issues above.
>>>
>>> Also, to be consistant with the default used in the
>>> registrar module, made the default for nat flag -1
>>> in the cpl-c module.
>>>
>>>
>>> John
>>>




More information about the Devel mailing list