In this Teams Insider podcast. We get deep on SIP Gateway with Chandranshu, who is a PM on SIP Gateway. He was a PM actually before it launched, and we talk about the SIP Gateway journey and how initially it was just for, you know, supporting existing phones. And now it's moved on to a much bigger part to play to enable customers. I really hope you enjoy this conversation about SIP Gateway, and many thanks to Pure IP, who are the sponsor of this podcast. Really appreciate their support. On with the show. Hi everybody. Welcome back to the podcast. I've been looking forward to this one. This is a topic that I don't think gets enough coverage and is definitely an interesting one for for me, coming from a voice background. We're going to talk all about Teams SIP Gateway, kind of the history of it and where it is today. And I've got, Chandranshu, from Microsoft. He's over in India. do you just want to introduce yourself and give us a little bit of background about yourself and your role? Absolutely. Hello, everyone. I'm Chandranshu PM on, Microsoft Teams. SIP Gateway and I have, I've been with Microsoft for about, four years and, and a quarter now and pretty much, that entire time I've been with, with Microsoft Teams, SIP Gateway before Microsoft, I was, I was working on, on a startup, of my own, that that was into BYOD devices and, and stuff and, yeah, it's it's been an exciting journey with, with Microsoft, and I'm, super, super excited to, to to work on this, this team and, and help our telephony customers. Awesome. we've spoken a lot online, but this is the first time we've spoken face to face. So, excited to have this conversation. so, so if four years was that pre I'm trying to think of a timeline was SIP Gateway, was that pre-launch or was it was it already launched at that point? No, no it was pre-launch. So so we shipped SIP Gateway to to, to customers and in general availability was December 2021. Okay. Okay. Cool. So, so when it first shipped, it felt the, the positioning was very much we have SIP Gateway. So you can take your legacy IP phones through existing PBX. And you can support them for a while longer while you burn that investment. But it feels like much more now. We've got we've got DECT we've got, a PA system, we've got, you know, Tango Extend, we've got different use cases using SIP Gateway. So can you talk us through that journey, because it feels like it's much more an important piece of the puzzle than when it initially launched. Sure. so, when, when we started off with, with SIP Gateway, what we essentially wanted to enable customers to do was, you know, making and receive phone calls on, on, on a bunch of, third party IP phones, for example, phones from, from from Poly, phones from Cisco. AudioCodes and, and some, some unique phones as well. So our focus was, in, in terms of devices, just, just some IP phones and in terms of scenarios pretty much make and receive calls, maybe transfer calls, and voice mail that that was pretty much it as we, as we went along, as we, got feedback from, from customers, we realized there were, there were so many other scenarios that, both in terms of devices and, and, calling scenarios that our customers wanted. even on their, their third party devices. So the story that, hey, this is just for basic calling and everything else, you should, you should invest in, in native devices. wasn't, wasn't holding good in many cases. we did not have a native device, story, for example, in DECT. Right. So there was no native device equivalent for, for DECT. So as we, as we spent time with customers, we realized we needed to, to support customers, with the devices that they had and, with, with the scenarios that, that they wanted. So our, positioning today or, or the way we think about SIP Gateway today. So SIP Gateway is an essential element, for the Teams phone story. it lends completeness to the Teams phone offering, and we want to support, more and more, customers devices and, and that they live in these scenarios. That's great. It takes away some of that complexity of, you know, coming from a voice background myself, you know, there were scenarios where, suddenly or back in Skype server days, we, you know, we we set things up directly on SIP to the SBC. And you could do the same thing in Teams. But as you support more and more direct SIP registrations, the Gateway in the cloud, you're reducing that infrastructure and complexity, which is great. I think. Right, right. So that is that is definitely, definitely part of the story from, from our perspective as well. We want to help, customers reduce the complexity in the telephony environment. but primarily what we are looking to do is, is help customers leverage, more of their, investments, that they've already made in telephony hardware. we we want customers, to, to have more options in terms of, in terms of devices, hardware that, that, that they can choose from for their, telephony needs. So, so those are also important considerations for us. So to help customers overall, you know, keep their costs down, get the, the value that they want, from their, their Teams, foreign investments. Awesome. And so, SIP is interesting, right? Because it's a, it's a standard. So you end up having to support something that other people. Right. The, the firmware for on the device is, you know, in, in, in, in Teams phone. Obviously Microsoft owned the, the software on the phone and the software on the back end. SIP right SIP slightly different. So, talk me through how you decide. what what kind of why you have a certain list of compatible devices, I guess, like, because it's not every single device, even though it's SIP. You do have an allow list, right? Yes, that is correct. Exactly. So, so I think there's a, there's a why part of it, I think and there is there's a what part of it it's on the why. But, first of all, there are, there are many, many devices out there that may support the, the SIP standard, but may not, support, the, the requirement of, of a cloud based, telephony system that is, that is Teams. Right. So, for example, devices may not support http or Https provisioning devices may not support a particular, version of of TLS that that we require. so there are some technical constraints and in some cases, the, the devices may be platform locked there in the sense that the, they're just not able to communicate with third party call controls, in and in, in other cases, there are, of course, these, you know, are, are positioning as, as a service provider and the, the way we want to leverage the Gateway to, to extend Teams is that, we want to unblock customers, to use their devices with Teams. Right. So we will we will want to invest in, in testing and validating, scenarios on devices that customers are actually blocked on. Right? So we will not, we don't want to open up to pretty much any device out there. We want to be judicious about, these, these investments and, and therefore, the way, we manage it, which is the what part of it. So we have an allow list, for devices that are enabled on our platform. If a device, is in that allow list, it, it comes to us requests for, for provisioning. Then we honor that request and respond with configuration. If a device is outside, we do not honor that provisioning request. Awesome. And so how how do devices get onto that allow list Is it similar to the certification process to the vendors? Work with you to get through certification, or are you doing the testing yourself? What does that look like. Right. So so certification is is an interesting, interesting thing, right. So here, since we do not own the stack as you as you said, we do not own the stack that is on the, on the phones. So we do not, want to take on, responsibility for the hardware itself. Right? We we have, I mean, it's entirely a, third party, hardware from our perspective. So what we are taking responsibility for what we are committing to to our customers is that, Okay, so if there is a if there is a big enough, requirement that, hey, certain customer or a certain number of customers are blocked on a certain device, then we will invest in testing and validating that device ourselves. Right. Whether or scenarios work well on that device. So we are committing only to the extent that, hey, we have tested, scenarios on a particular device running a particular off the shelf firmware that is available from the manufacturer. And we've seen that it works. So we are saying that, okay, we can add this to the, to the allow list, right? That is the typical process where, it's a customer led process where we, basically listen to our customers. We value, feedback from our customers. So where they say that, hey, we need this device to be, enabled on SIP Gateway so that we are unblocked. So that is one way. Another way is, where, say, OEMs reach out to us, the device manufacturers reach out to us, because they're getting, they're getting asks from their customers that, we are already using Teams in, in, large parts of our organization. but, but we are blocked on this, this telephony, part where, your particular, devices are not enabled on Teams. So how do I take this particular part of my telephony to Teams? So, sometimes manufacturers reach out to us, sometimes we reach out to manufacturers. It works both ways. So I see on the documentation as well, you've got minimum firmware version and a pre firmware version. So obviously that's when you check the devices is what happens when the manufacturers rev their firmware is do you retest those ever so often. How does that work. We we do, we do so ideally we would not we would not want to, but let's say if there is if there's a security update from the manufacturer side, we work closely with a lot of our, with all of that, not a lot of, manufacturing partners, all of our, OEM partners. And in case there is, a firmware update that that must, go out to customers, we prioritize that, and, and we put it through, test and validation cycles. Once we have tested that. Okay. this, this particular updated firmware version, supports, all of the, of these scenarios in the latest build of, of SIP Gateway, we roll it out to, to customers. we, typically roll it out, slowly, and, and maybe, by by device model or or by, by tenant. We have, we have a couple of levers that, that, that we can use to, to, to control how that, that firmware is rolled out to customers. But yes, we are responsible for ensuring firmware updates reach customers. Another case is when, let's say, there is there is a feature gap and we need a firmware update to enable that feature or, via SIP Gateway. Right. as was the case for, let's say, dynamic emergency calling, right. so we have to work with, OEM partners to ensure, firmware updates were, were made to enable dynamic emergency calling for, for, for devices connected to SIP Gateway. So even in, in some cases we may request firmware updates. Some cases, the OEM partner may request firmware updates, but regardless, if we have a firmware update, we, we test it and and we roll it out to customers slowly. What we hope for is that we don't have to do it, very, very frequently. Yeah, yeah, yeah, yeah. I mean, it tends to be SIP has been around for a while, hasn't it? So it tends to be these things are a bit slower moving than the, the faster cloud platforms. But there's still work to be done. Now you touched on something important which is pushing the firmware device of the firmware. So for all the compatible devices, do you take responsibility for pushing firmware or there's some, the OEMs tooling and process updates. Those devices. Right. So I think there are there are some nuances there. so, so since we, we, so a wide variety of customers, we, we don't want to be making, assumptions that, whether, customer would have, the, the kind of, i.t environment and, and skills in-house to, to do their own firmware updates, right. Yeah. I guess, I guess your customer base ranges for SIP Gateway ranges from a small customer with one one hour ago paging unit through to like, or an Islip phone in a lift to thousands of devices. highly managed. Correct? Correct. So, so we we do have the option of, of managing, well, we don't manage. We just, we just roll out the, the firmware. It's still I mean, it's not our firmware. It's, it's still off the shelf firmware that's available. Yeah, from the manufacturer. But we do manage the roll out of that firmware, and we are responsible for, for, for giving the firmware to the device, if it provisions with us. Right. But we do this for, for a bunch of, IP phones, for example, for that we work with, OEM partners, because there is an, an on premise, installation also of DECT. So there, OEM partners manage the, the firmware, similarly for, for, for analog Gateways, we do not manage firmware for, for analog Gateways, and even even for, overhead paging endpoints. We, we do not manage firmware because I think these elements have, these device types have, and a significant on premise presence. So, when customers, typically have been, in the habit of managing these firmwares for these devices locally, so we don't manage firmware for, for these devices going forward, we would want to reduce, our footprint, in terms of, hosting and delivering firmware to, to devices. but the catch there is that, we we still need to ensure that, the firmware that, devices, I mean, devices connected to SIP Gateway are running on, still, able to support, scenarios. Right. So, so our scenarios need to be validated against, a certain, firmware version if we just make it kind of free of, for all, then the number of firmware versions that we have to, we have to test and, and, and support just explodes. So, so we cannot effectively, support and, and provide, good quality of service to our customers. Awesome. And so did somebody in the India team have a room with, like, tons of tons of IP phones of all the different, all the different devices. so, so the way we want to look at it is that, all of our, all of our engineers and, and the, PM’s based out of India, at least, at least on the SIP Gateway team. yeah. So everybody should have, experience with, with using SIP devices. Many times we, we join our, meetings from, from our SIP phones, right, to, to see what it is like, and and what are, customers, experiencing? We do have we do have a devices lab where, which is like, you know, a few feet away, and, and we just, have a, have a testbed of devices where, where we test and and validate these, these devices. Yeah. That's cool. So, so that's really helps us understand kind of how how you approve devices and how it works. What's the official stance on supports? Like, I'm, I'm a I'm a Teams customer. I've got SIP phones, a SIP Gateway. Where's the line drawn on who's responsible for what? so we, we are responsible as Microsoft for, for providing the telephony service on, on your third party SIP device, if it is part of our, enabled devices list, we are not responsible for the device itself. Right. So if you face, if you face issues which, say device related, then, then you wouldn't reach out to us. You would reach out to the manufacturer. Right? In some cases. In some cases, it may be difficult for, for you as a customer to determine whether it is a device issue or whether it is a service issue. Right. So in that case, you would you would reach out to us and, and if we determine that, hey, it's a service issue, we, we work on fixing it for you. If we determine it's not a service issue, then we, say, redirect you to, OEM partners and, and and put in a word that, hey, we got this, this customer, complaint, or support case about, such and such issue. We investigated and found that it's not a, Microsoft Teams issue. can you please take a look? And we have we have good relationships with all of our OEM partners. So, well, we try and keep, the, you know, the, the, time that, that, that issues spent in support to, to minimum so that. Yeah, that's what we show gets resolved quickly. Yeah. It's good to understand. And how how does it work from, that question I get it is how it works from, a licensing perspective. So you've got two scenarios here. You've got regular Teams, users that obviously could potentially also have a SIP IP phone. And then you've got things like the, the, DECT which tend to be shared devices or the Algo, you know, paging whatever it may be. So how does that work from a licensing perspective? Right. So, so from our perspective, right. a SIP endpoint, if it is connected, to, to SIP Gateway, is is just another Teams endpoint. So it entirely depends on, what account is associated with the device. And so if it's a user with, with regular Teams endpoints as well as, a SIP device, then whatever regular license is that, that they would need to, to, to use Teams would be applicable to us. We are not asking for any extra licensing, right? No. You know, they've got any. They've got the Teams phone license. They just get the same ability on a SIP device. Absolutely. So we're just another, Teams endpoint? if they're licensed to use Teams, then, it will work equally well on, on the SIP device. Similarly for shared devices. Right. So if there is a shared device account, it is licensed to to, to to work on Teams native endpoint. It would work equally well on shared. sorry. It would work equally well on a SIP endpoint. So again, so we're not adding, on top of any of the, Teams licensing requirements today. we we do require that, that SIP endpoints have, have PSTN connectivity. Okay. But in, in, the short term, we, we plan to, move closer to regular Teams. Endpoint by, by removing the phone number requirement. So essentially if you have, if you have a Teams alias, then then then you can, sign in and, and associate a SIP device with your account. So if I, if I only have an internal calling use case for whatever reason, I could, I could use it potentially without that PSTN connectivity. Correct. that's good to know. So a bunch of other things will need to happen for, for, for it to, fall into place entirely. For example, you would also need, a dial by alias, for example, right. Oh, yeah. Of course. Yeah. So, but but yeah, I think you're right on point. We, we do want to enable that. That scenario. Awesome. So I think I think it's giving us a really good understanding of where it is, how it works. I'm curious from, from your point of view, seeing the journey from pre launch to launch like, cloud services is so interesting because the scale is just a different different league and Microsoft massive. Well what's been most interesting or exciting from you on this kind of SIP Gateway journey. See the, the most exciting part and and what helps me, John up every, every day. with the, the same sort of energy is, talking to our customers, helping our customers meet their, with their telephony needs. Right? I, I thrive on it. I enjoy, meeting with their, their pain points and, and helping figure out, a roadmap that would, that would address those, those pain points. I'm, I'm also heavily, interested in all the, all the support cases that we that we get for, for, for SIP Gateway. So I try and spend a lot of time with, with, support engineers, and customers trying to understand how to, to, to solve for, the, the most, interesting and and challenging problems. That is what drives me. And, and that's why I've been here, with this team, for years and counting. And I plan to continue being here with, with, with this team, in terms of how I have, I've seen SIP Gateway evolve is, well, as, as I said earlier, we have, now when we, when we were in private preview, which was, say, summer, 2021, we were looking at enabling 2 or 3 scenarios. Make a call, receive a call, transfer a call. That's it. and, and from there to, to to where we are now, it's been immensely satisfying that. Hey, our our service is, is helping customers meet their, the telephony requirements and in, in some, mission critical scenarios as well. I mean, we, we would be powering, phones in schools and in universities in, in government agencies and police departments in utilities, in, say, an offshore, offshore oil rig or on all kinds of, work environments there. you would find SIP devices that, that connect to, to our service. So I think that's, that's a huge, huge honor customers have given us and, and, and huge responsibility as well. So, the way we see this going forward is that we want to, invest more in ensuring that, there's always dial tone, on, on devices connected to SIP Gateway. So we want to invest in reliability, invest in security, as well as, improving the admin and, and and user experiences and incentives. Awesome. yeah. It's super, super exciting. I think by the nature of SIP and your use cases, you're always going to be into some of the most, complicated and extremely unusual use cases, because that's where the, where the devices are. That's really interesting. Oh, Chandranshu thanks so much for taking the time. I appreciate all the time you give me on, on chat and things when we've come back and forward as well. I hope everybody's enjoyed the pod. If you've got any questions on, on SIP Gateway or thoughts or feedback, let us know as well. And, maybe we'll, we'll have you on again, maybe when we get this, you know, URI based dialing and have a conversation about that as well. It’s a pleasure, being here with you, Tom. And, and thank you so much for, for taking the time to, to to meet with us.