<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>