Forum Discussion
Local Media Optimization for Direct Routing _ firewall\transport relay question
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
- Allowing traffic to the SBC just from MS is one thing
- Allowing traffic to the SBC from any external is more interesting!
Is there an example firewall rule for this?
Any advice welcome
Don'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)
- In this scenario a Teams user that is outside of the corporate network would be able to send/receive RTP packets directly to the IP address associated with the SBC, specially the public IP address.
- In this scenario a Teams user that is inside the corporate network would be able to send/receive RTP packets directly to the IP address associated with the SBC, specially the public IP address.
- In this flow scenario the SBC sees RTP traffic coming from your client's NAT'd public IP address.
Direct Routing with Media Bypass (Upstream Firewall Restricted to MSFT IPs)
- In this scenario a Teams user that is outside of the corporate network would not be able to send/receive RTP packets directly to the IP address associated with the SBC, specially the public IP address. Since the RTP flows are blocked the client must establish traffic to the MSFT Transport Relays, which then communicate with the SBC IP address.
- In this scenario a Teams user that is inside the corporate network would not be able to send/receive RTP packets directly to the IP address associated with the SBC, specially the public IP address. Since the RTP flows are blocked the client must establish traffic to the MSFT Transport Relays, which then communicate with the SBC IP address.
Direct Routing with Media Bypass (Upstream Firewall but No Restrictions)
- In this scenario a Teams user that is outside of the corporate network would be able to send/receive RTP packets directly to the IP address associated with the SBC, specially the public IP address.
- In this scenario a Teams user that is inside the corporate network would be able to send/receive RTP packets directly to the IP address associated with the SBC, specially the public IP address.
- In this flow scenario the SBC sees RTP traffic coming from your client's NAT'd public IP address.
Direct Routing with Local Media Optimization (No Firewall)
- In this scenario a Teams user that is inside the corporate network would be able to send/receive RTP packets to the IP address associated with the SBC, specially the internal IP address.
- In this flow scenario the SBC sees traffic coming from your client's internal IP address (likely RFC 1918).
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.
4 Replies
Don'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)
- In this scenario a Teams user that is outside of the corporate network would be able to send/receive RTP packets directly to the IP address associated with the SBC, specially the public IP address.
- In this scenario a Teams user that is inside the corporate network would be able to send/receive RTP packets directly to the IP address associated with the SBC, specially the public IP address.
- In this flow scenario the SBC sees RTP traffic coming from your client's NAT'd public IP address.
Direct Routing with Media Bypass (Upstream Firewall Restricted to MSFT IPs)
- In this scenario a Teams user that is outside of the corporate network would not be able to send/receive RTP packets directly to the IP address associated with the SBC, specially the public IP address. Since the RTP flows are blocked the client must establish traffic to the MSFT Transport Relays, which then communicate with the SBC IP address.
- In this scenario a Teams user that is inside the corporate network would not be able to send/receive RTP packets directly to the IP address associated with the SBC, specially the public IP address. Since the RTP flows are blocked the client must establish traffic to the MSFT Transport Relays, which then communicate with the SBC IP address.
Direct Routing with Media Bypass (Upstream Firewall but No Restrictions)
- In this scenario a Teams user that is outside of the corporate network would be able to send/receive RTP packets directly to the IP address associated with the SBC, specially the public IP address.
- In this scenario a Teams user that is inside the corporate network would be able to send/receive RTP packets directly to the IP address associated with the SBC, specially the public IP address.
- In this flow scenario the SBC sees RTP traffic coming from your client's NAT'd public IP address.
Direct Routing with Local Media Optimization (No Firewall)
- In this scenario a Teams user that is inside the corporate network would be able to send/receive RTP packets to the IP address associated with the SBC, specially the internal IP address.
- In this flow scenario the SBC sees traffic coming from your client's internal IP address (likely RFC 1918).
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.
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.
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:
