2010/10/25 Daniel-Constantin Mierla <mico...@gmail.com>:
>> 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?
Yes, for sure my proposal would not fit very well with current design
in which a single bflag is used to set the registration as natted and
to retrieve the NAT status of a registration user. I just meant that
IMHO it makes more sense to use a flag(NATTED) before "save(location)"
rather than a bflag.
>> 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.
Yes, perhaps it could be better documented the risk of inspecting a
bflag (after lockup) in "normal" environments in which multiple
registrations for same AoR take place. I've seen lot of
openser/kamailio scripts failing in this point as they check the
bflag(natted) under 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.
Ok, I agree that handling bflags on failure_route can make sense (not
so much on route IMHO). I just wanted to propose some constrains that
make the configuration a bit more "error-safe" :)
Regards.
--
Iñaki Baz Castillo
<i...@aliax.net>
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
