<div dir="ltr"><div>John,</div><div><br></div><div>This has worked brilliantly -- the domain module took care of teaching OpenSIPS what's local.  As far as a single versus double RR, the problem turned out to be with a downstream SBC that couldn't resolve the domain name properly.  Once fixed, the single RR works as expected.<br></div><div><br></div><div><br></div><div>Regards,</div><div>Jeff</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, May 11, 2021 at 7:07 AM John Quick <<a href="mailto:john.quick@smartvox.co.uk">john.quick@smartvox.co.uk</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Jeff,<br>
<br>
Regarding the first issue you mention, have you tried:<br>
record_route_preset(“SBC_FQDN:5061;transport=tls”);<br>
<br>
In other words, have you tried it with a single rather than a double RR header?<br>
You would need to remove the ";r2=on" parameter of course.<br>
<br>
In theory, if the SBC_FQDN resolves to the IP address and everything communicating with your SBC is (a) capable of resolving the FQDN and (b) capable of routing to the SBC, then it should work.<br>
<br>
In my script I added " AS SBC_FQDN:5061" on the end of the tls listen/socket statement. I cannot remember if that was essential for it to work, but I leave it there on the basis that it cannot do any harm and might do some good.<br>
<br>
John Quick<br>
Smartvox Limited<br>
<br>
</blockquote></div>