Author Archives: Torren

About Torren

I'm a Microsoft Certified Solution Master for Communication, aka Skype for Business. As a consultant I work in all areas of SfB design, deployments, and support, with a particular focus on voice workloads, networking, and high availability.

Blocking Calls to the PSTN with Direct Routing

Posted on by
Reply

If you’re on Direct Routing, blocking calls is as “simple” as ensuring that there is no route to the destination in the Voice Routing Policy assigned to the user placing the call.

For example, if we have a voice usage for national calls that looks like this ^\+(1\d{10})$ then any call that matches +1xxxxxxxxxx (that’s ten x if you’re wondering) will be allowed through. Carrying on with our example from previous posts of blocking calls to the 425 area code, we could change the route pattern to

^(\+1((?!425)|(\d{3}))\d{7})$

And calls to the 425 area code would no longer match this entry. That regex looks a bit gnarly. The +1 will always need to be at the start. (?!425) means “not 425”. The | is an OR, and (\d{3}) is any 3 digits. This says “We need +1 then (Not 425 but any other 3 digits) then 7 more digits.

If you have multiple voice usages – perhaps for service numbers, national, and international – you should be able to modify only the voice route associated with the national usage to block calls to the 425 area code.

This will work because a call to +1425xxxxxxx wouldn’t match with other typical usages, like service numbers (2xx-8xx) or international (country codes other than +1). However, if you have a more complex setup of usages and routes, you will need to ensure that a route further down the ordered list of usages does not allow the call. That is because while usages are evaluated top-to-bottom, evaluation continues until a route match is successful AND the call completes OR until the list is exhausted.

If you have ^(\+1((?!425)|(\d{3})\d{7})$ route in a usage above ^(\+1(\d{10})$ then a call to the 425 area code would be blocked by the first usage but would match the second usage.

This will definitely catch people using (.*) as a catchall for international calls at the bottom of their usage list. This also means that you cannot simply create a usage and route that blocks a call and insert it into the list of usages above a rule that would allow it. Your exception/block must take place in the same route regex that would match and permit the call.

Blocking Calls to specific numbers on the PSTN: This solution is good, but may not bulletproof

Posted on by
Reply

If you need a “best effort” method to block external calls to specific numbers, but aren’t hugely concerned over whether the solution is perfect, there is an option that will work with Calling Plans, Direct Routing, and Operator Connect.

Teams Dial Plans normalize the number a user enters on the keypad (or clicks on), usually into E.164 format. This allows users to dial based on their habits versus adherence to the E164 format. For example, they might dial 425 555 1212 and Teams will normalize this into +14255551212 to actually place the call. We can take advantage of this for call blocking by creating dial plan normalization rules that translate the dialed number into something other than the proper E164 format.

For example, 425xxxxxxx might get translated into +11001234567. That number doesn’t exist under the number plan for the +1 country code, so the call will fail. (It’s technically invalid, there are no area codes beginning with “1” in the North American Numbering Plan. Yet anyway!).

If you build something like this out, note that the “test” field here won’t allow you to put a + in front. You’ll have to test without the + here, and then test with the + at the client level.

Notice that the rule has \+?1? in front of the condition. That will match a + or 1 if they’re present, but doesn’t require them to be there. This means that even if a user knows how to dial an E164 number, this method can still catch and block the call.

You could get trickier here and translate to an E164 number that belongs to one of your Teams endpoints, and users would wind up connecting to that Teams endpoint. You could use Teams Routing Rules to build a rule that would play a message to the caller if these numbers were dialed.

I did say above that this solution may not be bulletproof. It’s possible that a client may implement number normalization in such a manner that it won’t match on a number in E164 format, on the assumption that it’s already in E164 format so it does not need to be normalized.

This is also where I put on my consultant hat and talk about non-technical aspects. If you have a user who is routinely abusing your phone system, and there is not technical solution to the issue, you may need to implement non-technical measures – a trip to HR, a visit with the school principal, etc..

Blocking Calls to the PSTN

Posted on by
Reply

It’s common for an organization to want to restrict where a user or phone can call outside an organization, especially long distance tolled calls. There are a number of different ways to do this, with a variety of different administrative impacts.

If a user has calling plans, the first way would be to only license the account for domestic calling, versus domestic and international. If you do this, note that adding a Communications Credit license to the user will allow them to make international calls on a pay-as-you-go basis. You might want communications credits assigned to a Calling Plan user to allow them to continue to make outgoing calls once the “per user per month” pooled minutes expire. If that’s the case, you’ll need to implement an additional method discussed below.

Regardless of whether a user’s PSTN service is via Calling Plans, Operator Connect, or Direct Routing, you can restrict where they can call in Teams Admin Center:

Here, I can block outbound calling entirely with “Don’t allow”, permit international calling with “Any destination” or only to Karl’s own country/region with the middle option “In the same country or region as the organizer”.

The text here – specifically the word “organizer” – would lead you to believe that this is for dialout from meetings. However, it does also apply to PSTN calls Get-CsOnlineDialOutPolicy (SkypeForBusiness) | Microsoft Learn

Note that this restriction will apply regarding of Operator Connect, Direct Routing, or Calling Plans being the PSTN connectivity option for the user.

This isn’t a terribly granular capability. If you’re on Operator Connect, your operator may be able to do some extra screening for you. There are some other solutions that may work well, or at least well enough, for your scenario, in my next post.

Troubleshooting Emergency Location not displaying in the Teams Client

Posted on by
Reply

All Microsoft Teams clients are capable of using location information from the Network, OS, or User for emergency calls. When the network is the desired source of the location, there are 3 key places that need to be configured.

First, the Trusted IP Address. This address is used by the Teams client to understand if it is on your organization’s network, or outside/remote. Trusted IP Address is not used beyond that.

Second, the client’s IP address is checked about the subnets/supernets configured in the Network Topology to establish if there’s a match for a network topology site. If there is a match, the policies from that site are applied. For emergency calls, there is the Emergency Call Routing Policy, that establishes the route a call will take to reach emergency call takers if Direct Routing is being used, and there is the Emergency Calling Policy to configure notifications.[1] There is one more policy not related to emergency calling, and that’s the Roaming Policy, which you can read about here.

Third, the client’s IP address and BSSID for wireless, and IP address, switch chassis, and switch port for wired, are compared against the LIS database. LIS stands for Location Information Services, and its job is to match your network information to the various places in your organization that first responders should respond to.

Ultimately, the goal is to have the correct location displayed in the user’s Teams client. This location is what will be passed through to the SBC in the Emergency Call Routing Policy, and off to an emergency call taker. It’s not uncommon for an address to not appear, or for the wrong address to appear, especially in new deployments. Fret not, there’s an easy way to see what’s happening.

Right click on the Teams icon in the systray – you may need to click on the ^ icon beside the clock to see it. Select “Collect Support Files”. You’ll see a flurry of activity as the client writes files to the downloads folder, and then zips them.

Grab that zip file and open it. We’re just reading a text file in the zip, so you don’t need to unzip and then find the file. Click on the folder called “web”, and then double click the file named “MSTeams Diagnostics Log 7_7_2022__9_31_02_PM_calling.txt” or similar, depending on the date/time you created the log file.

Search for the phrase “trustedIpMatchInfo”. That’s the actual case used in the file, but make life easy on yourself and make sure your search isn’t case sensitive. The first block you’ll see will look like this:

“debugInfo”: {
“ncsDebugInfo”: {
“trustedIpMatchInfo”: {
“publicIp”: “203.0.113.5”,
“reason”: “NotMatched”,
“_comment”: “Match Client Public IP to Tenant Trusted IP”
},

Here, the public IP shown is the public IP address that the Teams client used to connect to Teams. This IP needs to be in the “Trusted IP Address” list within Teams for the Teams client to be considered “internal”, and for the rest of the internal network policies to take effect.

The next section is used to apply policies if the Teams client is within a given site internal to the organization.

“siteMatchInfo”: {
“ipv4”: “192.168.20.107”,
“subnetLengthIPv4”: “24”,
“enableLocationBasedRouting”: false,
“reason”: “NotMatched”,
“_comment”: “Used to match endpoint subnet to Tenant site if trustedIpMatchInfo matches”
},

In this case, the LAN IP is 192.168.20.207. Even if there is a Network Site defined with this subnet, the policies for that Network Site will not apply since the Public IP/Trusted IP did not match.

Common policies applied based on the Network Site include Location Based Routing, Roaming Policies, Emergency Calling Policy, and Emergency Call Routing Policy. See this post for details.

The next section is used to establish the Teams Client’s location within the organization for emergency calling purposes.

“networkLocationMatchInfo”: {
“matchedNetworkType”: “CLS”,
“matchingIdentity”: “50.6583, -120.383”,
“ipv4”: “192.168.20.107”,
“reason”: “Matched”,
“_comment”: “Used to find emergency address, against Tenant Location Network Information (LIS), otherwise against Client Geo Location Information (CLS) if available”
}
},

Note here that my LAN IP did match against the LIS database, however Teams would not use this information for my emergency location as my Public IP didn’t match. There’s no way for Teams to know that I’m not in a coffee shop or at home with the same 192.168.20.0/24 subnet as the office.

For the Teams client to “find” your location for emergency calling, ideally all 3 of the above should result in “Matched”: The client’s public IP must be in the Trusted IP Address list, the NetworkLocationMatchInfo must find your IP subnet, wireless BSSID, Switch chassis ID, or switch Chassis ID and port name in the LIS database. You don’t necessarily need to have “matched” for the Network Location section, as you could have valid Global policies that would apply, or perhaps user-level policies assigned to the user. That may be the case in a very small organizationwith just one location, but would indicate a bad design in a larger organization with multiple locations.

Can I have a Common Area Phone account on more than one device?

Posted on by
Reply

Common Area Phones (2023 update: still called Common Area Phones, but the license is now a “Shared Device License”) are great for a variety of use cases. I see them typically used as a public area phone, such as a lobby courtesy phone, or as a common area phone that’s not publicly accessible, such as in a lunchroom, server room, or as an emergency phone in an area that doesn’t have any other telephones available for emergency calls.

Another use case that’s a bit less common is when the CAP is used for a role rather than a person. For example, a security desk might have a CAP phone or two on the desk, since there are so many different people rotating in and out of the security office who may answer a call. Where more than one CAP is to be deployed in scenarios like this, I often get asked if each CAP must be its own account, phone number, and license, or whether a single CAP account, phone number, and license can be shared between a few devices.

The answer is yes, you can absolutely share a CAP account, number, and license across multiple devices. This can keep your costs down, and also simplifies deployment. How? If you have CAP1, CAP2, CAP3, and CAP4 as four physical phones in a security office, each with their own number, you would need to also have a Call Queue with the “security office” phone number assigned to it. Then, you’d need to configure the CAP1-4 accounts to place outbound calls with the caller ID of the Call Queue. There’s no need for Call Queue and Caller ID policy if all 4 phones use the same account.

There are some disadvantages to this approach, however. First, if you don’t have a Call Queue, you can’t add other users into it so they can also field calls to the security line. The security supervisor might be one such person I would add. Second, if you have a Call Queue, users will be held in the queue when all agents are busy. With the share-CAP model, they would just ring, and there would be no opportunity for a message to be played. Third, there’s less logging and tracing capability to review what phone (and perhaps user) did what, when.

You should also be aware that by default, users who are on a call on a shared-CAP phone will still ring and be presented with the next call on their screen. Trying to block this with “busy on busy” functions may mess with the ability of the other phones to be offered the call. Further, in a security scenario, the security staff may want to see the caller ID/toast display of the next incoming call. “Blue emergency phone” on the toast notification would take a higher priority than an ongoing conversation with someone asking about a parking ticket, for example.

And lastly, if the phones are in different physical locations – strung down a hallway, for example, they may be in different Emergency Response Locations. This would mean that you would need to use Teams Certified devices and dynamic e911 to ensure the phones reported their proper “dispatchable location” in accordance with Ray Baum’s act in the US… but this is a worthy consideration for any country.

Emergency Calling: Trusted IP Addresses

Posted on by
Reply

When you’re configuring Microsoft Teams emergency calling, there are two end-user experiences. One is where Teams automatically establishes where the user is, based on network information that you’ve configured in Teams. The other is where the client depends on the OS location services and/or the user for a physical address.

For Teams to automatically establish your location, there are a number of pieces of network information that are required. The first of these is what Teams calls a “Trusted IP Address”. That’s maybe not the clearest name, but to be fair the name would get pretty huge if it was any more description.

A Trusted IP Address is any of your organizations public IP addresses that are dedicated, typically statically assigned. When a Teams client accesses Teams using one of these public IPs, Teams can trust that your client is inside your network. There are a few key points here:

Dedicated – The address cannot be shared like some cloud security services do, nor can it be dynamic and change at the whim of your ISP. Fixed IP addresses are typical, though we do sometimes see DHCP assigned “fixed” addresses.

Any – Yes any. Configure the entire range in Teams, not just one IP that clients typically use. This saves your bacon should the firewall guys change which IP clients egress from. It also means you’re covered if someone does something weird like plugging a phone into the server VLAN in the server room.

Trusted IP addresses are configured in TAC under Locations, Network Topology, Trusted IPs. If you click add, the dialog looks something like this:

Pretty straight forward! In the description field, put something meaningful to human. This has nothing to do with your location for emergency calling, but something meaningful like I’ve shown above is very helpful once you have more than one Trusted IP range.

If you’re a PowerShell fan, check out New-CsTenantTrustedIPAddress.

Note that your organization may already have assembled a nice list of these addresses in Azure for Named Locations in the MFA/Condition Access settings. You can spot-test if you’ve got an address in your list by having someone in a site browse to https://www.whatismyip.com. If their public IP address isn’t listed as a Trusted IP Address, you should first investigate if it meets the “dedicated” criteria above, then add it to the Trusted IP Address list.

I’ve been asked “If we monitor our dynamic public IP address for changes, can’t we just have a script run to update that in Teams?”. Well yes you could, except there will be a period of time for the IP change to work its way through Teams and down to all of the clients that require it. So, don’t do this. Instead, sites with dynamic public IP addresses will need to use the “work from home” or “External location lookup mode” as it’s more properly called. I’ve already posted a bit about this function, stay tuned for more.

Requirements for and Constraints of Site based Teams Policies

Posted on by
Reply

If you need to implement Site Based policies in Teams, there are several pre-requisites and design decisions that you need to be aware of and consider in your design.

If you are in Canada, the United States, or India then this absolutely applies to you. If you are in any other location, it probably applies to you unless you are a very small Teams deployment in a single office.

Here’s a list of the site based policies in Teams:

  • Location Based Routing
  • Emergency Call Routing Policy
  • Emergency Calling Policy
  • Local Media Optimization
  • Roaming Policies

Location Based Routing

Location Based Routing is mostly used in India, though there are a few other scenarios where it may be useful. The general idea here is that you can’t mix IP based calls/meetings with more than one PSTN site.

Emergency Call Routing Policy

This policy controls where Teams will route emergency calls to when using dynamic emergency calling for Direct Routing and Operator Connect scenarios. You use dynamic emergency calling in Canada and the US by law, and it make sense to me to use it in other locations as well.

Emergency Calling Policy

This should really be called the Emergency Call Notification Policy. When an emergency call is placed from a site, this policy controls who is notified via IM, who is conferences in by phone, and whether the phone call is muted or unmuted (you should ALWAYS configure muted, you do not want to interfer with the emergency call taker getting the information they require).

Also tucked into this policy is “External location lookup mode”. I have yet to establish why this feature is in this policy. The External location lookup mode turns on the “work from home” location experience for mobiles and computers, to user the device’s native location services and/or user input to establish a location for emergency calls. If you have the network information for this policy to kick in for a site, you also have the network information to dynamically establish the caller’s location. Realistically, you need to turn on the External location lookup mode in an Emergency Calling Policy that is assigned to the user, so that it triggers when they’re outside of your organization. (Note: there is currently a bug where if you set the External location lookup mode on a global Emergency Calling Policy, it does not work. You need to assign the policy to each user individually).

Local Media Optimization

LMO allows a client device to send media directly to the inside interface of an SBC, avoid travelling up to Teams and back down. The previous couple of posts here cover LMO.

Roaming Policies

Here’s another policy name that doesn’t make sense to me. Roaming Policies apply bandwidth restrictions to users that are present in a site, replacing the same two parameters that are in the policy that is assigned to the user. In the SfB world, this was called Call Admission Control, and was handled in an entirely different fashion.

Requirements

The requirements for these site based policies to trigger are:

First, the client must egress to the Internet that is static, and dedicated to the organization. This is generally the IPv4 address that the client NATs to, but it could be an IPv6 address or an IPv4 address assigned to the device that isn’t NAT’d. These addresses are called Trusted IPs.

Second, you must define a Network Site under Locations > Network Topology and assign the subnets in use at this site to the Network Site.

Constraints

There are some technical constraints to these requirements.

For the Trusted IPs, static means that the IP address(es) do not change. A DHCP assigned address with a reservation is okay. If the address were to change, you would a way to be notified of this change, then you’ve have to update this information in Teams, then policies would have to replicate and be pulled by clients. That’s no good for emergency calling, and isn’t that great for other scenarios either.

Also for the Trusted IPs, dedicated to the organization means that you can’t use cloud proxy/firewall services such as those provided by zScaler, and the address could be shared between multiple organizations and the address(es) assigned to your clients may change.

For the Network Sites, the subnets must be assigned to only one site. You cannot have a subnet assigned to or spanning multiple sites. If you need your sites to be more granular that your subnets permit, you will need to resubnet. A typical place this happens is with centralized wifi controllers that lay one very large subnet over an entire organization.

There is also a large design constraint to be aware of. These five policies (above) are typically assigned to sites. You define the site, then assign the policies to the site. You do not get to define different sites for different policy types.

Let’s use an example to clarify that. A university campus has several buildings in a campus, and you’d like to set the same LMO policy and Emergency Call Routing policy to the entire campus. That makes sense, the whole campus is probably served by the same PSTN service, and likely needs to send all emergency calls to the same spot. Plus, the university has a wifi system that uses a large /20 subnet for the entire campus. You can define the entire campus as one site and meet these objectives (sorry for making this sound like a certification exam!)

However, in the US Kari’s law states that you must notify someone within the building with the details of any emergency call from that building. You need one Emergency Calling Policy for each building. This means that you must define each building as a site, and you must break the wifi subnet up into smaller subnets that only belong to one building. You don’t need multiple Emergency Call Routing policies though, you can assign the same “campus” policy to each site.

This type of scenario makes network engineers scream, and threatens to delay the project until they can sort the wifi. As an interim measure, I have seen some organizations configure each building as a site and assign the wired subnets to them. They then assign the giant wifi subnet to a “campus wifi” site, and configure an Emergency Calling Policy to notify staff who can relay the notification information to the appropriate parties. Don’t make a decision to do this on your own, you are not a lawyer (probably). Give this decision to your legal/risk/executives to deal with.

LMO with Proxie’d Sites. When do you need it?

Posted on by
Reply

In the previous two posts I’ve talked about Media Bypass and Local Media Optimization. In general, I don’t feel that the effort to configure those is dignified by quality gains that you may see… and you may not see, or you may make your call quality worse.

However, there is a more complex LMO scenario that involves two levels of SBCs in a hierarchy. The “spoke” or “remote” sites proxy to Teams through the main SBC. Microsoft provides this diagram on the docs page for this

As an aside, I very much dislike that 172.16.240.x is used as an example public IP or Trusted IP. RFC 5737 provides 3 example IP ranges. It’s technically impossible to have an RFC 1918 private/non-routable/internal only IP as your Trusted IP. This diagram is terribly confusing, especially when you start working with network and security teams, so ensure that you explain that they’re meant as example public IP addresses in this diagram.

Now then, on to LMO. We have two “remote” or “spoke” sites here, Indonesia and Vietnam. Vietnam has a PSTN connection and Indonesia does not. Neither Vietnam nor Indonesia SBCs are configured for Direct Routing directly to Teams. This could be because of poor Internet in those locations (either in terms of bandwidth or the ability to get enough static IPs that can be used as trusted IPs), or it could be a desire to limit the number of FQDNs and certificates required – though you could use a wildcard for all of the SBCs in the organization to achieve this too.

The SBCs in Vietnam and Indonesia proxy through the Singapore SBC. The Teams client, the Teams Direct Routing service, and the SBC sort out what path the media should take based on:

  • What site the user device/client is in
  • What site the SBC with the PSTN connection is in
  • What Proxy SBC is set for that SBC (or if it is the Proxy SBC)
  • What bypass mode the SBC is configured for (Always, or Only for local users)

The “remote”/”spoke” SBCs have an extra field that needs to be configured

which is the Proxy SBC.

The Verdict

Now, I’m not going to dive deeper into the technical bits of how this works and how you would configure it, because we’d honestly be here for months. If you are considering an LMO deployment that uses proxy SBC(s) and have not successfully done that before, then I implore you to reach out to a partner that has, and to involve your SBC vendor in that process as well. One does not simply turn on proxy scenario LMO and go home on time.

A Gotcha

I do need to include a gotcha here that will affect proxy scenario LMO design. For Teams to identify your client as being in a site, that client MUST egress to the Internet with a trusted IP address (recall that this is dedicated to your organization and static). If your reason for looking at proxy scenario LMO is because you can’t obtain a dedicated and static IP address in your remote/spoke site for Direct Routing, then you won’t be able to do LMO (or any other Site based Policy feature of Teams) at that site UNLESS you route traffic to Teams out via a site that does have a dedicated/static IP address.


Local Media Optimization – Do you need it?

Posted on by
Reply

In my previous two posts, I give an intro to Media Bypass and Local Media Optimization, with the end goal of determining if you need them or not.

Local Media Optimization (LMO) at its core is similar to Media Bypass, except your device connects directly to the inside interface of the SBC and not the outside interface. That’s good in some ways, but does add some complexities of its own.

First, we don’t need to worry about firewall hairpinning or having to battle the security guys to open up the outside interface. We only ever talk to the inside interface, and thus only internal clients can do LMO. However, it’s only the outside interface that has an FQDN, so we need some other way of establishing where the SBC is, and how we connect to it. And that’s a bit of work.

In Teams Admin Center (TAC), under tLocation > Network Topology

you specify two important components for this, The first is Trusted IP Addresses, which are the IP addresses your clients are NAT’d to when they access Teams (or your entire IPv6 range if you’re one of the cool kids doing that). This lets the client understand if it’s “internal” on your network or external. That leads to a couple of requirements – you need to have static IP address(es) assigned only to you. No cloud-based shared proxy services like zScaler offers, and no dynamic addresses (DHCP assigned addresses with a reservation are fine). If your client doesn’t egress to the Internet with an IP that meets these requirements, it will not be identified as internal to your network and will not be able to do LMO.

The second part in TAC that you need to be concerned with is under Locations, Network Topology, Network Sites. This is the section where you identify sites in your network and what subnets are present at each site. This is used for the client to identify where it is within your organization, and thus which location based policies (of which LMO is one) apply and where.

There’s a third part that you need to do as well, and that’s in the configuration for the SBC. In TAC under Voice > Direct Routing click on the SBC, the select Settings, the Edit

For LMO you need to configure a couple of things. First, Gateway Site ID is the site that you configured above, that the SBC belongs to. SBCs are made by many vendors, and don’t have enough Teams client bits baked into them to establish what site they’re in based on IP address, so you have to specify it here.

The next part you need to configure is Bypass Mode – even though this is LMO and not Media Bypass. There are two options here, Always, and Only for local users. Always will attempt to do LMO for all clients, and fall back to default media paths if that fails. Only for local users will only attempt to do LMO if the user’s device is in the same site (that you defined above) as the SBC.

And lastly, you need to turn on “Media Bypass” even though we’re doing LMO. If you’ve read my previous post on Media Bypass and don’t want to do it, that’s fine. You won’t magically be doing it by turning this on unless you also configure your firewall.

Your SBC vendor will also have a bunch of configuration steps to take on the SBC to enable LMO.

Your device and the SBC should now be doing LMO.

SBC isn’t in your site

To be clear, here “site” means “your organizations premises” and not the Network Site that can be configured in TAC (that is the Bypass Mode of “always” or “only for local users”.

Moreso than with Media Bypass, LMO makes little sense to configure in hosted scenarios. First, you’d need to establish a network connection from your LAN(s) to the inside interface of the SBC, so now you’re firing up VPNs and dealing with datacentre or Azure networking, and… that makes no sense to go through that effort to get the traffic to the SBC.

LMO is also not applicable to Direct Routing as a Service scenarios. No DRaaS vendor in their right mind would setup an inside interface and take on the burden of LMO configuration on their SBCs, even if you paid them lots of money.

The Verdict

But wait you say, I’ve only cover basic LMO configuration. Yes, just one SBC, and users on the inside. We’ll dive into the more advanced “proxy” or hierarchical LMO deployment in the next post.

My recommendations are two-fold here. First, if you have excellent WAN bandwidth for users from any site to be able to place calls via the SBC you’re configuring LMO for, go ahead if you want to try it out. It’s probably going to be rare that you have run into a scenario where you have so many users in France who are trying to call Australian PSTN numbers via the SBC in Australia that you will need to be concerned about bandwidth consumption in “Always Bypass” mode. If this is the case, then flip the mode for this SBC to “Only for local users”.

Second, my recommendation for Media Bypass also applies here. If you’re not seeing call quality issues, then it may not make sense to go through the hassle of configuring LMO within Teams (well, it’s not that big of a deal) and in the SBC (this is more of a big deal, it can be messy and confusing). If you think you may benefit from LMO, and you have enough data in CQD for a baseline to compare against, go ahead and turn on LMO.

TL;DR – you probably don’t need to do Media Bypass or this basic form of LMO unless you have some weird network capacity constraints and topologies.

Up next, we’ll touch on the Proxy configuration for LMO

Media Bypass – Do you need it?

Posted on by
Reply

In my last post I gave an overview of Media Bypass in Lync/SfB and Teams, as well as the new Local Media Optimization functionality. In this post I’ll dive into Media Bypass, and we’ll save LMO for the next post.

First things first – this is MEDIA Bypass. It’s just the media that we’re messing with, not the signaling. Signaling will always involve Teams and the SBC.

Without Media Bypass, our traffic looks like this:

Media Bypass involves sending media from your Teams endpoint directly to the outside interface of the SBC. That media will come from two places, the Internet if you’re remote, or the LAN if you’re inside your organization’s network.

Remote

If you’re remote, your media path looks like this:

This looks nice and simple. The remote client can find the outside of the SBC since we have an FQDN, DNS, firewall rules, and certificate already in place for the Direct Routing connection. What we don’t have though are firewall rules to allow traffic from the remote users to the SBC. That is an “any” as the source, and most security teams are hesitant to permit that. If they don’t allow this, you could still permit your own public IP ranges so your LAN users can take advantage of Media Bypass. If the Teams client tries Media Bypass the connection directly to the SBC would fail and the default path (above) through Teams would be used – but do read on!

There’s another point to consider here, and that’s the difference in the network path between a remote user reaching your SBC directly, and a remote user reaching your SBC through the Teams cloud/Microsoft infrastructure. Chances are that your remote staff are at home, a coffee shop, or a hotel. Something with a general purpose, consumer grade Internet service. Their media would traverse that link and the general purpose Internet to reach the SBC. If their traffic took the default path, it would enjoy a smooth and luxurious ride on the Microsoft network, appropriate prioritized as Teams voice traffic. Having Media Bypass turned on may not actually benefit their call quality,

Why a nice ride on the Microsoft network/ Microsoft has an amazingly large, fast, high quality global network that peers with ISPs early and often. For quality, they want Azure/M365 bound traffic on their network as soon as possible. This also gives Microsoft the ability to place Teams resources in locations other than major Microsoft datacentres. Everything is microservices after all, so your media traffic may not be flowing from your client to a major datacenter then down to your SBC.

Internal

If you’re on your organization’s LAN, your Media Bypass connection looks like this:

We need to do some pretty funky firewall hairpinning here to make this work. It’s easy enough to permit your own IP ranges back in through your firewall, but a lot of firewalls don’t like accepting traffic inbound if that traffic has just egressed – it just doesn’t seem normal or right. Some firewalls can’t even do this, period. Make sure you shut off deep packet/application aware everything, because it won’t be useful to your security posture and will just clobber your traffic and generate helpdesk tickets.
In this scenario, you should also consider the bandwidth being consumed by the media traversing the firewall and Internet twice. This shouldn’t be spectacularly high and may not be an issue, but it is something to consider.
This is a better scenario that the outside user in terms of potential call quality improvements, since there’s no external traffic at all.

SBC isn’t in your site

There’s another factor of Direct Routing to consider here as well. If your SBC is not in your own building (ideally the same one as those light blue users), you are in a scenario that’s very close to the remote user scenario – your traffic needs to traverse the Internet or Microsoft’s network to reach the SBC, and Microsoft’s network is probably better. If your SBC is hosted in Azure, then the traffic doesn’t need to leave the Microsoft network.

If you as using a Direct Routing as a Service provider, Media Bypass is likely not available to you as an option – the setup and complications would consume too much time.

The Verdict

Given the above, what should you do? My recommendation is that you NOT enable Media Bypass. Leave media paths at their defaults, and monitor your call quality through the Call Quality Dashboard. If you are seeing results in CQD that indicate you may benefit from Media Bypass for external users, turn it on and see if there’s a change (and if things improve, drop a comment below as this is, in my experience, rare). If you see results in CQD that indicate you may benefit from Media Bypass for your internal users, don’t implement Media Bypass, but instead read my next post on LMO.