Understanding Teams SIP Gateway with Chandranshu Singh, Senior Product Manager

Prefer audio?

Who should listen: Microsoft 365 service owners and voice/UC engineers running Teams Phone alongside legacy SIP estates — DECT handsets, analogue gateways, overhead paging or lift phones — who need clarity on device eligibility, firmware ownership, support escalation and licensing.

Guest: Chandranshu Singh — Senior Product Manager, Microsoft Teams SIP Gateway, Microsoft

Chandranshu Singh, Senior Product Manager for Microsoft Teams SIP Gateway, joined the team before the service went GA in December 2021. He explains how SIP Gateway grew from basic call handling on legacy IP phones into a core part of the Teams Phone story covering DECT, analogue gateways and overhead paging, and sets out how the device allow list, firmware management, support boundaries and licensing actually work.

Many thanks to Pure IP, sponsor of this episode.

Key insights

• SIP Gateway reached general availability in December 2021, having entered private preview in summer 2021 with just three scenarios: make a call, receive a call, transfer a call. Voicemail and a small set of Poly, Cisco and AudioCodes IP phones followed. ▶ 2:06
• The original 'use SIP Gateway to burn down your legacy phone investment, then buy native' position did not hold up, because there was no native Teams equivalent for device classes such as DECT. SIP Gateway is now positioned as adding completeness to Teams Phone rather than as a migration bridge. ▶ 3:39
• Supporting the SIP standard is not enough to get a device enabled: phones can fail on HTTP/HTTPS provisioning, on required TLS versions, or be platform-locked so they cannot register to a third-party call control. Microsoft deliberately keeps a closed allow list and will not honour provisioning requests from devices outside it. ▶ 6:44
• Getting onto the allow list is customer-demand-led rather than a formal certification programme. Microsoft tests and validates a device against a specific off-the-shelf OEM firmware build when enough customers (or the OEM on their behalf) report being blocked — it takes no responsibility for the hardware itself. ▶ 8:47
• Firmware responsibility splits by device type: Microsoft hosts and rolls out firmware for the IP phones it enables, staged by device model or by tenant, but does not manage firmware for DECT, analogue gateways or overhead paging endpoints, where customers already manage on-premises installs locally. The stated direction is to reduce Microsoft's firmware-hosting footprint while still pinning validated firmware versions, because supporting unlimited versions would make test matrices explode. ▶ 11:52
• Feature work sometimes requires OEM firmware changes — dynamic emergency calling for SIP Gateway devices is a case where Microsoft had to get partners to ship updated firmware. Security fixes from OEMs are prioritised through Microsoft's test and validation cycle before rollout. ▶ 12:24
• Support boundary: Microsoft owns the telephony service on an enabled device; hardware faults go to the OEM. Where a customer cannot tell service from device, raise it with Microsoft, who will triage and hand off to the OEM partner with their findings if it is not a Teams issue. ▶ 17:30
• No additional licence is needed for SIP Gateway — a SIP endpoint is treated as just another Teams endpoint, using whatever licence the user or shared device account already has. PSTN connectivity (a phone number) is currently required, but Microsoft plans to drop that so a Teams alias alone can sign in, which also depends on dial-by-alias landing. ▶ 19:34

Insights summarised by AI from the episode transcript, reviewed by the Empowering.Cloud team.

Listen: Apple Podcasts · Spotify · Other platforms