<p>I agree with points 1-3, as well as the follow on that it would allow for multiple attempts against weighted SRV records.</p>

<p>I am not sure I follow that we need to know the destination protocol/address family before the main request route - I would say that would not be useful as the request could end up forking via append_branch mechanisms.  Knowing in branch_route IS crucial, and any processing that is happening based on a destination should happen in the branch route father than the request route block.</p>

<p>In the case of failure route, you need to know what AF/protocol you had attempted, but this can be achieved via transactional storage mechanisms: avp, flags etc.  If you t_relay from failure_route it will hit the branch route again for further branch processing.</p>

<p>I assume in your example that in the failure route you have modified plist to remove the previously attempted protocol from the list before passing it to uri_resolve?</p>

<p>It seems like a reasonable approach to me in general.</p>

<p style="font-size:small;-webkit-text-size-adjust:none;color:#666;">&mdash;<br>Reply to this email directly or <a href="https://github.com/OpenSIPS/opensips/pull/483#issuecomment-98193726">view it on GitHub</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/AFOciSpEm4ZCmV9v82mvgnXVKvoiTF_Kks5oE7qOgaJpZM4ELAUw.gif" width="1" /></p>
<div itemscope itemtype="http://schema.org/EmailMessage">
  <div itemprop="action" itemscope itemtype="http://schema.org/ViewAction">
    <link itemprop="url" href="https://github.com/OpenSIPS/opensips/pull/483#issuecomment-98193726"></link>
    <meta itemprop="name" content="View Pull Request"></meta>
  </div>
  <meta itemprop="description" content="View this Pull Request on GitHub"></meta>
</div>