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

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

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.