Hey Daren,
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).
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.
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.
/*
NAME: HANDLE_RECORD_ROUTE
DESIGN: Properly applies Record-Route headers to request. For
Microsoft Teams, it is
a requirement to use FQDN in Route header. Therefore, if
the request is identified
to be Microsoft Teams then use FQDN otherwise use IP.
*/
route[HANDLE_RECORD_ROUTE] {
xlog("L_INFO", "HANDLE_RECORD_ROUTE:INFO\n");
if (route(IS_MSTEAMS)) {
if (route(IS_REQUEST_FROM_MSTEAMS))
record_route_preset("MY_IP:5060;r2=on","$rd:5061;transport=tls;r2=on");
else
record_route_preset("$fd:5061;transport=tls;r2=on","MY_IP:5060;r2=on");
return(1);
}
record_route();
}
John
On 2/21/23 11:04 AM, Daren FERREIRA wrote:
Hey John,
I made some more tests and, indeed, domain is well used by loose_route
my problem is:
On both cases, the most important informations are $socket_out and $du
I print on my log messages:
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
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
sip:myFQDN.com:5061;transport=tls;ftag=534123ce5a624b30b3cb9edd5806b8b7;lr;r2=on
- myFQDN.com <http://myFQDN.com>
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:
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>
My message has been blocked because of its length. Full log is
available on https://pastebin.com/tXKAJpeL
In short terms:
REPLY FROM $socket_out DU $du
"REPLY FROM tls:100.64.0.1:5061 DU
sip:myFQDN.com:5061;transport=tls;ftag=534123ce5a624b30b3cb9edd5806b8b7;lr;r2=on"
"REPLY FROM udp:100.64.0.1:5060 DU <null> »
Where we well see that $du is empty… (and in some cases $socket_out is
wrong).
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.
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?
Thank you
Le 21 févr. 2023 à 17:07, John Burke <[email protected]> a écrit :
Hey Daren
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?
I quickly looked up some notes:
<XIbHvx0c2a8RAZsn.png>
My memory could be wrong :) but IMO it's worth a quick shot.
I didn't see anything else special in the config for MS, besides what
the tutorial points out.
Regards,
*John Burke
*
On 2/21/23 9:28 AM, Daren FERREIRA wrote:
Hi John,
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.
Whatever I set, comparison is always made with IPs not FQDN.
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.
I wonder if the reason I face this problems is not because:
- 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?
- 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?
Maybe a mix of both…
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 ;-)
Thank you for you reply :-)
Le 21 févr. 2023 à 15:40, John Burke via Users
<[email protected]> a écrit :
Hey Daren,
Aliases should work I believe, however, you can also use the domain
module[1] to dynamically maintain “local” FQDNs.
[1] https://opensips.org/docs/modules/devel/domain.html
Sent from my iPhone
On Feb 21, 2023, at 8:33 AM, Daren FERREIRA
<[email protected]> wrote:
Hello,
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.
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"
This has never been a limitation until I had to work with
Microsoft TEAMS, that requires the use of FQDN in Route headers.
I tried using aliases, Route headers tags, and lots of other
things, without success…
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).
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).
Many people seems to use OpenSIPS successfully with TEAMS and
nobody seems to have publicly complained about such limitations on
forums.
I may have missed something, and so I wonder what can be done to
better work with Route headers.
Do anybody have any idea on what I may have missed?
Thank you for your advices and comments.
Daren
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Please be cautious! This email was sent from outside of Voxtelesys.
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
*Please be cautious!* This email was sent from outside of Voxtelesys.
--
*Please be cautious!* This email was sent from outside of Voxtelesys.
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
