dmunified

UC and beyond

recent posts

about

Specialist in all things Microsoft, Teams evangelist, cloud voice specialist. Living and working in Melbourne, Australia.
  • Why Teams Phone Extensibility for Dynamics 365 Contact Center & ISV Solutions is a Game Changer

    Why Teams Phone Extensibility for Dynamics 365 Contact Center & ISV Solutions is a Game Changer

    I know what you’re thinking: the term “game changer” is rolled out a lot these days, and I tend to agree. That said, I did ask Copilot to give me 10 better variations of “Teams Phone Extensibility for Dynamics 365 Contact Center & ISV Solutions has landed – why this is a good thing”, and this is what I’m going with. Oh hell I’m owning it: it IS a game changer for any organisation that has\wants Teams Phone for PSTN calling AND wants to use a Teams PSTN connectivity option for their Dynamics 365 Contact Centre (or other ISV certified contact centre solutions…)

    I’ll explain.

    In March 2025, Microsoft announced Teams Phone extensibility for Dynamics 365 Contact Center and certified ISV solutions – powered by Azure Communications Services. This was welcome news for those of us that play in the Microsoft Converged Communications space – but what exactly does it mean?

    Background: Dynamics 365 Customer Service\Contact Center

    Before we look at the Teams Phone extensibility bit, it will be worth going over what’s happening in the contact center space from a Microsoft perspective.

    In June 2024, Microsoft announced the general availability of Dynamics 365 Contact Center – a Copilot-first cloud contact center that’s designed to transform service experiences. Whilst this was welcome news, it wasn’t in fact the first time Microsoft offered “first party” voice capabilities with a Dynamics 365 product. Here’s the announcement from November 2021 when voice channel was introduced to Dynamics 365 Customer Service.

    So, what changed in 2024?

    Prior to the June 2024 announcement, the only option for voice channel within Dynamics was within the Customer Service product: a full-blown CRM platform, with a focus on managing customer interactions and cases end to end. The addition of voice channel was great for existing Dynamics 365 Customer Service customers that wanted to expand on omnichannel capabilities and add voice, or for greenfield deployments where Dynamics 365 Customer Service made sense. But what about organisations that were using something else for CRM and case management? Perhaps they were using something else already (Salesforce or Service Now for example)? That’s what the 2024 announcement was all about: the release of Dynamics 365 Contact Center which would allow for deployment alongside an existing CRM platform – opening up a greater number of deployment scenarios and opportunities – a standalone contact centre solution:

    Dynamics 365 Contact Center – with or without Dynamics CRM (Customer Service)

    In the following example, note the Salesforce icon top left, and the embedded Dynamics Contact Centre widget providing the contact centre capabilities over the top – this is one possibility with a decoupled contact centre solution from Microsoft:

    Dynamics 365 Contact Centre – Embedded Experience with Salesforce

    Regardless of option chosen, there’s a number of prerequisites required when deploying voice channel with Dynamics 365, one of them being Azure Communication Services:

    ACS Prerequisite for Microsoft CCaaS Solutions

    So it’s probably worthwhile spending a bit of time explaining:

    What exactly is Azure Communications Services, and what does it do?

    Found via the Azure Portal, Azure Communications Services (ACS) is a set of tools provided by Microsoft that allows developers (via APIs and SDKs) to add communication features like voice calls, video calls, chat, and text messaging to their applications. It provides a way to integrate communication capabilities into your apps without needing to build everything from scratch. In addition, ACS also forms part of the architecture that underpins Microsoft Teams communications: voice, video, and chat are all possible in Teams thanks to ACS. Keep this in mind as we explore Teams Phone extensibility further.

    ACS: Supporting Voice Calls for your Application

    Bringing it back to Dynamics 365 Customer Service\Contact Center: either option is essentially an app built in Power Platform, and just like any other app that might want access to voice channel and PSTN calls, ACS is what’s providing this:

    ACS – Supporting Voice (and SMS) for Dynamics 365 Contact Centers

    Other ISV Contact Center Solutions?

    Aside from Dynamics 365 based solutions, there are other Independent Software Vendors (ISVs) that develop certified contact centre solutions – built on ACS. At time of announcement, these were Anywhere365, AudioCodes, ComputerTalk, Enghouse, IP Dynamics, Landis, and Luware. All of these ISVs will also benefit from Teams Phone Extensibility, and have been given the certified tick of approval from Microsoft. However, it’s worth noting that there’s no requirement to be certified to use it if you happen to have your own application that’s leveraging ACS for the voice bits. This was called out in the official announcement also:

    Now that we’ve covered off on contact centre and ACS components and what ACS is doing for the various contact centre solutions, what’s changed with the Tams Phone Extensibility announcement?

    PSTN Calling with ACS (pre Teams Phone Extensibility Announcement)

    Prior to Microsoft announcing Teams Phone extensibility, there were a couple of ways to get a PSTN call into and out of ACS:

    • Request a direct phone number from Microsoft (similar to requesting a service number for use with Teams Phone if you’re familiar with that), or
    • Configure an Azure Direct Route (not to be confused with a Teams Direct Route – more on that later).

    Once an Azure Communication Service instance is deployed in Azure, here’s where you’ll find them:

    Azure Communication Services: Where to find PSTN Configuration

    A little bit more detail on each of these existing options:

    Direct Phone Number

    As the name suggests, phone numbers are requested and provisioned by Microsoft, which can then be used to make and receive calls from an application. Of the two options available in ACS today, this is the simplest way to get PSTN calls up and running:

    ACS: Direct Phone Number Interface

    Azure Direct Routing

    Another option to enable PSTN calling with ACS is via Azure Direct Routing. It’s essentially a SIP Trunk between a Session Border Controller (SBC) and ACS:

    ACS: Azure Direct Routing Interface

    In the example above, aucssbc01.domain.com.au is the FQDN of an SBC that in this case, happens to be hosted in Azure but could be hosted on-prem, carrier hosted, etc:

    Azure Direct Routing… a SIP Trunk

    Side note: In Australia, Azure Direct Routing was the only way that PSTN numbers could be commissioned within ACS, at least initially. Phone Numbers provided by Microsoft were not supported in all global locations on release. That’s now changed, Australian numbers can now be requested, but you do still have to fill out a special request via the Phone Number Service Center. Takes a day or two to process, so if you do plan to use this method, plan ahead.

    Teams Phone PSTN Connectivity – A Refresher

    Before I finally get to my point and explain why I think Teams Phone Extensibility for Dynamics 365 Contact Center & ISV Solutions is a total game changer, over in the world of Teams what options are available to connect to the PSTN? Essentially, they boil down to three (yes technically four if you include Teams Phone Mobile – see my asterisk below):

    • Teams Phone Calling Plan
      • Known as Telstra Calling Plans in Australia.
    • Teams Direct Routing
      • A SIP trunk between an SBC and Teams Phone in Microsoft 365.
    • Operator Connect
      • Pre-qualified, carrier managed PSTN calling and SBCs managed for you.

    When deploying Teams Phone, one of these (or sometimes more than one) are provisioned in order to provide connectivity between Teams and the PSTN. It’s a prerequisite: the plumbing that’s going to allow PSTN phone calls from a Teams client.

    Aside: In addition to Teams Phone connectivity options above, there is also the concept of a Service Number in Teams Phone System: the ability to request a phone number direct from Microsoft to use in a few different scenarios, including assigning to Teams Auto Attendant or Call Queues. Whilst not clear at this stage, it’s possible these may also be able to be leveraged with Teams Phone extensibility for contact centre use cases. Would make for a much smoother migration from native Teams call flows to a CCaaS solution if that were true. This will make more sense once I’ve covered off on what Teams Phone extensibility actually is below.

    So Why is Teams Phone Extensibility a Game Changer?

    For organisations that have PSTN connectivity infrastructure in place to support Teams Phone, wouldn’t it be great if we could use the same infrastructure to support PSTN calling from Dynamics 365 Contact Centre (or one of the other certified contact centre ISVs that are using ACS)? That’s precisely what Teams Phone extensibility will allow.

    No longer will I have to request a phone number from ACS or configure an Azure Direct Route (particularly if I already have a Teams Direct Route) – I can just use what I already have, or if I’m migrating to Teams phone and also want to bolt on a contact centre solution, my architecture is simplified.

    Options available for PSTN calling: Before and After

    What about if I’m using Teams Direct Routing to enable PSTN calling for Teams Phone? Can’t I just use the same SBC infrastructure to support Azure Direct Routing too?

    Yes, absolutely. However, it is not supported to use the same direct route for both Teams and Azure Direct Routes: you need to deploy two (prior to this announcement of course). Phone numbers for Teams would go via the Teams Direct Route, Calls to ACS via the Azure Direct Route:

    Azure and Teams Direct Routing from the same SBC

    To be honest, adding an addition direct route isn’t too tedious, but it did mean that more configuration on the SBC was required, more firewall ports to open, more public certificate FQDNs needed (as each Direct Route would have a unique FQDN configured on the SBC so Teams and ACS knew where to send calls), and frankly it’s just simpler if I can just use one Direct Route, particularly given that both actually route to the same destination cloud side. Here are the destination FQDNs listed in Microsoft’s documentation for Teams Direct Routing and Azure direct routing respectfully – note that they are identical:

    From Plan for Teams Direct Routing:

    Teams Direct Routing – Connection Points Cloud Side

    From Azure Direct Routing Infrastructure Requirements:

    Azure Direct Routing – Connection Points Cloud Side

    Which goes to my earlier point: Teams is already using ACS for calling – this kind of proves it.

    What Else will be Possible?

    In addition to simplifying connectivity to the PSTN by consolidating telephony infrastructure for UCaaS (Teams) and CCaaS (D365\ISVs), there are a number of other features and capabilities we expect to see unlocked with this announcement, including:

    • Gen AI Integration: Utilize AI to streamline processes and empower customer service agents with automation capabilities, with direct access to Azure AI technology.
    • Extend UCaaS Capabilities to CCaaS: Take advantage of Teams Phone enterprise features, including emergency calling, dial plan policies, wide geographic availability of Public Switched Telephone Network (PSTN) connectivity options and much more from CCaaS solutions.
    • Agent Notification handling: Allow data segregation between CCaaS persona and UCaaS persona with the choice of ringing either the Teams standard client or a CCaaS application.
    • Cost Efficiency: Enable ISVs to build cost-effective solutions using existing Teams Phone plans, without adding Azure Communication Services numbers or Azure Direct Routing.

    Final Thoughts

    The integration of Microsoft Teams Phone system with ACS-powered contact center solutions marks a significant advancement in the way organisations can simplify their communication and customer support capabilities. This convergence not only streamlines the user experience, but also brings greater efficiency and simplicity to UCaaS and CCaaS deployments. As businesses continue to adapt to evolving communication needs, leveraging these powerful tools will be essential for staying competitive and providing exceptional service to customers. The future looks promising as we embrace these innovative solutions to create more connected and responsive environments (thanks Copilot).

    Damien is the Global Solutions Director for Microsoft Converged Communications at Rapid Circle: a global organisation dedicated to creating impactful solutions with the Microsoft Cloud.

    Click here to get in touch.

  • SIP & H.323 Calling with Microsoft Teams Rooms

    SIP & H.323 Calling with Microsoft Teams Rooms

    There are few technologies that we can say have broken down all barriers when it comes to communicating with anyone else on the planet: sending a letter, sending an email, making a phone call – all great examples. If I’m doing any of these, I don’t have to enquire beforehand to find out what system or technology the far end is using: I just need their unique contact details (address, email address or phone number respectively) and away I go – I’m communicating.

    From a video conferencing perspective however, this is far from the case. Today, there are a number of competing technologies and platforms that don’t allow easy communication between themselves: a video call between Microsoft Teams and Zoom for example. There have been some efforts made to allow one platform to join meetings on another: Microsoft’s Direct Guest Join for example, but there have been limitations with these approaches – only being able to leverage a single screen for Direct Guest Join calls in a dual screen Microsoft Teams room is one example, and only allowing a guest experience in the 3rd party platform another.

    Interop with “legacy” conferencing protocols

    In today’s business environment, organisations typically select one of only a handful of cloud-based conferencing platforms to support video conferencing: Microsoft Teams, Zoom, or Cisco Webex. There’s more of course, but these are by far the most common. Each of these have their own proprietary approach to providing video conferencing services, and aren’t necessarily based on an industry standard when we look at what protocols are under the hood of each platform. This wasn’t always the case however: there was a time when video conferencing did adhere to standards, which made interop a little bit simpler.

    Side Bar – SIP and H.323

    Without getting too much into the technical, it is important that I clarify what I mean by “standard-based” SIP and H.323 when it comes to video conferencing. In essence, the term “standards-based” refers to any video conferencing endpoint that uses either the SIP or H.323 protocol to communicate with other endpoints using SIP or H.323 – natively. They don’t necessarily have to be from the same vendor for these calls to work, as a common standard is being adopted by each respective vendor:

    Now, anyone that’s using one of the online conferencing platforms mentioned early may be wondering why we’re still talking about SIP and H.323, and what it has to do with video conferencing interop. Well believe it or not, there are still plenty of platforms and endpoints out there that use standards-based based SIP or H.323 that we’d love to be able to integrate with from a Microsoft Teams room perspective. In addition, many of the online platforms also often provide a standards-based method to connect to their meetings. For example, here’s a Zoom meeting invite offering standards-based SIP or H.323 meeting join details:

    If we were to receive a meeting invite from any meeting platform we’re not familiar with, and they offered a standards-based SIP\H.323 meeting join capability, wouldn’t it be great if we could use that to join that meeting directly from a Microsoft Teams Room?

    Wait – don’t we have standards-based interop already?

    For organisations that have standardised on Microsoft Teams Room solutions, we have been able to offer interoperability between Teams and standards-based endpoints for some time: Cloud Video Interop. Cloud Video Interop (CVI) is a Microsoft Qualified third-party solution that enables third-party SIP and H.323 video room devices (VTCs) to join scheduled Microsoft Teams meetings. The architecture looks like this:

    This service worked by adding additional meeting join info into a Teams meeting invite, allowing a 3rd party to join my Teams meeting from a standards-based video conferencing endpoint.

    Here’s an example Teams meeting invite, showing standards-based meeting join info:

    As outlined above, it’s important to reiterate the specific scenario that Cloud Video Interop supports:

    • Allow a standards-based endpoint to join my Microsoft Teams meeting
    • Must be a scheduled Teams meeting

    The piece that’s been missing is the ability to make and receive a one to one, ad-hoc, standards-based video call.

    Introducing SIP\H.323 Calling for Microsoft Teams Rooms – Powered by Pexip

    In partnership with Pexip, Microsoft has unveiled additional capability that builds on top of what CVI was able to provide: SIP and H.323 calling with Microsoft Teams Rooms. This allows both inbound and outbound video calls between a Microsoft Teams Room on Windows system and a standards-based SIP\H.323 endpoint\conference, and supports audio, video, and content sharing in both directions.

    Prerequisites

    Before you can use this feature, there are of course some prerequisites, namely:

    • This is only available on Microsoft Teams Rooms on Windows based solutions (no Android support)
    • The room must have a Microsoft Teams Room Pro license assigned
    • Teams Room software needs to be at least 4.17.51.0
    • You must have purchased the interop service from Pexip\Poly

    Poly?

    For those that may have been using Cloud Video Interop in the past, you may be familiar with Poly(com) and the interop service they were offering (here are details on the “traditional” CVI service and who was offering it).

    Moving forward, Poly will continue to offer CVI as well as the latest 1:1 SIP\H.323 calling capabilities we’re talking about here, but the service is powered by Pexip:

    Pexip Licensing

    Looking at what’s required licensing wise from Pexip, you’ll need one of the following:

    Enterprise Room Connector Premium

    • Minimum 10, per room license, one year pre-pay
    • Has traditional CVI, plus MTR SIP\H.323 Dialling included
    • Includes Custom Domain x 2, Custom Branding
    • Plus a lot more features and capabilities that may not be relevant to you if you’re using Microsoft Teams Rooms exclusively in your environment

    OR

    MTR Calling License

    • Minimum 25, per room license, one year pre-pay
    • Also requires Custom Domain License (required for each unique MTR domain)
    • The more likely choice for pure Microsoft Teams Room environments

    Setup – Pexip Consent

    Once you have licensing in place from Pexip (or Poly), you’ll receive an email requesting consent to authorise Pexip CVI applications within you Microsoft 365 Tenant:

    Note that the next step will require Global Administrator permissions to proceed:

    Here are the permissions you’ll need to accept:

    Once accepted, you receive the following notification:

    Setup – Microsoft Teams

    Once the Pexip service has been authorised within your Tenant, you’ll need to setup Pexip as a Teams Video Interop Service Provider. Details for the Tenant Key, Instruction URI and Application ID will be contained within the page displayed by Pexip once admin consent has been granted. Here’s the Teams PowerShell:

    New-CsVideoInteropServiceProvider -Name Pexip -TenantKey "teams@domain.onpexip.com" -InstructionUri "https://pexip.me/teams/domain.onpexip.com/{ConfId}" -AllowAppGuestJoinsAsAuthenticated $true -AadApplicationIds "923c9f0a-b883-4efe-af73-54810da59f83"

    Once created, you will also have to create a Teams Room Video Tele Conferencing Policy that will be assigned to resource accounts associated with Teams Rooms where you want to enable SIP\H.323 dialling. This is where you also have some control on what you want the room to support, for example you may want the room to be able to make SIP\H.323 calls to external participants, but not receive. The following example allows both inbound and outbound:

    New-CsTeamsRoomVideoTeleConferencingPolicy -Identity "TurnOnSIPH323" -Enabled $true -AreaCode "923c9f0a-b883-4efe-af73-54810da59f83" -ReceiveExternalCalls Enabled -ReceiveInternalCalls Enabled -PlaceExternalCalls Enabled -PlaceInternalCalls Enabled

    And finally, make sure you grant the policy created above to each of the resource accounts with Teams Rooms you want to enable this capability for:

    Grant-CsTeamsRoomVideoTeleConferencingPolicy -Identity “mymtrroom@domain.com.au" -PolicyName "TurnOnSIPH323"

    Note that, in my testing, it takes around 15-30 minutes after granting the policy before the functionality is available.

    Placing a Call

    From your Microsoft Teams Room (Windows) touch panel, click on the Call button:

    From there, you should now see a drop down in the top left of the screen that allows you to select SIP or H.323:

    In this example, I’m dialling a handy test service Pexip make available: test@pexip.me. This works for test calls using SIP or H.323:

    You can see in the call setup screen that the Teams Room system is dialling the Pexip interop bot:

    And when connected, your front of room screen will show this:

    Before showing you this. Makes it easy to test audio and video is functional in both directions:

    Receiving a Call from a SIP\H.323 endpoint

    Everything shown above is all you need if you only want to support outbound calls to standards-based SIP\H.323 endpoints from your Microsoft Teams Room. If you also want to support inbound calls direct to your Microsoft Teams Rooms from SIP\H.323, there’s some additional configuration:

    Setup – DNS

    The following DNS records are required to point inbound standards-based calls to the Pexip interop service:

    • _sip._tcp.domain.com 10 100 5060 ygg-dial1.vp.vc
    • _sip._tcp.domain.com 50 100 5060 ygg-dial2.vp.vc
    • _sips._tcp.domain.com 10 100 5061 ygg-dial1.vp.vc
    • _sips._tcp.domain.com 50 100 5061 ygg-dial2.vp.vc
    • _h323cs._tcp.domain.com 10 100 1720 ygg-dial1.vp.vc
    • _h323cs._tcp.domain.com 50 100 1720 ygg-dial2.vp.vc

    If you’re not sure if records already exist in your environment for these services (sometimes the case, or may also be old records not in use anymore), Pexip provide the following handy tool to check: https://dns.pexip.com.

    Enter in your domain, and you will see what’s configured\confirm the above records have been configured correctly:

    Setup – Pexip

    Once in place, there is some backend configuration that Pexip need to complete to support inbound dialling. Your Pexip partner will reuest this for you as part of the setup process.

    Setup – Teams Policy

    And finally, make sure that the Teams Room Video Tele Conferencing Policy allows the Teams Room system to receive an external call:

    New-CsTeamsRoomVideoTeleConferencingPolicy -Identity "TurnOnSIPH323" -Enabled $true -AreaCode "923c9f0a-b883-4efe-af73-54810da59f83" -ReceiveExternalCalls Enabled -ReceiveInternalCalls Enabled -PlaceExternalCalls Enabled -PlaceInternalCalls Enabled

    Receiving a SIP\H.323 Call

    With all that in place, you should now be able to receive a SIP\H.323 call to your Microsoft Teams Room. Here’s an old but reliable Polycom Convene I recruited for this demo – dialling the MTR room address:

    This is what appears on the Teams Room touch panel:

    Front of room:

    And finally, when the call is connected, touch panel:

    Front of room:

    Future Capability

    At time of writing, there was one important feature yet to land, and that’s DTMF support. This is important in scenarios such as entering in a meeting PIN once you have joined a standards-based meeting.

    Currently this is in tech preview, but you can check it out here:

    Hope you found this useful – get in touch of you have any questions or are interested in getting this setup in your environment.

  • Using non-Teams Room Licensing on your Teams Room Systems and Surface Hubs? Read This.

    Using non-Teams Room Licensing on your Teams Room Systems and Surface Hubs? Read This.

    Important Update: Teams Rooms Device Licensing Enforcement has been extended to Sept. 30, 2023. Check out this tech community update for further details.

    If you’re using Microsoft Teams Room systems or Surface Hubs in your organisation, these devices will be licensed to allow connectivity to Microsoft 365. Microsoft have two licenses available for Teams Rooms and Surface Hubs today: Teams Room Basic and Pro. These licenses superseded an earlier licensing model (Teams Room Standard and Premium, read more about them and the change to Basic and Pro here), and have all the components required to support your video conferencing devices in your rooms and spaces.

    Whilst Teams Room licensing has been available for sometime in one flavour or another, it was still common to see some organisations opt to use standard licensing (such as E3 or E5) to license their meeting room devices. This didn’t actually license the rooms with all the recommended components (for example, Microsoft Intune is not part of E3 or E5, but is part of Teams Room Pro), but nonetheless we still did see this occurring.

    Typically, an organisation had a few spare E3 or E5 licenses available, and path of least resistance was to just use those for the meeting room accounts, but moving forward – these will need to be changed.

    Meeting Devices Blocked after July 1st 2023 if not licensed correctly

    As published by Microsoft as part of their Teams Meeting Room devices documentation, Microsoft will no longer allow devices to sign in if not licensed correct post July 1st 2023.

    Are your rooms licensed incorrectly? Now is the time to review and confirm prior to the cut-off date.

  • HUGE Changes to Microsoft Teams Meeting Room Licensing – Introducing Meeting Room Pro (and Basic…)

    HUGE Changes to Microsoft Teams Meeting Room Licensing – Introducing Meeting Room Pro (and Basic…)

    As per Microsoft’s official blog released today, Microsoft have announced big changes to licensing for Microsoft Teams Rooms. If you have already deployed (or are planning to deploy) Microsoft Teams Rooms on Windows, on Android, or Surface Hubs, these changes will affect you.

    As of September 1st 2022, Microsoft has begun offering Microsoft Teams Room Basic & Pro, which will replace Microsoft Teams Rooms Standard and Premium licensing SKUs that are required to license both Teams Room systems and Surface Hubs:

    Changes to Room Licensing as of September 1st 2022

    Prior to September 1st, Standard and Premium room licenses were both paid options, and both provided the same in room experience regardless of which license you decided to use. What Premium did add however were more advanced capabilities around monitoring and alerting, security, reporting, software updates and inventory control. In addition, Premium licensing also gave you access to a managed service from Microsoft: tickets were either automatically created, or manually requested from the Teams Room Premium portal, with resources from Microsoft assigned to resolve.

    Limitations of Basic

    With the previous licensing structure, there were no differences with the in room experience regardless of licensing chosen: Standard and Premium both allowed use of all in room features, with the benefits of Premium being more from a support perspective. With the new licensing structure, advanced features are only available with the Pro license.

    The following table provides a good overview of what features are available with Basic and Pro:

    Basic vs Pro

    NOTE: one that isn’t clearly outlined in the table is dual screen support – you’ll need a Pro license if you want to use dual screens. This is more clearly articulated here.

    If basic still meets your needs, also keep in mind that it’s limited to 25 licenses per tenant. Basic is very much targeted at SMB deployments and removes licensing blockers for these spaces to be Teams enabled.

    Benefits of Pro

    Whilst I could see what Microsoft was trying to achieve with the premium license previously available, in practice it did not go far enough from a managed services perspective to give a level of assurance that most organisations desire. Sure, tickets were automatically generated, updates were being handled better, much better alerting and reporting was available. But what could be done if the issues could not be resolved remotely? What if there was a device failure, or a site visit was required? What about the AV layer – who was responsible for that?

    With the move to Pro, Microsoft has made some key changes, namely:

    • The AI-powered platform value from Managed Services (Premium) will be included as part of the Microsoft Teams Rooms Pro SKU, with access to the intelligent device management dashboard available in the coming months.
    • Microsoft will be winding down the involvement of service engineers. Importantly, this includes no longer serving as the intermediaries for the incident management workflows starting October 1, 2022.

    As someone who works with customers on a daily basis who have either deployed Teams Rooms or are thinking about it, I’m happy to see the changes that are coming to the licensing structure, for the following reasons:

    • Alerting and reporting with Teams Room Standard was not sufficient to provide a good level of service for most organisations. Notification and alerts would only allow me to trigger an alert based on online\offline device health status, which was not granular enough to be really effective. Reporting was also very limited. With Pro, all the alerting and reporting benefits that were part of Premium are included.
    • The removal of the managed services component from Microsoft aligns better with what we see our customers needing to provide a good level of service. As I mentioned earlier: there’s more to manage in a Teams Meeting Room than the core meeting room system itself. Even in a simple room setup, there’s screens, USB peripherals from a range of partners, as well as things outside the room that can affect a room’s up time. Rooms are also physical spaces: when things break, need to be reset, or cannot be reached remotely, a managed service needs to include a mechanism to support on-site visits.

    The new model allows Microsoft partners to built their managed service offers around pro, without the confusion that having additional managed services included in Premium licensing tended to generate:

    Not using Room Licensing for your Rooms?

    From time to time I do come across rooms that are licensed with non room specific licensing: E3, E5, a combination of E3 + Phone System + Intune etc. Not the most efficient way to license a room, but do come across it nonetheless.

    If you are doing something like this, you have until July 1st 2023 to update to room licensing. Prior to that date, Microsoft will be alerting you via pop ups on the Teams Room systems themselves, so worth getting out in front of:

    What about Teams Room Panels?

    If you have use cases that call for a Teams Room Panel outside the room only, without a Teams Room system or Surface Hub in the room itself, there will be an additional license coming that will meet this requirement. Microsoft’s Ilya Bukshteyn has confirmed this via LinkedIn, however no timeframe at this stage:

    Final Thoughts

    Since the inception of Room Standard and Premium licensing, I’ve always held the opinion that Standard did not provide enough from an alerting and reporting perspective, and that the Managed Services of Premium did not go far enough to provide a true managed service offering that organisations require. I see the move to Basic and Pro as a way to simplify the discussion: Basic is there to streamline deployments for initial pilots and smaller organisations, with Pro the way to go for larger orgs that require all the additional features and benefits. The removal of the managed services direct from Microsoft also ensures that discussions around ongoing support are streamlined, with qualified partners filling the gap and ensuring the entire space is managed end to end.

  • Register a Poly Rove DECT Handset DIRECTLY to Microsoft Teams

    Register a Poly Rove DECT Handset DIRECTLY to Microsoft Teams

    Back in September of 2021, Microsoft announced the public preview of their SIP Gateway solution that would allow select “Standard SIP” phones to connect to Teams. This feature has since become generally available and was welcome news, as it allowed organisations that had a large investment in non-Teams native handsets to bring them across during migration, rather than replacing with Teams native options. Sure, they wouldn’t provide the same advanced features and benefits of a Teams phone, but it did ensure there was a path to Teams telephony without having to replace every single handset, which may have been cost prohibitive.

    The addition of the SIP gateway also meant that organisations that were still using Skype for Business phones with Teams (in 3PIP mode) also had a migration path forward once Microsoft stop supporting their 3PIP gateway (which is on topic at present – this was recently announced as occurring as soon as end of September 2022, check out Tom Arbuthnot’s blog for more on this).

    At release, the Teams SIP Gateway was slated to support only a select number of handsets from Cisco, Poly, Yealink and AudioCodes (for a full list of supported devices and model numbers, check out Microsoft’s Plan for SIP Gateway documentation):

    Initial Devices to be Supported via Teams SIP Gateway

    But what about other use cases?

    Support for a Broader Range of Devices

    In addition to being useful for all the reasons stated above, the availability of the SIP gateway also means that Microsoft can now add support for additional devices that extend features and capabilities into areas that Teams devices don’t support today. When I first heard about the SIP Gateway, my mind immediately went to support for SIP paging speakers\servers, intercoms, and analogue gateways (ATAs) that would mean we could finally retire a bunch of on-premises SBCs we still have deployed to support these use cases. We don’t have support for those devices yet, but what we now have is support for a number of DECT handsets.

    Announced in quick succession, first to be supported was Spectralink, and now Poly’s Rove series are also supported for connectivity to Teams via the SIP Gateway.

    Why DECT?

    The desire to have a DECT handset option for Microsoft telephony deployments is definitely not new: here’s a blog I put together back in 2014 that walked through how to integrate Spectralink DECT solutions with Lync Server. Of course, things have changed a lot since then, and we don’t necessarily want to deploy and manage on-premises infrastructure simply to support DECT handsets. That said, some might ask: why do you want DECT handsets at all?

    The simplest answer here is simplicity, reliability and security. Whilst there’s a range of WiFi devices an organisation might use (running Android and the Teams native client for example), for anyone that has deployed WiFi handsets, it’s rarely straightforward. Issues with connecting to the network in the first place (802.1x, certificates, etc), the quality of the WiFi network, coverage, roaming issues, the list goes on. DECT tends to be simpler to deploy, reliable, and secure, and for these reasons we expect to see demand for DECT to continue into the foreseeable future.

    The Poly Rove Series

    Full details of Poly’s Rove range can be found here.

    In summary:

    • Modular system, choose from two handsets (Rove 30 or 40), two base stations (Rove B2 or B4), and a repeater (Rove R8) to meet your needs.
    • Main difference between handsets: Rove 40 also supports a dedicated emergency key, vibrate mode and Bluetooth connectivity to add a wireless headset.
    • Scalable: deploy from 1 to 1,000 handsets.

    How to Register Poly Rove Handsets to Teams

    Ready to connect a Poly Rove handset to Microsoft Teams? Here’s how:

    From the Teams Admin Centre, make sure the Calling Policy associated with the account that will sign in from the Poly Rove device has SIP devices can be used for calls set to On.

    For the next step, you’ll need to access the web interface of the Rove base station. You can find the IP address from any handset that’s already connected. From the main menu, go to Info, and scroll down:

    The phone will need to be updated to a version supported to register to the Teams SIP Gateway. Configure the Firmware Server URL and Firmware Path, and configure the Firmware Versions and Handset Images. At time of writing these were Base Firmware 8003 and Handset Firmware 0009 (check here for the latest supported firmware versions):

    • Firmware Path: /voice/dect-ip-phones/Rove/

    It will take sometime for both the base station and handset to update (expect up to 90 minutes). You can check and confirm the base station software version from the System Status page, and the handset from the Handset Summary page:

    Now that everything has been updated, go to System Management > Auto Provisioning and configure ITSP Provisioning. The correct URL is dependent on your particular global region:

    I’ve opted for a periodic check for config updates every 3600 seconds, and using APAC region URL given I’m in Australia:

    After configuring, the device will reboot, and\or reboot it yourself in order to kick off provisioning. Once complete, the device will show Microsoft Teams registration:

    Next, you’ll need to access the Teams Admin Centre. Go to Teams Devices > SIP Devices, and from the Actions menu, select provision devices:

    Use the IPEI Number of the Rove handset to add the device to Teams:

    You can also get this directly from the handset:

    Note: When entering, you will need to append a couple of zeros to the front of the IPEI number so that it fits and is accepted:

    Once added, generate a verification code that the handset will need to complete sign in:

    From the Handset, Dial *55* + the verification code from the handset. The phone will dial and hang-up pretty quickly. From the Teams Admin Center, phone will move from Waiting on activation to Waiting for sign in:

    From the Teams Admin Portal, select the handset, and click on Sign in a user:

    The following will appear:

    The process from this point forward is very similar to signing in any device when using the web sign in method. Follow the prompts, and when you’re done, you should see this:

    After this, give the handset a few minutes, at which point it should be signed in and ready to use.

    Conclusions

    It’s great to see that we’re starting to get a broader range of devices that can register to Teams via the SIP Gateway. Hopefully DECT is just a start – I’m looking forward to not needing any SBC infrastructure at all for organisations that want to support additional SIP devices. SIP Intercoms and ATAs are at the top of my list. Any others you’re waiting on? Keen to hear your thoughts in the comments below!

    Damien

  • TLS Certificate Changes to Microsoft 365 (Including Teams)

    TLS Certificate Changes to Microsoft 365 (Including Teams)

    As announced here, Microsoft will soon be updating the root certificates that are (as their name suggests) foundational when it comes to protecting your Microsoft 365 traffic. For your day to day devices that you use to access Microsoft 365 services, this change should have no impact: your devices should already trust the new root certificate, and mechanisms will be in place that ensure trusted certificates are automatically updated.

    However, there are some scenarios where trusted root certificates are manually configured, and as such will need to be updated. One such use case is Microsoft Teams Direct Routing. Session Border Controllers (SBCs) that support direct routing typically require manual management of trusted root certificates, and will need to have the new trusted root certs added before the change. One of my older blog posts outlines how certificates are managed on Ribbon SBCs.

    Up until this change, the Baltimore CyberTrust Root certificate was installed on SBCs to support TLS authentication. New TLS certificates used by Microsoft 365 services will now chain up to one of the following Root CAs:

    Common Name of the CAThumbprint (SHA1)
    DigiCert Global Root G2df3c24f9bfd666761b268073fe06d1cc8d4f82a4
    Microsoft RSA Root Certificate Authority 201773a5e64a3bff8316ff0edccc618a906e4eae4d74
    Microsoft ECC Root Certificate Authority 2017999a64c37ff47d9fab95f14769891460eec4c3c5

    Time wise, it looks like that this change will rollout out between now and October 2022. Now is a good time to check your SBCs and make sure these have also been added to avoid any unnecessary downtime.