Hi, using Kamailio 1.5.4. I've detected a possible error:
- INVITE received.
- It's routed to gw-1 (branch-1).
- Branch-1 replies some final non 2XX reply and in on_reply_route I set a bflag.
- In failure_route I check the value of such bflag and it's set (OK).
- Still in failure_route I create a new branch (Branch-2).
- Branch-2 replies some final non 2XX reply and in on_reply_route I *DONT* set the bflag for this second branch.
- In failure_route I check the value of such bflag and it's set (WHY??).
Why is such bflag set when inspecting it in failure_route for the second branch? the branch creating such negative final response (Branch-2) hasn't such bflag active. Is it the expected behaviour due to something I miss? or is it a posible bug?
Regards.
2010/3/25 Iñaki Baz Castillo ibc@aliax.net:
Why is such bflag set when inspecting it in failure_route for the second branch? the branch creating such negative final response (Branch-2) hasn't such bflag active. Is it the expected behaviour due to something I miss? or is it a posible bug?
Well, in case of parallel forking in which bflags is just set for some branches, it would be really difficult to determine which should be the status of such bflag after all the branches have failed, so most probably what I'm trying to achieve makes no sense.
I think I shoul dplay with a flag (instead of bflag) and use "set" and "unset" in each case.
I guess append_branch copies also all the flags
regards klaus
Iñaki Baz Castillo wrote:
Hi, using Kamailio 1.5.4. I've detected a possible error:
INVITE received.
It's routed to gw-1 (branch-1).
Branch-1 replies some final non 2XX reply and in on_reply_route I set a bflag.
In failure_route I check the value of such bflag and it's set (OK).
Still in failure_route I create a new branch (Branch-2).
Branch-2 replies some final non 2XX reply and in on_reply_route I
*DONT* set the bflag for this second branch.
- In failure_route I check the value of such bflag and it's set (WHY??).
Why is such bflag set when inspecting it in failure_route for the second branch? the branch creating such negative final response (Branch-2) hasn't such bflag active. Is it the expected behaviour due to something I miss? or is it a posible bug?
Regards.
2010/3/25 Klaus Darilion klaus.mailinglists@pernau.at:
I guess append_branch copies also all the flags
Even if it was false, I expect this is not possible to determine the exact branch whose final negative response was selected to terminate the incoming INVITE transaction, this is:
- INVITE arrives and the proxy does parallel forking (branch-A and branch-B).
- bflag(1) is set for branch-A.
- blfag(1) is NOT set for branch-B.
- branch-A replies 486.
- branch-B replies 480.
- On failure route you get the TM selected final negative response, but this process just means selecting the "best" one of the received negative replies. I expect that selecting such reply doesn't mean that we can get in failure_route the bflags associated to the branch whose reply TM has selected.
So IMHO my question was originally wrong as no bflag should be inspected in failure_route (undefined result when doing it).
I aki Baz Castillo writes:
So IMHO my question was originally wrong as no bflag should be inspected in failure_route (undefined result when doing it).
i have been using a non-branch flag as GW_ALIVE flag, which i set in on_reply route if i get a provisional reply from the next gw and it has worked fine.
-- juha
2010/3/26 Juha Heinanen jh@tutpro.com:
I aki Baz Castillo writes:
> So IMHO my question was originally wrong as no bflag should be > inspected in failure_route (undefined result when doing it).
i have been using a non-branch flag as GW_ALIVE flag, which i set in on_reply route if i get a provisional reply from the next gw and it has worked fine.
Yes, using a transaction flag (rather than flag) even in on_reply_route (for a branch) is valid and correct. My point was exactly the opposite.
-
Iñaki Baz Castillo -
jh＠tutpro.com -
Klaus Darilion