2010/10/25 Daniel-Constantin Mierla miconda@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.