Jun 22 2020 08:19 AM
Local Media Optimization for Direct Routing _ firewall\transport relay question
When a user is "external" ie not on the corporate network
Does media always flow via the public IP of the SBC?
OR as per media bypass with Direct Routing _ is it supported to route traffic via the transport relay?
The reason for asking is looking at the firewall rules and talking to the digital security team
Is there an example firewall rule for this?
Any advice welcome
Jun 22 2020 10:10 AM
SolutionDon't confuse Media Bypass with Local Media Optimization... The two items are technically separate and independent technologies, although they are complimentary in certain forms.
Direct Routing with Media Bypass (No Upstream Firewall)
Direct Routing with Media Bypass (Upstream Firewall Restricted to MSFT IPs)
Direct Routing with Media Bypass (Upstream Firewall but No Restrictions)
Direct Routing with Local Media Optimization (No Firewall)
In this scenario a Teams user that is outside of the corporate network would be able to send/receive RTP packets to the IP address associated with the SBC, specially the public IP address.
LMO removes the restriction of internal users having to send RTP streams externally, which was a requirement in a "normal" Direct Routing with Media Bypass configurations.
SBCs are voice-specific firewalls and when configured appropriately, exposing the SBC to the public Internet as a whole is not an issue. I generally don't recommend any level of firewall insertion or restrictions for Direct Routing unless there are extreme circumstances that require. The addition of the firewall not only could complicate troubleshooting, but adds a layer of complexity and potential latency if the firewall is wrongly configured for deep-packet inspection. Use the firewall ACLs on the SBCs themselves, if need be.
Jun 22 2020 12:22 PM
thank you for the long reply.
However to be clear.
1.Are you saying that the only media path with lmo, for an external client is to the public ip of the sbc?
2. Relay via the Teams transport relay is not supported?
Your comments about exposing the sbc to the internet seem to be bold, but really I am only after clarification on the points above.
Jun 22 2020 01:19 PM
LMO and media bypass are not the same thing. LMO only impacts internal clients and is only applicable when the Direct Routing components & SBC are configured to support LMO. The addition of LMO does not change any RTP flows for external clients since it is not applicable to that topology.
Regardless of media bypass configuration, LMO configuration, and client location (internal vs external), Transport Relays are always an available path for RTP streams:
Sep 21 2020 01:53 PM
@rovert506 do you know where the Transport Relays are located? I'm trying to find a list from Microsoft of the TRAP geo locations but drawing a blank. We're deploying Teams DR in South America (Uruguay) and hitting US East & West Media Processors. About to enable bypass, but wanted to know where our calls could hit.
Jun 22 2020 10:10 AM
SolutionDon't confuse Media Bypass with Local Media Optimization... The two items are technically separate and independent technologies, although they are complimentary in certain forms.
Direct Routing with Media Bypass (No Upstream Firewall)
Direct Routing with Media Bypass (Upstream Firewall Restricted to MSFT IPs)
Direct Routing with Media Bypass (Upstream Firewall but No Restrictions)
Direct Routing with Local Media Optimization (No Firewall)
In this scenario a Teams user that is outside of the corporate network would be able to send/receive RTP packets to the IP address associated with the SBC, specially the public IP address.
LMO removes the restriction of internal users having to send RTP streams externally, which was a requirement in a "normal" Direct Routing with Media Bypass configurations.
SBCs are voice-specific firewalls and when configured appropriately, exposing the SBC to the public Internet as a whole is not an issue. I generally don't recommend any level of firewall insertion or restrictions for Direct Routing unless there are extreme circumstances that require. The addition of the firewall not only could complicate troubleshooting, but adds a layer of complexity and potential latency if the firewall is wrongly configured for deep-packet inspection. Use the firewall ACLs on the SBCs themselves, if need be.