<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Hi John,<div><br></div><div>I use the same record_route_preset() commands on my setup.</div><div><br></div><div>After more searches about my issue I found threads pointing invalid RURI and the cause to be Contact patching that should be done only for OPTIONS.</div><div><br></div><div>I made some more tests, removed contact patching on initial requests (also removed all my socket and destination uri rewriting routines) since then, all requests are forwarded like a charm.</div><div><br></div><div>If I well understood, because of contact patching, RURI was misleading / invalid, openSIPS had to find more parameters to be able to forward the requests.</div><div>So, it tried to use Route headers to find the socket and destination URI to use to forward the requests.</div><div><br></div><div>- It successfully did for the first route header, because it found the FQDN through domain module => that was the TLS part - useless to reach the destination.</div><div>- It didn’t succeed for the second route header, because it doesn’t try anymore to find FQDN through domain module => that was the SIP part, needed to know how to reach the destination but ignored because considered as "non local"</div><div><br></div><div>With incorrect contact, and so incorrect RURI, not being to solve socket and destination URI was a problem.</div><div><div><br></div><div>Now RURI is correct, it is used as is, and requests are forwarded to the next hop.</div></div><div><br></div><div><div><div> « no socket found to match 2nd RR » warnings are still there in logs despite FQDN should match as it is present in domain module database.</div><div><div><div></div></div><div></div></div></div></div><div>The matching failure is no more a (real) issue for things to work.</div><div><br></div><div>There are probably things to do to improve the routines in order the warning not to appear anymore but</div><div>I’m far from an OpenSIPS specialist to know if that would really be beneficent if that was changed nor if that wouldn’t lead to other regressions or side effects. </div><div><br></div><div>Anyway, thank you John for trying to help me solve my issue.</div><div><br></div><div>Regards</div><div><br></div><div>Daren</div><div><br></div><div><br></div><div> </div><div><br></div><div><br></div><div><br></div><div><div><br><blockquote type="cite"><div>Le 22 févr. 2023 à 17:31, John Burke <john@voxtelesys.com> a écrit :</div><br class="Apple-interchange-newline"><div>
<div>
<font face="Helvetica, Arial, sans-serif">Hey Daren,<br>
<br>
You can use any combo of interface / protocol that you want and
RR/loose-routing should handle it. I have deployed SBCs in a
similar topology as you describe (no Topology Hiding).<br>
<br>
In such a case, you should see a couple RR headers added by
OpenSIPS: 1 for the TLS leg to MS and 1 for the UDP leg. The TLS
leg should have the FQDN that MS requires and you should have this
stored in the domain module. The UDP will contain the local socket
for the UDP listener.<br>
<br>
Have you confirmed the RR headers look good? I dug up a snippet
from an SBC that handled both MS and non-MS traffic, where I was
manually providing the RR headers in the TLS/UDP case.<br>
<br>
/*<br>
NAME: HANDLE_RECORD_ROUTE<br>
DESIGN: Properly applies Record-Route headers to request. For
Microsoft Teams, it is<br>
a requirement to use FQDN in Route header. Therefore,
if the request is identified<br>
to be Microsoft Teams then use FQDN otherwise use IP.<br>
*/<br>
route[HANDLE_RECORD_ROUTE] {<br>
xlog("L_INFO", "HANDLE_RECORD_ROUTE:INFO\n");<br>
<br>
if (route(IS_MSTEAMS)) {<br>
if (route(IS_REQUEST_FROM_MSTEAMS))<br>
record_route_preset("MY_IP:5060;r2=on","$rd:5061;transport=tls;r2=on");<br>
else<br>
record_route_preset("$fd:5061;transport=tls;r2=on","MY_IP:5060;r2=on");<br>
return(1);<br>
}<br>
<br>
record_route();<br>
}<br>
</font><br>
<br>
<font face="Helvetica, Arial, sans-serif">John<br>
<br>
</font>
<div class="moz-cite-prefix">On 2/21/23 11:04 AM, Daren FERREIRA
wrote:<br>
</div>
<blockquote type="cite" cite="mid:DM6PR04MB6474EEFB1C5EDBDAEBE27A31B0A59@DM6PR04MB6474.namprd04.prod.outlook.com">
<div style="overflow-wrap: break-word; -webkit-nbsp-mode: space;
line-break: after-white-space;">Hey John,
<div><br>
</div>
<div>I made some more tests and, indeed, domain is well used by
loose_route my problem is:</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<div>
<div>On both cases, the most important informations are
$socket_out and $du I print on my log messages:</div>
</div>
<div><br>
</div>
<div><br>
</div>
<div>If domain is defined and known, is is considered as local
but socket and $du are emptied because of the previously
mentioned warning: "WARNING:rr:after_loose: no socket found to
match 2nd RR" And I get</div>
<div><br>
</div>
<div><span style="font-family: Menlo; font-size: 11px;">Feb 21
17:27:49 opensips[48264]: Feb 21 17:27:49 [48264]
INFORMATIONS ROUTE C2: SOURCE 52.114.75.24 METHOD ACK STATUS
<null> REPLY_REASON <null> RECEIVED_ON
tls:100.64.0.1 REPLY FROM tls:100.64.0.1:5061 DU
<a class="moz-txt-link-freetext" href="sip:myFQDN.com:5061;transport=tls;ftag=534123ce5a624b30b3cb9edd5806b8b7;lr;r2=on">sip:myFQDN.com:5061;transport=tls;ftag=534123ce5a624b30b3cb9edd5806b8b7;lr;r2=on</a>
- <a href="http://myfqdn.com/" moz-do-not-send="true">myFQDN.com</a></span></div>
<div><span style="font-family: Menlo; font-size: 11px;"><br>
</span></div>
<div><span style="font-family: Menlo; font-size: 11px;"><br>
</span></div>
<div>If domain is not defined, is is not considered as local and
socket and $du are left as is and so, not treated as it
should. And I get:</div>
<div><br>
</div>
<div>
<div>
<div style="margin: 0px; font-stretch: normal; font-size:
11px; line-height: normal; font-family: Menlo;"><span style="font-variant-ligatures: no-common-ligatures;">Feb
21 17:31:32 opensips[48264]: Feb 21 17:31:32 [48264]
INFORMATIONS ROUTE C2: SOURCE 52.114.75.24 METHOD ACK
STATUS <null> REPLY_REASON <null>
RECEIVED_ON tls:100.64.0.1 REPLY FROM
udp:100.64.0.1:5060 DU <null> - <null></span></div>
</div>
</div>
<div><span style="font-variant-ligatures: no-common-ligatures;"><br>
</span></div>
<div><br>
</div>
<div>
<div style="margin: 0px; font-stretch: normal; font-size:
11px; line-height: normal; font-family: Menlo;">My message
has been blocked because of its length. Full log is
available on <a href="https://pastebin.com/tXKAJpeL" moz-do-not-send="true" class="moz-txt-link-freetext">https://pastebin.com/tXKAJpeL</a></div>
</div>
<div style="margin: 0px; font-stretch: normal; font-size: 11px;
line-height: normal; font-family: Menlo;"><br>
</div>
<div style="margin: 0px; font-stretch: normal; font-size: 11px;
line-height: normal; font-family: Menlo;"><br>
</div>
<div>In short terms: </div>
<div><br>
</div>
<div>REPLY FROM $socket_out DU $du</div>
<div><br>
</div>
<div><span style="font-family: Menlo; font-size: 11px;">"REPLY
FROM tls:100.64.0.1:5061 DU <a href="sip:myFQDN.com:5061;transport=tls;ftag=534123ce5a624b30b3cb9edd5806b8b7;lr;r2=on" moz-do-not-send="true" class="moz-txt-link-freetext">sip:myFQDN.com:5061;transport=tls;ftag=534123ce5a624b30b3cb9edd5806b8b7;lr;r2=on</a>"</span></div>
<div><span style="font-family: Menlo; font-size: 11px;">"REPLY
FROM udp:100.64.0.1:5060 DU <null></span><font face="Menlo"><span style="font-size: 11px;"> »</span></font></div>
<div><font face="Menlo"><span style="font-size: 11px;"><br>
</span></font></div>
<div><font face="Menlo"><br>
</font></div>
<div>Where we well see that $du is empty… (and in some cases
$socket_out is wrong).</div>
<div><br>
</div>
<div>That seems to confirm my thoughts about a potential problem
with reusing the same IP facing Microsoft as the facing my
internal devices and/or the mix between UDP and TLS.</div>
<div><br>
</div>
<div><br>
</div>
<div>On you case, to you use the same IP address for facing
Microsoft and you devices? Do you use TLS on both sides of the
call?</div>
<div><br>
</div>
<div>Thank you </div>
<div><br>
</div>
<div><br>
</div>
<div><font face="Menlo"><br>
</font>
<div><br>
<blockquote type="cite">
<div>Le 21 févr. 2023 à 17:07, John Burke
<a class="moz-txt-link-rfc2396E" href="mailto:john@voxtelesys.com"><john@voxtelesys.com></a> a écrit :</div>
<br class="Apple-interchange-newline">
<div>
<div> <font face="Helvetica, Arial, sans-serif">Hey
Daren<br>
<br>
It's been a while since I've been inside the MS
integration TBH, but I remember digging into the
code at the time and am pretty sure it was the
domain module that fixed the multi-tenant FQDN
loose-routing issue. You dismissed the domain
implemented based on your source code searching, but
did you give it a quick try?<br>
<br>
I quickly looked up some notes:<br>
<br>
<span id="cid:part1.0rUqRrHs.ZhDftenZ@voxtelesys.com"><XIbHvx0c2a8RAZsn.png></span><br>
<br>
<br>
My memory could be wrong :) but IMO it's worth a
quick shot.<br>
<br>
I didn't see anything else special in the config for
MS, besides what the tutorial points out.<br>
<br>
</font>
<div class="moz-signature">
<div style="font-family: tahoma, helvetica,
sans-serif; font-size: 16px;"><span data-mce-style="color: #808080; font-family:
arial,helvetica,sans-serif; font-size: 11pt;" style="color: rgb(128, 128, 128); font-family:
arial, helvetica, sans-serif; font-size: 11pt;">Regards,</span>
</div>
<div><span data-mce-style="color: #808080;
font-family: arial,helvetica,sans-serif;
font-size: 11pt;" style="color: rgb(128, 128,
128); font-family: arial, helvetica, sans-serif;
font-size: 11pt;"><strong>John Burke<br>
<br>
</strong></span></div>
</div>
<div class="moz-cite-prefix">On 2/21/23 9:28 AM, Daren
FERREIRA wrote:<br>
</div>
<blockquote type="cite" cite="mid:DM6PR04MB647425878C3839A5A94CC131B0A59@DM6PR04MB6474.namprd04.prod.outlook.com">
Hi John,
<div><br>
</div>
<div>Everything I read, even in the opensips source
code (grep_sock_info_ext function) shows it is
only comparing Route headers values to its local
IP addresses.</div>
<div>Whatever I set, comparison is always made with
IPs not FQDN.</div>
<div><br>
</div>
<div>I do use domain modules for other tests and
functions but according to my tests, domain module
is not linked nor « consumed » by loose_route(),
so that doesn’t solve my issue.</div>
<div><br>
</div>
<div>I wonder if the reason I face this problems is
not because:</div>
<div>- I use the same IP address to talk to
Microsoft as to talk to my internal devices =>
If IP would be different on the « WAN » and
« LAN » side, maybe that would be much easier for
opensips to match?</div>
<div>- I use UDP TLS with Microsoft and UDP with my
internal devices => If protocol would be the
same, there won’t have to switch between sockets?</div>
<div><br>
</div>
<div>Maybe a mix of both…</div>
<div><br>
</div>
<div>Or maybe most people using OpenSIPS with Teams
don’t use it for multi-tenant, use it statically
or have done the same « cooking » I made without
complaining ;-)</div>
<div><br>
</div>
<div>Thank you for you reply :-)</div>
<div><br>
</div>
<div><br>
<div><br>
<blockquote type="cite">
<div>Le 21 févr. 2023 à 15:40, John Burke via
Users <a class="moz-txt-link-rfc2396E" href="mailto:users@lists.opensips.org" moz-do-not-send="true"><users@lists.opensips.org></a>
a écrit :</div>
<br class="Apple-interchange-newline">
<div>
<div dir="auto">Hey Daren,
<div><br>
</div>
<div>Aliases should work I believe,
however, you can also use the domain
module[1] to dynamically maintain
“local” FQDNs.</div>
<div><br>
</div>
<div>[1] <a href="https://opensips.org/docs/modules/devel/domain.html" moz-do-not-send="true" class="moz-txt-link-freetext">https://opensips.org/docs/modules/devel/domain.html</a><br>
<br>
<div dir="ltr">Sent from my iPhone</div>
<div dir="ltr"><br>
<blockquote type="cite">On Feb 21,
2023, at 8:33 AM, Daren FERREIRA <a class="moz-txt-link-rfc2396E" href="mailto:darencrew@hotmail.com" moz-do-not-send="true"><darencrew@hotmail.com></a>
wrote:<br>
<br>
</blockquote>
</div>
<blockquote type="cite">
<div dir="ltr"><span>Hello,</span><br>
<span></span><br>
<span>According to my understanding
of OpenSIPS Route headers
management with loose_route
function, it is only able to test
matching between local listening
IP addresses and Route headers,
not with FQDN.</span><br>
<span></span><br>
<span>In other words, if FQDN are
presents in Route headers, they
are compared to local IP addresses
(well visible in logs), so, this
never matches and you get a
"WARNING:rr:after_loose: no socket
found to match 2nd RR"</span><br>
<span></span><br>
<span>This has never been a
limitation until I had to work
with Microsoft TEAMS, that
requires the use of FQDN in Route
headers.</span><br>
<span></span><br>
<span>I tried using aliases, Route
headers tags, and lots of other
things, without success…</span><br>
<span></span><br>
<span>Even if aliases would have
been a solution, that is not a
scalable solution when using
OpenSIPS as a multi-tenant SBC for
Teams (as aliases changes require
an OpenSIPS restart).</span><br>
<span></span><br>
<span>The only workaround I found
was rewriting $du and $socket (so
partially reimplement
loose_route() ) based on context
values stored in dialog variables
(that’s working quite well
anyway).</span><br>
<span></span><br>
<span>Many people seems to use
OpenSIPS successfully with TEAMS
and nobody seems to have publicly
complained about such limitations
on forums.</span><br>
<span></span><br>
<span>I may have missed something,
and so I wonder what can be done
to better work with Route headers.</span><br>
<span></span><br>
<span>Do anybody have any idea on
what I may have missed?</span><br>
<span></span><br>
<span>Thank you for your advices and
comments.</span><br>
<span></span><br>
<span>Daren</span><br>
<span>_______________________________________________</span><br>
<span>Users mailing list</span><br>
<span><a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:Users@lists.opensips.org" moz-do-not-send="true">Users@lists.opensips.org</a></span><br>
<span><a class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" moz-do-not-send="true">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a></span><br>
<span></span><br>
<span></span><br>
<span>--</span><br>
<span> Please be cautious! This
email was sent from outside of
Voxtelesys.</span><br>
</div>
</blockquote>
</div>
</div>
_______________________________________________<br>
Users mailing list<br>
<a class="moz-txt-link-abbreviated moz-txt-link-freetext" href="mailto:Users@lists.opensips.org" moz-do-not-send="true">Users@lists.opensips.org</a><br>
<a class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users" moz-do-not-send="true">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a><br>
</div>
</blockquote>
</div>
<br>
</div>
<br>
--<br>
<table style="border-collapse: collapse; width:
100%; height: 64px; background-color: #fd3d14;" border="1">
<tbody>
<tr style="height: 64px;">
<td style="width: 100%; height: 64px;
text-align: center;">
<pre><span style="background-color: #fd3d14; color: #ffffff;"><strong><span style="font-size: 300%;"> Please be cautious!</span></strong>
<span style="font-size: x-large;"> This email was sent from outside of Voxtelesys.</span></span></pre>
</td>
</tr>
</tbody>
</table>
</blockquote>
<br>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
<br>
--<br>
<table style="border-collapse: collapse; width: 100%; height:
64px; background-color: #fd3d14;" border="1">
<tbody>
<tr style="height: 64px;">
<td style="width: 100%; height: 64px; text-align: center;">
<pre><span style="background-color: #fd3d14; color: #ffffff;"><strong><span style="font-size: 300%;"> Please be cautious!</span></strong>
<span style="font-size: x-large;"> This email was sent from outside of Voxtelesys.</span></span></pre>
</td>
</tr>
</tbody>
</table>
</blockquote>
<br>
</div>
</div></blockquote></div><br></div></body></html>