Skip to main content

Microsoft

Direct Routing March 2019 Updates (Part 2 of 5)

Welcome back to the second blog in our “Direct Routing March 2019 Updates” blog series. Last time we talked about what exactly Direct Routing is, how it can benefit your organization, and about certain considerations that you should account for before implementing Direct Routing. This time, take a look at what’s under the hood by discussing Direct Routing flows.

Direct Routing Flows

Signaling

In the diagram below you will see the Office 365 global network in your upper left-hand corner. The global network is run by Microsoft and provides users with a great quality connection to Office 365. In the middle you’ll see that we have the public Internet and lastly on the bottom we have the corporate network. Users can either connect via the Internet (if connecting from outside the corporate network) or from your corporate network (if internal) to Office 365.

 

If we are connecting from the Internet, the signaling will be sent directly to the CC (Cloud Controller) in the Office 365 global network. Similarly, if a user connects via the corporate network their flow will look the same in that the signaling traffic will travel to the CC. In both scenarios the CC will communicate with the SIP Proxy (SP) in Office 365. Lastly, the SP will exchange signaling with the Session Border Controller (SBC) via SIP. If you are unfamiliar with the innerworkings of an SBC, you can think of this piece of equipment as a call router. The SBC will sit on your corporate network and as calls are placed/received there is signaling from the CC to the SP and then on to the SBC where the call is established. Lastly, your SBC will communicate with the PSTN next hop (on-premises phone system or PSTN trunk).

Media

As you may have noticed with signaling, the flows are pretty much the same regardless of where you reside on the network (internal vs external). However, media is a tad different and a bit trickier since the media flow will differ depending on the circumstance. The first component we will introduce (as seen in the diagram below) will be the Media Processor (MP). The MP is responsible for transcoding media from one codec to another so the SBC can understand the Teams client. These MP’s are located in the Microsoft datacenters in NA, EU, APAC, and Japan. The second component is called the Transport Relay (TR). The TR is responsible for relaying real time media in a scenario where a direct connection is not possible. This is the sole purpose of the TR, so it won’t be doing any additional activities with the media. So, if there are two endpoints that want to talk to one another, but they can’t communicate due to a firewall in between them, they would just send their media to the TR and then the TR will relay it. TR’s are deployed worldwide and not just in the main Microsoft datacenters.

 

To dig into this a little deeper, we can have three different scenarios for media flows in Direct Routing:

  • No media bypass
  • Internal Media Bypass
  • External Media Bypass (Direct)
  • External Media Bypass (via Transport Relay)

No Media Bypass

Without media bypass enabled the traffic would take this route:

  1. Media traffic sent directly to Office 365 Media Processor
  2. Public internet will be utilized for the short leg over the internet until it reaches the global Office 365 network
  3.  Once on the Office 365 network the traffic will be optimized for Microsoft Teams
  4.  The MP (Media Processor) transcodes the call
  5. Traffic from the MP will flow back over the Office 365 network and over the short leg of the internet until it reaches the SBC
  6. From the SBC media traffic will go out to the PSTN next hop

Internal Media Bypass

With media bypass enabled users on the corporate network would take this route:

  1. Media bypass requires users to send their media traffic directly to the public IP address of the SBC
  2. Traffic will stay internal to the corporate network until it reaches the SBC
  3. From the SBC media traffic will go out to the PSTN next hop

IMPORTANT: Be sure to allow this “hairpin” on your network and firewall. If the “hairpin” is blocked, traffic will flow via the Transport Relay

This means that traffic stays internal to the corporate network thus it will never need to go out over the internet to the global Office 365 network and then on to the MP. By sending the media directly to the SBC you eliminate multiple unnecessary hops for your media resulting in reduced latency for your end users. In addition, you will have 100% management over your traffic since everything is done internally thus you won’t need to worry about relying on your ISP to ensure a good connection for your users.

External Media Bypass (Direct)

With media bypass enabled users outside of the corporate network would take this route:

  1. Media bypass requires users to send their media directly to the public IP address of the SBC
  2. Traffic will flow over the public internet but will not traverse the global Office 365 network until it reaches the SBC
  3.  From the SBC media traffic will go out to the PSTN next hop

IMPORTANT: Be sure your firewall allows incoming traffic to the media ports on the SBC rom any** IP to the SBC. 

**When we say any IP, we mean that users could be sitting anywhere in the world on the internet. Also when we say any source IP, this is due to NAT between the user and SBC which changes the source address of where traffic is coming from. So client traffic may have any IP or any port.

External Media Bypass (via Transport Relay)

With media bypass enabled users whom cannot connect directly to the SBC would take the following route:

  1. Since media traffic cannot travel directly to the public IP of the SBC, instead it will traverse the global Office 365 network and leverage the Transport Relay (TR)
  2. The TR will only relay the traffic, it will not manipulate/transcode the media in any way. TR’s are deployed worldwide so there is a good chance a TR will be deployed close to the user
  3. From the TR the media traffic will be relayed over the global Office 365 network to the SBC on your corporate network
  4. From the SBC media traffic will go out to the PSTN next hop

IMPORTANT: Be sure your firewall allows incoming traffic from Office 365 on specific IP’s and ports

Recommendations for Media Bypass

When enabling media bypass in your environment you should consider the following:

  • Results of media bypass may vary based upon location of your endpoints and SBC’s
  • Results of media bypass may vary based upon your proximity

In addition, you should remember these following rules of thumb:

  • For internal endpoints
    • Allow connection directly to the SBC by keeping traffic internal to the network and avoiding detours via the global Office 365 network
  • For external endpoints
    • Block direct connections from your external endpoints and SBC to force traffic over the Office 365 network and minimize the use of the public internet

Summary

Since we’ve covered a fair amount of content in this article, let’s quickly summarize everything:

  • Media Processor (MP)
    • Calls WITHOUT Media Bypass will ALWAYS travel via the Media Processor (MP)
    • Calls WITH Media Bypass will NEVER travel ia Media Processor (MP)
      • Media Processors are deployed in the main datacenters
  • Transport Relay (TR)
    • Calls WITH Media Bypass might travel via TR
    • TR’s are deployed much closer to end users
    • Direct traffic between end point and SBC will NEVER use Office 365 network
    • Traffic between end point and TR will leverage the Office 365 network

This concludes today’s blog article on Microsoft Teams Direct Routing flows. In the next article we’ll cover the aspect of voice routing for Direct Routing. If you are interested in checking out the official video on this topic, I encourage you to check out the “Coffee in the Cloud” series.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Brian Siefferman

Brian is a Technical Consultant for Perficient’s Unified Communications practice focusing primarily on Skype for Business and Microsoft Teams workloads. He has been in this role since December 2017 and has an active presence blogging about all things Teams related. Currently, Brian resides in the suburbs of Chicago and enjoys running, swimming, weight lifting, and playing soccer in his free time.

More from this Author

Follow Us