26 Oct
2010
26 Oct
'10
12:03 a.m.
On 10/25/10 10:30 PM, Iñaki Baz Castillo wrote:
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.
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
2010/10/25 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
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?
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 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. 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?