[SR-Users] bflag under failure_route (kamailio 1.5)

Daniel-Constantin Mierla miconda at gmail.com
Mon Oct 25 23:03:37 CEST 2010



On 10/25/10 10:30 PM, Iñaki Baz Castillo wrote:
> 2010/10/25 Daniel-Constantin Mierla<miconda at gmail.com>:
>>> PS: Perhaps would it make sense a constrain so setbflag(),
>>> isbflagset() and resetbflag() cannot be used in route and
>>> failure_route anymore?
>> they are necessary in route to mark natted register
> Right, but IMHO it would make more sense it to be a flag and not a
> bflag (as the registrar server is processing the incoming transaction
> rather than generating an outgoing transaction). This is, the
> registrar set a flag(NATTED) before "save(location)". When retrieving
> the registrations for this AoR this flag would become a bflag.
> Of course this changes the current behaviour, but IMHO makes more sense.

This will make things a bit more complex, should it be there a mask of 
what flags are saved as branch flags and a map of translation?
>
>> as well as checking the branch flag when you don't run branch_route.
> If there are two registrations for an AoR, one of them behind NAT and
> the other one with public IP, checking "isbflagset(NATTED)" in route
> would retrieve 1 or 0 randomly (depending on the first branch found in
> the location table). This is not consistent.

But in some deployments, you may want to keep only one registration per 
user, save(location) can do that, and then you don't bother with 
branch_route.

>
>> In failure route you should get the branch flags from selected failed branch.
> But is this useful? imagine lookup("location") retrieves two
> registrations (one of them behind NAT) and Kamailio receives 486 for
> both branches. Which is the winning branch? AFAIK it's random so, what
> is the purpose of checing bflags in failure_route?
Branch flags can be set for some other purposes, not only NAT state. 
Therefore you may want to check it in failure route.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
http://www.asipto.com




More information about the sr-users mailing list