<p><a href="https://github.com/jarrodb" class="user-mention">@jarrodb</a> , the sip_resolvehost() takes the proto parameter as a must. Whatever proto is requests by upper layer must be obey. This function must not change the proto (for whatever reasons) .<br>
If the upper layer wants TLS (because of forced from script, or because the the URI indication), the function must find (DNS based) a destination for TLS. If an SRV record is not present should be an error - maybe there is a simple setup where SRV is not used. But the service accepts TLS via A record + default SIP port.<br>
For having proto fallback, the whole logic of the function + upper layer must be changed. The fallback (like enabling and potential options) should be dictated by the upper layer (or some mid layer function) and the sip_resolvehost() just to perform the actual DNS lookup (with an eventual break if some records are not present and indicated so).</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/issues/482#issuecomment-98760157">view it on GitHub</a>.<img alt="" height="1" src="https://github.com/notifications/beacon/AFOciSymSl4DR7GLPg3VHRTwr-Yqvs20ks5oF4uagaJpZM4EK8Cp.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/issues/482#issuecomment-98760157"></link>
    <meta itemprop="name" content="View Issue"></meta>
  </div>
  <meta itemprop="description" content="View this Issue on GitHub"></meta>
</div>