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 _______________________________________________ sr-dev mailing list [email protected] http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
