It’s no secret that Microsoft has been working hard on improving the Teams calling experience, especially for handsets over the last few months. As part of What’s New in Microsoft Teams | February 2022 update, Microsoft announced that Walkie Talkie had finally come to Teams Phone Edition.
This was thought to be the nail in the coffin for dodgy hacks like this, this, and this (Sorry Greig) when we saw it on the roadmap. Offering a fully supported, certified paging solution for Teams Phone right?
Sorta. (not really)
Why do we need Paging?
One of the big missing features from Teams Phone has been some form of “Paging” system.
I’m sure you have all experienced Paging and Call Park at some point in your life. You’re at the local grocery store only for an announcement to come over the speakers “Call for Health Foods, Star 22, Health Foods Star 22” then the monotonous elevator music resumes.
Paging is seriously important in FrontLine/Retail/Warehouse scenarios, where someone in the office might take a call, place it in call park then “page” the warehouse with something along the lines of the announcement above.
It’s also commonly used to play announcements to inform customers of events such as closing, or potentially for emergencies.
Is Paging the right solution?
Sure, it’s easy for us desk jockeys Information Workers to say that the person taking the call can simply send a Teams message to the Team responsible for the call. Or maybe sending the call to a Call Queue would be more approrpiate. But what about that retail setting we mentioned earlier? Staff walking the shop floor arent constantly checking their smart device for Teams messages, some places even ban smart devices whilst on shift so they can focus on doing their job assisting customers.
With Paging, staff in almost any situation can hear the page, walk to the nearest handset and dial the call park orbit to retrieve the call.
What about the customer communication or emergency scenarios? Would an IM message work here?
How did Paging work in the “old world”
In the days of old “Key System” phone systems, Paging was the norm. Someone would take a call, place it on hold, then use a “Paging line” announce there was a call on “line 3” and hang up.
With the transition to more modern phone systems came improvements to this model. Eventually, we ended up with SIP PABXes, Phones, and Dedicated Paging Amplifiers mostly using Multicast Paging. These devices would plug into your network and “Subscribe” to a Multicast address. These could be any of the above device types, even dedicated “Push to Talk” Microphones like you see on a principal’s desk in old movies/tv shows.
The problem with these in a “cloud world” was its best feature. Multicast.
Multiwhat?
For a really quick summary of Multicast, its important to understand the different kinds of network packet delivery methods.
- Unicast – A host sending packets to another host. Network aware devices like switches don’t send this where it’s not needed.
- Broadcast – A single host sending a single packet that is received by all hosts on the same VLAN – Switches will forward the traffic to all hosts whether they like it or not.
- Anycast – A single IP address that is used by multiple machines on the internet
- Multicast – A single host sends a packet to a Multicast address that hosts can receive by subscribing to that address. Switches/Routers will forward the packet to the host if it has subscribed, Thus saving bandwidth and processing power.
I won’t go too in-depth for the non-network nerds but Multicast is different from Broadcast in that it only sent traffic to hosts that cared about it, and Multicast would also cross VLAN boundaries if configured correctly, but would never survive on the internet.
Why is any of this relevant to Teams?
That’s the thing, it’s not.
Microsoft has taken a different approach with Teams Walkie Talkie and its implementation on Teams Phones.
Instead of having one device such as a phone/pbx/microphone send its audio stream to a Multicast address for other devices to listen to, Teams Walkie Talkie takes the brute force approach of having the sending party transmit the media to the Microsoft365 cloud and then it sends it back to all devices as individual Unicast streams on the same Walkie Talkie channel that they are currently connected to. (more on that later)
If I had to guess, I’d say Microsoft dispensed with the complexity of Multicast because;
- It (typically) only works inside the private network boundary
- Correct network Multicast configuration can be difficult
- It doesn’t work on Wifi very well
- It will never work on mobile (cellular) devices
- It was also kinda a security nightmare
- The bandwidth savings aren’t really relevant in this day and age
- The amount of Physical Handsets has rapidly declined in the past decade.
The reasons for this are many, but the biggest one is that any devices on any network can participate in Walkie Talkie sessions together, regardless of hardware vendor, network connectivity or platform (Mobile Phone, Teams Phone or (hopefully at some point) Desktop)
This sounds great. So we can use it for Paging right?
Well, not really.
Whilst Walkie talkie has some great features that make it fantastic for a mix of workers with smart devices and desk phones. There are a few drawbacks to the current implementation of Walkie Talkie that make it unsuitable as a viable Paging replacement today.
I understand why some of these decisions were made, with each phone holding a connection open to a Teams media relay. Those idle connections stack up pretty quickly both in idle network sockets and processing load. But let’s look at some of the design decisions that are preventing us from using Walkie Talkie for paging.
- Phones in Common Area Mode cannot use Walkie Talkie
- Users must manually select and join a Walkie Talkie channel
- If the device is idle too long, it will disconnect from the Walkie Talkie channel
- Walkie Talkie connections don’t persist on reboot
Other bugs I’ve run into in my testing are just bugs, and hopefully will get fixed.
- The connect button randomly hides behind the app bar on the CCX500
- Pressing the PTT button on my CCX500 causes the speakerphone button to activate, which brings up the search bar
- Poly handsets wont allow you to mute whilst idle, yet Crestron handsets will
- All phones will unmute themselves AFTER using PTT, regardless of their state before
- Being connected to a Walkie Talkie channel will prevent Better Together from functioning. Selecting the handset inside the Teams desktop as the audio device will simply cause the client to return “Sorry, we couldn’t complete the call”
Why are we talking about it then?
Because of the Internet First nature of Teams and the Teams Phone System service. I assume has required a lot of “Re-Inventing the Wheel” throwing out all the standards above, but also a lot of the lessons and solutions created over the many decades of development they offered.
I find that each time we ask for a feature in Microsoft Teams, we get something slightly different due to different interpretations of the feature.
As an example, SIP connectivity for Teams was announced back at Ignite in 2020. We figured it would solve customers’ key selection critera by allowing standards based hardware to fill the gaps. But as we see in my recent article Dissecting Teams SIP the Internet First nature of Teams means that it needs to keep updating the phones’ credentials regularly as a security measure.
In this case, the same has happened with Walkie Talkie. It feels a little bit like it’s being designed by someone who has never used what they are attempting to replace. At least not in anger. I’m all for new ideas and better ways of doing things, but I feel this one missed the mark.
No paging, right. What now?
This is still a great feature for someone using Walkie Talkie for their frontline workers already. Perhaps all your frontline staff have PTT capable smart devices and you want someone in the office to be able to communicate with them? or need to be able to record their comms using dedicated recording hardware?
In the meantime, Poly has released traditional Multicast paging for CCX handsets in Teams mode by using app switching. Something I’ll be diving into more shortly. Otherwise, you can look at separate multicast solutions.
I have heard vendors claim they are “coming to sip gateway” but until I hear anything from Microsoft I’m not holding my breath.
Otherwise, your other option is to use a traditional paging amplifier connected to an SBC. Even if you are using Microsoft Calling / Operator Connect.
But that’s it for now. hopefully I’ve have some better news with the CCX paging.