[OpenSIPS-Users] OpenSIPS and Teams - Route headers and FQDN
Daren FERREIRA
darencrew at hotmail.com
Wed Feb 22 18:38:43 UTC 2023
Hi John,
I use the same record_route_preset() commands on my setup.
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.
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.
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.
So, it tried to use Route headers to find the socket and destination URI to use to forward the requests.
- 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.
- 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"
With incorrect contact, and so incorrect RURI, not being to solve socket and destination URI was a problem.
Now RURI is correct, it is used as is, and requests are forwarded to the next hop.
« 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.
The matching failure is no more a (real) issue for things to work.
There are probably things to do to improve the routines in order the warning not to appear anymore but
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.
Anyway, thank you John for trying to help me solve my issue.
Regards
Daren
> Le 22 févr. 2023 à 17:31, John Burke <john at voxtelesys.com> a écrit :
>
> 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 <john at voxtelesys.com> <mailto:john at voxtelesys.com> 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 <users at lists.opensips.org> <mailto:users at lists.opensips.org> 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 <darencrew at hotmail.com> <mailto:darencrew at hotmail.com> 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
>>>>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>>>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Please be cautious! This email was sent from outside of Voxtelesys.
>>>>> _______________________________________________
>>>>> Users mailing list
>>>>> Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>>>> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20230222/67e4cf13/attachment-0001.html>
More information about the Users
mailing list