fix: when deciding if we need to propagate a reply, skip branches scheduled for cancellation but with no replies yet

[vladpaiu]

Summary
Current bug is :

• we have branch1 sent to a destination which is dead/down/not replying
• we have branch2 replying with a code that the script decides should terminate the transaction ( ie. if ($rs == 486) t_cancel_branch("o")

The bug is that the 486 does not get propagated on the spot - it gets saved internally and relayed only when fr_timeout elapses.

Details
Ignore branches scheduled for CANCELation via t_cancel_branch, which don't have any replies on them yet.

Solution
Ignore branches scheduled for CANCELation via t_cancel_branch, which don't have any replies on them yet.

Compatibility
Should be backwards compatible - I hope.

[bogdan-iancu]

@vladpaiu , this is not a bug at all. The RFC3261 says you have to forward back to caller a negative final reply only after completing all the branches of the transaction. Now, a branch which haven't received any reply, even if marked for canceling, it is still a open, ongoing branch, you cannot simply ignore it. It is possible for that branch to generate a 200 OK at a point (as a response to your INVITE), so you cannot cancel it anymore.
Also, for the sake of the sanity of the TM internal logic, branches should be properly terminated upon sending a reply back to caller. I mean that unresponsive branch should be marked as completed, like with a 408 timeout at least. So the transactional data is consistent.
In your case, why not setting a low (1-2 secs) fr_timer to avoid waiting too long for such unresponsive branches?

Anyhow, I do not see this as a bug at all. In the best way maybe as a feature request in changing the TM behavior.

[bogdan-iancu]

ping @vladpaiu

[vladpaiu]

sorry for the long delay, just now getting back to this.

my new scenario here is :

• t_wait_for_new_branches();
• fork to dst 1 and dst 2, no new branch gets injected. dst 1 is ringing, dst 2 is giving me back a 603
• in onreply_route, I have
  t_wait_no_more_branches();
  t_cancel_branch("a") - to CANCEL dst 1

basically I'm trying to get this call to failure_route, to send it someplace else. Setting T_fr_inv_timeout or T_fr_timeout from the 603 onreply route does not help me, the transaction still ends up waiting for the full initial T_fr_inv_timeout seconds.

so think that with my patch, I'm basically skipping the phony branch, which was marked as to be cancelled.
still feel like this is a bug that needs addressing...