25 Oct
2010
25 Oct
'10
7:25 p.m.
Hi, I know that handling bflags outside of branch_route is not a good
idea. Anyhow I have a doubt:
1) In a normal route I set "setbflag(i:1)", so the bflag will be set
for all the branches that could be generated for this incoming
transaction. This also involves creating new branches manually under
failure_route, am I right?
Note: I do know that it would be much better just to use flag instead of bflags.
2) The outgoing transaction(s) fail so I enter into failure_route. If
I inspect here bflag(i:1) will it be set or not? I remember that it
will be set.
3) Then I call append_branch in failure_route, or perhaps call
loockup("location") and I expect that all the generated branches will
have the bflag set, am I right?
Thanks a lot.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
25 Oct
25 Oct
7:31 p.m.
Hello,
On 10/25/10 6:25 PM, Iñaki Baz Castillo wrote:
Hi, I know that handling bflags outside of
branch_route is not a good
idea. Anyhow I have a doubt:
1) In a normal route I set "setbflag(i:1)"
why are you using "i:1"? The parameter must be just 1.
, so the bflag will be set
for all the branches that could be generated for this incoming
transaction. This also involves creating new branches manually under
failure_route, am I right?
Note: I do know that it would be much better just to use flag instead of bflags.
2) The outgoing transaction(s) fail so I enter into failure_route. If
I inspect here bflag(i:1) will it be set or not? I remember that it
will be set.
3) Then I call append_branch in failure_route, or perhaps call
loockup("location") and I expect that all the generated branches will
have the bflag set, am I right?
never used in this way, but the normal usage is per
branch and when you
do it in the main route then it is just for first branch.
Cheers,
Daniel
Thanks a lot.
--
Daniel-Constantin Mierla
http://www.asipto.com
7:35 p.m.
2010/10/25 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
It's more curiosity than need. But anyhow I'm 90% sure that if you set
a bflag in route then it will be set for all the branches generated
during loockup(location). Not sure what happens in case of serial
forking using append_branch() in failure_route...
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
why are you using "i:1"? The parameter must
be just 1.
Sorry, just a typo in the mail :)
, so the bflag
will be set
for all the branches that could be generated for this incoming
transaction. This also involves creating new branches manually under
failure_route, am I right?
Note: I do know that it would be much better just to use flag instead of
bflags.
2) The outgoing transaction(s) fail so I enter into failure_route. If
I inspect here bflag(i:1) will it be set or not? I remember that it
will be set.
3) Then I call append_branch in failure_route, or perhaps call
loockup("location") and I expect that all the generated branches will
have the bflag set, am I right?
never used in this way, but the normal usage is per branch and when you do
it in the main route then it is just for first branch.
10:38 p.m.
On 10/25/10 6:35 PM, Iñaki Baz Castillo wrote:
2010/10/25 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
It's more curiosity
than need. But anyhow I'm 90% sure that if you set
a bflag in route then it will be set for all the branches generated
during loockup(location).
Looked in the code and I saw that only first branch inherits the branch
flags from main route, the other takes only the value from location records.
Cheers,
Daniel
why are you using "i:1"? The parameter
must be just 1.
Sorry, just a typo in the mail :)
, so the
bflag will be set
for all the branches that could be generated for this incoming
transaction. This also involves creating new branches manually under
failure_route, am I right?
Note: I do know that it would be much better just to use flag instead of
bflags.
2) The outgoing transaction(s) fail so I enter into failure_route. If
I inspect here bflag(i:1) will it be set or not? I remember that it
will be set.
3) Then I call append_branch in failure_route, or perhaps call
loockup("location") and I expect that all the generated branches will
have the bflag set, am I right?
never used in this way, but the normal usage is
per branch and when you do
it in the main route then it is just for first branch. Not sure what happens in case of serial
forking using append_branch() in failure_route...
--
Daniel-Constantin Mierla
http://www.asipto.com
11:08 p.m.
2010/10/25 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
Looked in the code and I saw that only first branch
inherits the branch
flags from main route, the other takes only the value from location records.
Ok, so better to be careful with this and use blfag just under branch_route :)
PS: Perhaps would it make sense a constrain so setbflag(),
isbflagset() and resetbflag() cannot be used in route and
failure_route anymore?
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
11:21 p.m.
On 10/25/10 10:08 PM, Iñaki Baz Castillo wrote:
2010/10/25 Daniel-Constantin
Mierla<miconda(a)gmail.com>om>:
they are necessary in route to mark natted register as well
as checking
the branch flag when you don't run branch_route. In failure route you
should get the branch flags from selected failed branch.
Cheers,
Daniel
--
Daniel-Constantin Mierla
http://www.asipto.com
Looked in the code and I saw that only first
branch inherits the branch
flags from main route, the other takes only the value from location records.
Ok,
so better to be careful with this and use blfag just under branch_route :)
PS: Perhaps would it make sense a constrain so setbflag(),
isbflagset() and resetbflag() cannot be used in route and
failure_route anymore?
11:30 p.m.
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.
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?
Cheers.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
26 Oct
26 Oct
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?
12:30 a.m.
2010/10/25 Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
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.
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.
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
<ibc(a)aliax.net>
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? 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?
5145
days inactive
5145
days old
8 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo