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.
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:
- 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.
- 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.
- 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.
2010/10/25 Daniel-Constantin Mierla miconda@gmail.com:
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.
- 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.
- 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.
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...
On 10/25/10 6:35 PM, Iñaki Baz Castillo wrote:
2010/10/25 Daniel-Constantin Mierlamiconda@gmail.com:
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.
- 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.
- 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.
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
Not sure what happens in case of serial forking using append_branch() in failure_route...
2010/10/25 Daniel-Constantin Mierla miconda@gmail.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?
On 10/25/10 10:08 PM, Iñaki Baz Castillo wrote:
2010/10/25 Daniel-Constantin Mierlamiconda@gmail.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?
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
2010/10/25 Daniel-Constantin Mierla miconda@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.
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.
On 10/25/10 10:30 PM, Iñaki Baz Castillo wrote:
2010/10/25 Daniel-Constantin Mierlamiconda@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
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.
-
Daniel-Constantin Mierla -
Iñaki Baz Castillo