For a complete, enriched Teams experience, we recommend customers use certified IP phones running Microsoft Teams natively and available on Teams Marketplace.


If customers have IP phones certified for Skype for Business, and are preparing for an upgrade to Microsoft Teams, the Skype for Business phones will continue to sign into the Skype for Business service and support a limited number of core functionalities listed below. There is no additional setup needed on the customer site for this to work. As customers prepare for the upgrade to Teams, they must consider deploying Teams native phones for a complete Teams experience.



Sign in with user credentials/Web Sign-in

Modern Authentication

Phone lock/unlock

Hot Desking Support


Incoming/Outgoing P2P calls from/to Teams users

In-call controls via UI

(Mute/unmute, hold/resume, blind transfer, end call)

PSTN calls

Visual Voicemail

911 support

Calendar and Presence

Calendar Access and Meeting Details

Presence Integration

Exchange Calendar Integration

Contact Picture Integration

Corporate Directory Access

Visual Voicemail


One-click Join for Pre-Scheduled Teams Meeting

Meeting Call controls

(Mute/unmute, hold/resume, hang up,

Add/remove participant)

Meeting Reminders

Add Skype for Business participant to ongoing meeting

Device Update and Management

Device Update

In-band provisioning

QoE & Log Upload

Common Area Phone Support

Regular Visitor

Just to clarify, is it a subset of the above listed functionalities that will be supported on SfB certified IP phones or all of the ones in the list?

@Nathan Chapman all features on this list are supported


Senior Member
Except that if you follow the links, you find out that there is currently ZERO desk phones for Teams, and ONE camera.

@Lorne Rogers, there are 3 desk phones listed. These desk phones from Audiocodes and Yealink are available. A firmware updates will provide native teams experience for these devices. The new portfolio of Teams devices announced this year are planned to GA in early 2019.

Senior Member
@Chantal De Menezes, when I filtered for "teams" zero results showed.

@Kruthika Ponnusamy, you specifically call out "Incoming/Outgoing P2P calls from/to Teams users". Am I reading this right when I assume this means I cannot answer Call Queue calls on IP phones certified for Skype for Business?


Microsoft? Is anyone monitoring these threads? Would be great to get an answer to my query above @Kruthika Ponnusamy @Chantal De Menezes

@Damien Margaritis When users upgrade to Teams, Call Queues will work via the native Teams IP phones. We do not support it today on Skype for Business IP phones.

New Contributor

Not that it will likely matter, but it’s just plain wrong that certified SfB phones will not support the full Teams feature set, particularly since SfB is being phased out after a relatively short lifecycle. Today, I discovered that you cannot admit an external participant to a Teams call from a SfB Polycom phone. Our organization uses conference calls primarily to communicate with external parties. Now, all Dial-in meetings will have to be hosted from a Teams client, not a phone. Technology should build on existing functionality and make work easier, not harder. Come on, Microsoft.

Occasional Contributor

@David Stradleysometimes you need to make a big leap in tech that means the old tech becomes redundant. Teams devices use REST whereas SfB devices use SIP. This is a fundamental change that means the older tech (Skype Certified phones) won't work on Teams. Whilst this isn't ideal, it opens up so many more capabilities in the future. Microsoft and device vendors are working hard to provide interop capabilities between Skype and Teams but there will always be edge cases that aren't catered for. It's certainly a downside of fast evolving technology.

Occasional Contributor

"This is a fundamental change that means the older tech (Skype Certified phones) won't work on Teams."


that CP960 though.


obviously these devices aren't hardware limited like they're running some hypothetical ASIC that only speaks SIP.  There certainly could be a fundamental change preventing companies from developing teams firmware for existing skype phones but it's not a technical one. it's a money one. 


in the yealink world at least the T4 series has full Opus codec support, but they want to upsell T5 series instead so they just don't develop a Teams firmware for T4 and then some sucker comes along and throws in "certainly a downside of fast evolving technology" as if he's not literally wrong and there should be some gestalt world-wide knowledge that companies are allowed to hand-wave away any criticism with "agile devops synergy oh well hey look new shiny" instead of fixing their broken business plans.


@Rob Geach It's got nothing to do with up-sell or lack of motivation to develop. The approach Microsoft is taking with Teams phones is to have devices from vendors run Android OS, with the (Microsoft developed) Teams app running on top. This is to ensure there's feature parity across all devices regardless of vendor: Microsoft is in control of the code base. 


If you want to know why Microsoft has taken this approach: https://dmunified.com/2018/11/15/devices-for-microsoft-teams/

Occasional Contributor

@Damien MargaritisI don't work for Microsoft so their motives are irrelevant to me personally, but in general companies have a fiduciary responsibility to up-sell and one of the ways they up-sell is by obfuscating their reasoning with unnecessary technical pleas.  For example, anywhere you see justifications about approaches taken, they're not talking about literal technical limitations like a "limited by the technology of my time" howard stark meme.  They're talking about selling you on the most expedient way they could accomplish their specific goals while costing them the least amount of money to generate the solution.  in the case of your blog, let's just hit the bullet points to find all the sales pitches that are happening.


"control end user experience" different is just different, not better or worse. Microsoft was actually reverse selling this feature not more than 2-3 years ago by claiming that each vendor was able to apply more aggregate resources and work in a competitive landscape to pull off 3pip interfaces that MS never would have been able to achieve by continuing the LPE program in-house.  So you can see this bullet point is 100% arbitrary depending on whatever story Microsoft is telling at the time.


"lack of feature parity" again this was being heralded as a positive in that it provided customers who needed more features to choose more expensive vendor solutions and customers who needed cheap phones the ability to give up some features. so basically how great flexibility and choice was in the crucible of the free market.


"Inconsistent delivery of new features" you had to push out new firmware whether it was tanjay/aries or 3pip so obviously you're not talking about that, but the functionality being pushed around in o365 tenants is anything but consistent so I know you're not taking that angle.  as for your naked assertion that it's maybe sorta not technically possible to code new features into existing firmware that has already been established as FUD or at bare minimum an additional development branch that Microsoft simply doesn't want to manage as "it doesn't fit with their approach" aka it will either be too much hassle or cost too much.


"there's no SIP in teams" so what? you wrote two paragraphs that boil down to "you have to use a different protocol to register."  so is the subtext here that developers are incapable of adding teams registration to a 3pip firmware?  because I'd absolutely love to hear a polycom or yealink dev admit that in a public forum.  Or are you saying the sip gateway to cloud voice is already in maintenance mode and microsoft doesn't want to develop against it anymore? because that goes right back to hassle/money again.


Now just to bring it all home, I'm 100% sure that Microsoft thinks they are making the best decisions for managing Teams as a live service over the next 10 years, but they've also over-promised and under-delivered in regard to voice services and supportability matrices in that area, and not just with their constantly changing definitions of "certified/optimized for Skype fully supported I mean mostly supported ok fine here's a subset of features that will work" and "LPE supported for Teams woops not supported afterall" and "TLS 1.0 actively blocked woopsie we just meant not supported" and their own personal mission accomplished variation "now has feature parity with SFBO". 


In a vacuum while reading about it in news articles and blogs it's all well and good but when you've got your MS rep squeezing you on how much better Teams phones are less than 2 years after replacing all LPE phones with 3PIP phones and then you have fasttrack consultants trying to change your plans just because Microsoft added a Skype CU one month ago that provided a new migration path and then you can't even get your PoC on how to handle 3pip phones interop with call queues definitively answered because now Microsoft doesn't want you to migrate SFB Server to SFBO before upgrading to teams because they want to deprecate SFBO... ok well that's all really annoying, but they haven't provided any guidance on migrating RGS agents to Teams call queues much less whether or not those agents will need new hardware or not.


So then you come to the realization that this is all done because they just really don't care that they were selling 2 year lifecycle phones and/or there is some program manager somewhere who has said in a private meeting, "they'll just have to suck it up and buy new phones if they want xyz" while completely ignoring the number of hoops that customers had to jump through just to get their 3pip phones purchased. And then you come across some post that talks about how this situation "isn't ideal" and that this consolidation in direct opposition to what they were selling not very long ago "will open up many more capabilities" while failing to name a single capability other than that it will make the Microsoft devs' lives easier.  Then yes, at that point I will go out of my way to say that at a very fundamental level these are all arbitrary excuses that sit on a throne of lies.  and at that same level, the reason you're getting limited backwards compatibility is due to both money and hassle or some variation thereof so as far as I'm concerned coming from the perspective of a Microsoft customer I'm completely justified in my irritation regardless of their reasoning for doing what they've done.  It's the ends that are the problem here, not the means.


@Rob Geach I am the "program manager somewhere" who two years ago proposed a new generation of Teams Phones, which actually run our Teams app, UX, and media stack.  I did this after 6 years of running the team at Microsoft which worked with our partners on 3PIP phones and other devices.

With that context, I will say that @Damien Margaritis is absolutely correct in his statements. 3PIP phones and other protocol interop devices (where the partner used their own media stack and UX) worked fine in an on-prem server world, but simply did not work well in a cloud service world. There was no reasonable way to expect our partners to keep up with us in new FW releases. Every FW release would be outdated, and have a ton of known issues, the day it came out.  Our customers were complaining about inconsistent feature support across 3PIP phones, and about lack of overall reliability.

Could we have figured out some way for partner devs to do something on Linux based, older, under powered phones to register to Teams?  Maybe, but it would have ended up looking exactly the same as what we ended up doing with 3PIP phones, which is supporting them with "basic functionality" via a SIP gateway we built.  That's the reality of us having built a new, born in the cloud, communications service for Teams, which is aimed at delivering a higher level of quality and reliability, and does not have SIP support. 

As far as LPE phones, we had communicated the impending end of life for those a long long time ago. Those phones are based on a 10 yr old version of Windows Embedded CE (and I also used to be in the Windows Embedded business at that time btw so have some insight on that), and as you said they do not support TLS 1.2 as the OS level, so are inherently not secure.  For us to have "updated" these, we would have needed to choose a modern "small OS", and a modern client, and that's exactly what we did with Teams Phones, which are Android based and run a Teams Android client.  Unfortunately the HW for LPE phones was so old and under-powered that there was no way for us to do a FW upgrade to make them Teams phones (btw we actually invested in re-writing the old LPE client twice to get around the brutal memory limitations on those devices).

I'm sorry you feel there's some "throne of lies" here somewhere, but really there's not. We are doing our best to work through all of the limitations of older technologies and HW, while at the same time trying to meet customer asks for a higher bar of phone user experience and reliability with Teams. 

I can sense your frustration on this topic, so would also say that I would be happy to listen and/or discuss this further on a direct call / Teams meeting with you, so please feel free to pm me if you're interested. 


@Rob Geach I understand your frustrations. We have dozens of customers that are coming from the Lync\Skype for Business world and moving into Microsoft Teams, we provide guidance, roadmaps and the like specific to their requirements, taking into account existing devices they might have not just across their user base but in meeting spaces as well. The article I wrote that explains where we came from and where we are going was written to address precisely the misconceived notions you've stated above. I would also say the points you raised after reading my post make little to no sense: This article wasn't written from the perspective of Microsoft, nor was it written from the perspective of a Microsoft partner (which my company is) that is being "squeezed" (your words, not mine) into relaying their message. The article was written by me: an industry UC professional that has the knowledge and experience to provide a balanced perspective on this topic. You've chosen to introduce your own bias when reading it.


You also seem to assume that Microsoft is the one selling the phones here. They're not. I would be very surprised if Microsoft cares one way or the other what specific end user device you use, as long as it's supported, and that the user experience is consistent.


Nothing was "done because they [Microsoft] just really don't care". I'm totally over hearing this narrative. A new platform was released: Microsoft Teams. It's taken off, one reason being because it left all the baggage of LCS\OCS\Lync\SfB behind and built fresh on a new hyper-scale platform that made sense in this cloud first modern world. It's built on an entirely new protocol, and no, you can't just get a SIP device and "make it work". To your original point, Teams works on a Yealink C960 because the device already happened to run Android, which aligned with Microsoft's strategy for Teams devices.


Is there some pain moving from one to the other? Yes. I know, because I work with dozens of organisations that need assistance to get there. You can keep complaining, making broad assumptions that this is some kind of corporate money grab, or you can get on with it and move forward.


The lack of call queue support on 3PIP phones is a big issue. We have several clients that went with SfBO and invested in 3PIP phones within the last two years and are now being told they need to rip and replace (less than two years after making a large investment in Microsoft's solution). They all use call queues extensively and need to answer inbound calls using physical phones (this includes health care providers, police departments, etc., where soft clients are not a viable option). Please, Microsoft, rethink your stance on this issue.


@John Joseph we support call queues with 3PIP phones and Teams right @Kruthika Ponnusamy ?


@Ilya Bukshteyn I don't think so, unless something has changed recently?



New Contributor

@Ilya Bukshteyn 
3PIP phones from AudioCodes, Polycom and Yealink with Skype for Business firmware do not work properly when answering a call queue in Teams.  the phone will start ringing and looks to be calling back to the calling number then hangs up and the call goes back into the queue. Most of these phones do not have option to upgrade to the Android based Teams firmware.

I  have dozens of customers that are on Skype for Business online that rely heavily on call queues that use AudioCodes phones to answer.  Many of them are getting notices that they will be moved to Teams by the end of the Month. (we are having to go in and postpone these changes.)


If they do slip through and are migrated to Teams, their business is completely immobilized by the lack of being able to answer a call queue.  

Asking them to throw out their 3PIP phones they purchased in past 2 years, (being told that 3PIP phones that supported Skype for Business online would also work with Teams), is not something that they are willing to accept. 


It makes Microsoft look bad and it makes us (your partners) look bad.


Please let us know if Microsoft is working on a fix for this or put out a definitive statement that you are not supporting these phones.  (BTW, you will lose a lot of customers by not supporting.) 


Fixing Call Queues is the ONE issue I have left in recommending moving to Teams for the dozens of clients I have on O365 Phones.


Please make this a priority to fix!

Senior Member

Has anyone tried posting about this on other forums that MS is known to watch?  Like Linkedin?


Hi @Ilya Bukshteyn ,
It was not working about a month or two ago, when last I checked (I will try again). There have been some indications that it would now, not be supported (even though, originally, it was supposed to be). @Kruthika Ponnusamy 's post from December 20th indicates that, at that point, it was not supported (see above). In other posts on the Internet, people calling in about the issue have received feedback from Microsoft that they need to purchase new phones.

In many cases, my customer's phones are barely a year old and they will need to re-invest in new phones in order to stay with Microsoft. These were early adopters that tolerated long pickup delays, having to purchase additional licenses just to forward to outside numbers or have department voicemails, etc. Keep in mind, SfBO did not become a viable phone replacement until August 2017 (when the Organizational Auto Attendant was released). The customers we deployed were subsequent to that date.

Thanks for listening,
John Joseph

Frequent Contributor

Without meaning to sound overly dramatic, I'm currently in danger of losing a major client over this issue. They were in desperate need to adopt a new VoIP phone system last fall, and were already using Teams. They purchased a fleet of Polycom VVX handsets, only to be left in a lurch with regards to the lack of Call Queue support (not to mention other missing features that they naively expected to have in phones that were advertised as "Teams Ready"). One could argue that I should have advised against it, but frankly keeping track of what is/is not supported in this environment is a nightmare that seemingly changes daily.

Senior Member

@Bob Manjoney  What has the MS account manager for the client said in response to this?

I am looking into this right now. I will provide an update in a day. 


A bug was identified that impacted some scenarios where the agent is on Teams and using a 3PIP phone. This issue was fixed in a call queue service update that started rolling out to customers gradually, we expect the rollout to be completed before the end of this week. The best forum to get an issue resolved is Microsoft support, where a ticket will be created and tracked with relevant teams. 


@Waseem Hashem ,

Thank you! We will test it shortly and post back. We are able to replicate the issue 100% of the time.


New Contributor

@Waseem Hashem 


Is there a way to know if the fix has been rolled out to a tenant other than trying to answer a call queue on a 3pip phone?

my tenant still does not, nor any of my customer tenants that I have tried on.

New Contributor

I am looking into this right now. I will provide an update in a day. 

Any update on this today?


Quick update from my attempted test:

  • I created an E5 test tenant and assigned my test domain.
  • I created users, assigned licenses and voice enabled.
  • I created a test distribution list.
  • I obtained a domestic call plan trial.
  • I obtained service phone numbers (this was done using the legacy portal).
  • I created a call queue (in the legacy portal).

This is where I realized there has been a dramatic change. It automatically created a Resource Account and assigned the phone number I had assigned to the call queue in the legacy portal to the number. Resource accounts are a new option under Org Wide Settings. I looked at one of my customers Teams Admin Portal and noticed under Voice, that they had the option to create and manage Auto Attendants and Call Queues from the Teams Admin Center, without having to go to the legacy portal and the options are different. You can assign a resource account. My test tenant does not have these options, yet (nor do my other customers). Apparently the way AAs and CQs are managed and licensed has dramatically changed (yes, they now need to be licensed, if they are assigned a phone number). On the bright side, you can now use on prem phone numbers as service numbers with Direct Routing.




My testing is on hold until the test tenant I am using gets the updated tools for managing AAs and CQs (PowerShell commands don't even work, yet). My guess is this tenant has not seen the updates mentioned above, yet. Hopefully we will get them by the end of the week.


I deleted the call queue I had created in the legacy portal and was able to create and assign licensing and a phone number to a deliberately created resource account, but I cannot yet create or manage a call queue (or auto attendant).


I will post an update, when I have one.


@John Joseph if you can see your AA/CQ in the Teams Admin Portal that means your tenant has been updated already. you can test there. on the licensing, this is a temporary requirement as stated in the documentation until we release a cost-free app license model (work in progress). There is a new set of Cmdlets for the updated service, you can find them in the documentation. We plan to complete the rollout of the update early next week. 


@Waseem Hashem Thank you. I saw that it said that Microsoft was working on new licensing, but it did not indicate costs. It is good to hear it will be cost free. A couple of my customers have quite a few CQs and AAs. One of my customers, a GCC account, has the AA/CQ tools showing up in the Teams portal, but the others do not yet. My lab account does not have it yet. I saw a post on another forum, where someone had confirmed answering CQs from a VVX is now working, when that shows up.


I am excited about support for on prem service numbers (with Direct Routing). This is something we have been waiting for, as we now have to forward the numbers back out to a cloud service number from the SBC (I have two customers with CCE deployments).


It was mentioned that the Teams client will not be supporting Better Together over Ethernet (BToE). Can you confirm that?

@John Joseph BTOE will not be supported on 3PIP phones and Teams desktop client. We are working on a pairing solution (using Bluetooth) for native Teams phones. 


@Kruthika Ponnusamy  Thank you for the quick reply. We will plan around that.
Occasional Contributor

Just want to point out things are still a hot mess. Several times a day at least 2 - 3 of our phones need to be power cycled to stop the issue with call queue calls getting put on hold upon picking them up. As of today I'm rebooting all phones from the dashboard at 6am each day in hopes that will give them a chance of making it through the work day without the issue. Who knows, either way Yealink and Microsoft should be embarrassed.


@jcorbs The issue(s) you described should have been fixed already (and btw it was on our side, not our partners at Yealink).  Tagging @Kruthika Ponnusamy  and @Waseem Hashem to see if they can help further.

Occasional Contributor

@Ilya Bukshteyn @Kruthika Ponnusamy @Waseem Hashem

Hello Everyone,

Let me start by saying I'm sorry if I came across as unprofessional, but I lost my cool as I've been fighting phone issues for two months now and aside from losing lots of my day to ongoing phone issues I'm starting to have my team lose faith in my abilities to admin our phone system. Anyway, let me explain what's going on.


The original issue we had was with the call queue calls being answered an automatically being put on hold, I documented that issue here: https://youtu.be/brw8oj31NA4.


In the last firmware update (v58.15.0.36) for the T58 and the Teams app (v1449/ the issue seemed to be resolved (at least with my testing).


Here is how we come across the issue now:

  • Assuming a phone has just been logged into the call queues should work as expected
  • Over time all phones will eventually begin to see the call queue bug again exactly the way the above video shows it from months ago
  • Power cycling the phone (removing PoE cable) may fix the issue or it may not
  • Remotely rebooting the phones from the admin dashboards does not help
  • Remotely rebooting the phones may cause phone to not even ring when a call queue call comes in
  • The only "reliable" solution thus far is to log the user out and log them back in
  • Sometimes phones will hang during the log in process requiring a power cycle (removing PoE cable)


As of today our new policy is to have all users log out of their phone at the end of the day and then log back in the next morning, ideally this will get us through a work day without issue, but we'll have to see. Anyway, as you can see the issue is not fixed, at least for us. Perhaps our "Tenant" has not been updated with the fix, but I can assure you we have real problems and I need a fix soon. Thank you and please let me know if there is anything I can do to expedite getting a patch released to address this issue once and for all.


@jcorbs first of all let me apologize for this messy situation! The best channel to get issues resolved is a support ticket where logs can be gathered and analyzed. I will reach-out to you for a quick chat, if you have a ticket then we can follow-up on it, otherwise we should create one for tracking. 


My test lab migrated today and I have confirmed that I can now answer queue calls on a Polycom VVX phone (3PIP) in Teams Only mode.


@Waseem Hashem When do you expect the cost free app licensing model to be released? One of my clients is a municipality (GCC) with an EA, so if they commit to licenses, they are stuck with them for a while. They have quite a few service numbers.




@John Joseph did you answer the ringing call on the VVX handset? We tested with Voice V2 Teams only voice user, VVX rings but no media connects on answer.


@Damien Margaritis Yes, I was using a Polycom VVX 411 phone and it worked perfectly. The answer delay was similar to SfBO (about 3 seconds), so acceptable.

Has your tenant migrated? Did you build a new queue or utilize an existing queue? You might try making a fresh queue for testing, as my test was on a queue that was built after the migration (including the resource accounts).


@John Joseph  around July time-frame, hopefully before, pending validation and quality testing. 


@John Joseph yes to all the above. We've been a member of the voice v2 TAP for sometime, tested with a new CQ - same result. Australia region has been completely migrated to new voice back end. 


We're going to do some more testing and see if we can find a solution.


@Waseem Hashem Thank you for your help. I now have Direct Routing functioning in my lab and I can make inbound and outbound calls to a user with a Direct Routing DID. I am not finding any documentation on how to assign a Direct Routing service number to a Call Queue or Auto Attendant and the portal does not give the option (I assume it is through PowerShell, though). Can you direct me to the documentation?




@Waseem Hashem Ok, we figured out that Set-CsOnlineApplicationIntance lets us assign an -OnpremPhoneNumber to the RA account. The queue will then ring and it connects, but we are not getting audio. Still troubleshooting. Media works for inbound and outbound DID calls. Getting closer.

@jcorbs I've sent you a message. With the latest Teams app (v1449/, you should not see any more audio issues with call queues. There is no need for users to log out/log in everyday for this to work. Please reach out to me if you are still hitting this issue.


@Waseem Hashem We did some more testing (the results have been replicated several times, so they are consistent):

  • We have created the following
    • Test Queue 2
      • Cloud Service Number (XXX) XXX-XX27
      • Transfer to voicemail after 15 seconds
      • E5 License and Domestic Dial Plan assigned
    • Test Queue 3
      • On Premise Service Number (XXX) XXX-XX41
      • Transfer to voicemail after 15 seconds
      • E5 License assigned
    • Test Queue 4
      • No phone number assigned
      • Transfer to voicemail after 15 seconds
      • No licensing assigned
    • Test AA
      • On Premise Service Number (XXX) XXX-XX42
      • Transfers to Test Queue 4 (24x7)
      • E5 License assigned



(XXX) XXX-XX27 (Test Queue 2)

(XXX) XXX-XX41 (Test Queue 3)

(XXX) XXX-XX42 (Test AA – Test Queue 4)

Answer with Teams Soft Client (Windows)

Successful – Call answered and two way audio

Failure – Both sides show the call connected, but neither side can hear audio

Failure – Both sides show the call connected, but neither side can hear audio

Answer with VVX 411 Phone

Successful – Call answered and two way audio

Failure – Phone side shows connected, calling side continues to hear music on hold. Held for over two minutes, with no change.

Failure – Phone side shows connected, calling side continues to hear music on hold. Held for over two minutes, with no change.

Transfer to Voicemail

Successful - Transfers in about 17 seconds – Two way audio

Successful – Transfers in about 37 seconds – Two way audio (I could hear the announcement and left a voicemail that could be heard)

Failure – Transfers in about 37 seconds – Could not hear voicemail announcement. A voicemail is left, but it is a blank audio file (even though I was speaking).


and as noted before, calls to a user with an on premise DID worked, as did out bound calls from the user routed through the Direct Routing path.


I did open a ticket, but other than an initial response, I have not heard back.




We've been informed by Microsoft that our Office 365 tenant will be "upgraded" to Teams in June. Our Yealink T42G SfB phones use SfB firmware and licenses. Yealink don't appear to be offering a firmware upgrade for these phones. 


Can somebody please put my mind at rest that our phone system will continue to work when we are force-upgraded to Teams. Our pilot of Teams is going okay but this would be a showstopper...


@Helios Comms The 3PIP phones (SfB) will work now. There was an issue with using them to answer Call Queue calls, but that has been resolved. The Better Together over Ethernet functionality is not supported with the Teams client, so that will be lost. You will need to deploy the Teams client to your users who use a soft client (and provide training). The auto attendants and call queues should have been migrated to the new management tools in the Teams admin portal. If you are using CCE, you will need to replace it with Direct Routing. You should be able to request a deferral, if you cannot meet the migration deadline.