Hugh Waite writes:
A new route type "branch_failure_route" which can be called on a failure response for every branch created.
fine.
Change t_next_contact_flows() so that it can only be called from the branch_failure route.
then also the name of the function could be changed to t_next_contact_flow(), because there cannot be more than one of them.
Modify t_next_contact_flows() so that it will search the xavp of alternative flows and select the next instance that matches the failed instance. This will create another branch.
fine.
t_relay() can be used in the branch_failure route to fork to the new branch. There will be a few more functions that can be called in the branch_failure route, including unregister_contact().
if contact is tcp contact and the branch fails because set_forward_no_connect() is set, then it would be nice if also in that case the contact could be unregistered. perhaps that will be possible in your implementation?
If no new flows are available, the response is passed on to be handled by the failure route handler. If a new flow is available, and a branch created, the failure response must not be passed on. A response from the new branch, plus all other branches must be received before the failure route is called with the best response.
If the failure route is called, t_next_contacts() can be called to implement serial forking based on q-value, as before.
ok,
Any comments before I start work?
no other comments from me. thanks for your effort.
-- juha