Emergency Calling: Trusted IP Addresses

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

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.


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.


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?

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?

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?

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.


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.


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.

Media Bypass and Local Media Optimization – Do you need them?

Media Bypass has been around since Lync 2010, however the implementation in Teams is different in many regards. In Teams in comes in two flavours, Media Bypass and Local Media Optimization. In the next couple of posts, I’ll cover what these are, and why you might want or need to use them, and why you might not.

In Lync and SfB, the basic voice path is from the device to the Mediation server and then off to the gateway/SBC. Media Bypass allowed media to flow directly between the device and the gateway/SBC. There were two main reasons to do this:

  • To reduce load on the Mediation server.
  • To reduce WAN bandwidth usage by preventing tromboning of traffic to the Mediation server and back, in scenarios where the user and gateway are not located in the same site at the Mediation server.
  • Tromboning or hairpinning, is where traffic leaves a devices and proceeds to another, usually in a different site, and then returns to the original site

10+ years ago, these were serious considerations for organizations.

With Teams, we have a very different architecture. There aren’t any servers, and traffic to/from the PSTN doesn’t (usually) traverse the WAN. If it does, something is probably wrong if your media is tromboning through your WAN.

In Media Bypass for Teams, media traffic from a devices connects to the outside interface of a Session Border Controller (SBC). Local Media Optimization (LMO) allows traffic from the device to connect to the inside interface of the SBC. A more advanced configuration of LMO creates a 2-level hierarchy of SBCs that can help in scenarios where remote sites have no (or terrible) Internet, and when two remote sites have no direct WAN connectivity.

In the next post, I’ll dive into Teams Media Bypass.

Main Numbers – answered by technology or people

There are two main types of organizations that I come across when it comes to handling a main line. The first are those who strongly prefer a human to answer the calls, and the second are those that would rather have automation handle the call, with humans jumping in only when needed.

Either of these scenarios are easily achieved with Teams. For the first, I create a call queue and assign the main number to it. I have the receptionist(s) added as agents in the queue. I then setup an auto attendant, and user this as a destination for overflow and timeout actions from the queue. I include an option to press 0 to get back to the receptionist queue, in case the caller prefers that versus the options presented in the auto attendant. One of these options can be to leave a voicemail.

For the second scenario, implement the same auto attendant and call queue, but I assign the main number to the auto attendant.

A third scenario that I come across is usually only found in small offices or organizations. Here, the main number for the office is assigned to the receptionist as their personal number. I don’t like this for many reasons, including:

  • The receptionist can’t tell if the call is for them or the main number, and must always answer as if it’s an outside call to the organization.
  • Anyone who covers for the receptionist (too many calls, on a break, sick days, holidays) gets access to the receptionists phone and voicemail – and if this is Teams, everything else too.
  • It doesn’t scale if the organization grows
  • It can’t take advantage of ANY of the features of Teams (auto attendants, call queues, bots…) Sure, bots may be a stretch for a small org or office, but AA and CQ are not.

And so in this scenario, I assign a new number to the user and configure one of the other scenarios for the organization.

How to handle phones for roles rather than users

A question that I have a lot from organizations that I work with, is how to setup phone service for what I call “roles” versus “users”. For example, a factory shift supervisor. There’s always one on duty, and their shift lasts 8 hours, then the next one takes over. Someone in the organization who needs to reach that supervisor doesn’t want to have to consult a schedule or call 4 or 5 different numbers to reach the right person. Another example would be a security line (or two, one urgent/emergency and one administrative) for a security department. A third could be a main reception line versus the receptionists (and their relief) who staff it.

There are two ways to handle this type of scenario. The first is to create a user account or common area account for the “role”, drop a phone on the desk and you’re done. I like this solution when the staff involved aren’t information workers or don’t have their own network accounts at all – the security team, for example. This does require either a Common Area Phone or user license (depending on if you want the user level features that a Common Area Phone doesn’t offer, like voicemail).

The other solution is to create a call queue for the “role”, and have the staff be assigned as agents in the call queue. The staff can hot desk onto phones or logon to the Teams client on their computer, and can make and receive calls as either themselves or the “role”.

In more complex scenarios such as if the security team needs both administrative and emergency lines, the “role is a phone” solution doesn’t scale well. The Call Queue option works well here. Finally, you could also create a hybrid where there’s a desk phone as an agent in the call queue, so that there’s always a “bat phone” that can be picked up.

Call Queue – Call Routing and Agent Option Pain Points

The last two posts covered the options available for distributing calls to agents in a call queue. In the first of those, I mentioned that there are some gotchas that can cause you some pain. Let’s cover those, and provide a few tips and tricks to make life easier.

Presence-based routing is a hot-topic for some of my colleagues. One has been bitten by having a Call Queue trigger the timeout action because no agents were available. Why? They were all either in meetings, or had populated their calendars, causing their presence to be “busy” or “in a meeting”. This could be a legitimate scenario and a good use of the overflow options (to another queue or to voicemail, perhaps), but is probably sub-optimal if all of your agents have items populated in their calendars. Perhaps they’re staff at a Microsoft partner and have their time allocated for various projects and tasks throughout the day, but need to be agents in a support queue. Turning presence-based routing off would make sense here. On the other hand, if your agents are less calendar focused, perhaps they’re helpdesk staff, then presence based routing would make sense. There’s no point in ringing a helpdesk agent who’s on a call to take another call!

Round Robin and Serial routing need to have an ordered list of agents. That’s in another spot in the Call Queue configuration in Teams Admin Center, and it gives you three options:

For round robin and serial, you will want to add only users here. There’s no way to prioritize agents in a group, or in multiple groups. (And choosing Team here is an entirely different set of blog posts!)

Call Agent alert time seems straight forward enough. Ring an agent for x seconds, and then move on to the next agent, again for x seconds. If you have a timeout configured for the queue, the timeout action will only take place at the end of a full agent alert time. For example, if your queue timeout is 20 seconds, but the agent alert time is 15 seconds, the first agent will ring for 15 seconds, then the next agent will ring for 15 seconds, then the timeout action will trigger.

When cycling between agents, the caller doesn’t notice anything different in the ringback that they hear. Agents will see the call come and then go. If for some reason an agent is offered the call again – maybe they’re the only ones that are Available and you’re using presence based routing – the ringing will stop briefly and then start again.

If you have an agent alert time that’s less that a queue timeout value and you’re using Attendant mode, all of your agents will ring for the alert time, then ringing will stop, and then it will start again. This is annoying, so sync up those timers to get rid of this.

If you’re coming from the Skype for Business world and are familiar with Response Groups, you’ll notice some similarities with call queues, and a few differences. First off, SfB has an Attendant routing mode. The Teams equivalent to that is “Attendant with presence-based routing off”. SfB has a mode called Parallel, and that is Teams “Attendant mode with presence-based routing on”. You’ll also note that there aren’t any IVR options or schedules in Call Queues. If you need those, you should build an Auto Attendant, and have the auto attendant send calls to the call queue(s). Why this change? I’m not certain, but it likely had to do with Auto Attendants being an Exchange item that SfB (and other systems) could take advantage of, and now Teams has Auto Attendants, not Exchange. It doesn’t make a lot of sense to have schedules and IVR functionality in both Auto Attendants and Call Queues, when you can easily snap them together into whatever combination of objects you’d like.

And finally, the docs article for call queues is FULL of all sorts of different exceptions and limitations and recommendations. Make sure you read through the exceptions and limitations. I don’t put a lot of weight in the recommendations like “use presence based routing” as there’s no explanation as to WHY that is recommended. And as explained above, there are legit reasons to not use it. Similarly, there’s a recommendation to use longest-idle or round robin, and yet I can list out a handful of reasons to use other methods without too much effort. If you’re not sure about these, run a proof of concept and try them out.

Call Queues – Presence-Based Routing, Agent Opt-out, Agent Alert Time. What do I pick?

In a recent post, I covered the 4 methods that can be used to assign calls to agents of a Call Queue. In this post, we’ll continue with the rest of the configuration bits that can affect call distribution. Unlike the 4 methods, there’s no information buttons beside these options to help explain.

First up is Presence-based routing. This one is fairly easy – if you turn this on, only agents who are Available are offered calls. Agents who are in any other presence state will be skipped.

Next is a setting that allows agents to opt-out of being offered calls. This is done via the Teams client, and is a couple of clicks deep in to the options menu. The choices for the user are to receive or to not receive calls. There’s no option to set an expiry or schedule for this timer. In my experience, users will opt out of the queue and forget to opt back in. If your agents need to set different statuses for breaks or wrap-up time after handling a call, you can fudge these instead by setting presence to away or busy, and using the expiry timers there. Or, consider one of the many contact center options for Teams.

And finally, Agent Alert Time. This setting is used to establish how long a call is used by the serial and round robin options to determine when the call should move to ring the next agent in the list.

Up next is tips, tricks, and gotchas when configuring these settings