Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

migrating from Avaya to TEAMS Telephony - anyone have feedback on Polycom phones?

Status
Not open for further replies.

learningSkype

IS-IT--Management
Jun 6, 2016
213
0
0
US
we're migrating some of our folks from Avaya to TEAMS Telephony. has anyone used Poly CCX phones to register them to TEAMS in the Cloud? what was your experience like, can you share any pain points or thoughts on the phones and reliability on the Cloud?
 
They're supposedly supporting any SIP phone now...
I'd imagine the J's will eventually be compatible, but you probably don't have those anyway.

I gues just check the station programming - if they're all basic phones with a few call-appr, then fine. If you've got brdg-appr, you'd need to program what I believe is a delegate in Teams for the equivalent functionality. Basically, the more features you have, the more complex it'll be if you find out you really need to keep them.
 
thanks Kyle. you always have a lot of good info/feedback on this forum.

But I'm more interested in the experience relevant to the CCX Series phones and how the deployments have panned out. I know Tek-Tips forums lean heavily towards Avaya, Nortel, Mitel, etc., so not sure anyone here has had actual experience working on those phones and registering them to TEAMS in the Cloud.
 
Cant comment on MS teams. Only Webex Teams. But I dont have anything nice to say so I wont say it.
 
Well, past experience - the 9641 was the "fancy" Avaya IP phone. Heavy users hate touch screens.

The doc for Poly says it's basically a Teams Android client - probably modified to some degree.

I've supported a customer with a large deployment of Polycom conference phones. One day we changed the SIP server IP to not go through an SBC anymore. So I had to debug log the SIP messages from an Oracle SBC to a giant text file, filter user-agents Polycom, and use Sublime Text and some sed to get the IPs of them.
Then I had to open 200 browser tabs to those IPs and login and change the SIP server.

So that's when they got a Polycom provisioning server. Kinda like AADS/Utility Server. The phones will grab "my mac address.cfg" and they'll probably learn to register.

You'll probably use LLDP to get them on the voice VLAN and because it's running Teams firmware it's probably going straight to MS and because MS supports Poly, once you have your device configured in Teams, MS will probably have that phone's MAC.cfg waiting so the phone comes up automagically. Broadsoft is the same - J100s are supported on it and J100s can get their MACaddr.cfg, so Broadsoft knows how to spit out config files for many different vendor devices. I assume MS Teams does as well for the phones they support.

Poly also makes a dock

Plug your cell in and go. I think it's smart enough to tell the cell to tell Teams that you can use Teams on your laptop but the call is on the mobile dock.

Just depends on your users. I like buttons. If they're in an open area, the screens will get beat up and if you don't lock them down right I'm sure someone will break out to Android and find their way on to pornhub or something.

End of the day, if the use case is Teams on PC driving the show, then who cares what the phone at the desk is. If these are phones for people without PCs and they rely heavily on them, i'd be skeptical about the screen. I want to use a regular phone, not a cell phone pretending to be a regular phone.
 
Well if it is a Polycom CCX Teams Certified Device, to my understanding the software is made to make configuration and the User Experience very user friendly to end users. Login for end users is just done via Azure Active Directory to my understanding. I am curious about Teams and Avaya integration. Are you using direct routing to integrate Teams and Aura together or is it in a standalone? If they are integrated, are you using an Avaya SBC or third party?
 
Avaya's SBC is certified for Direct Routing
 
yes we'll use Direct Routing on Ribbon SBC's. the calls will come in on SIP trunks, land on the SBC and then get steered to Avaya or TEAMS.
 
One think that I saw researching was Ribbon and AudioCodes SBC's can be deployed in Azure marketplace (not IaaS). If you don't need to have FXS/FXO or local survivable site. Are you doing it in Azure? I am curious if you have to upgrade the SBC software on Azure or if it is SaaS. I assume upgrading the SBC is automatic upgrade and it is just administration
 
Upgrading an Avaya SBC doesn't need a new VM, it's just in the web page.

Functionally speaking, there's no reason learningSkype couldn't do what he's talking about with an Avaya SBC on prem or in Azure.

But Ribbon SBCs have some very cool features.

As a carrier, if I were to deploy a customer their Edgemarc device on prem, it's basically like I deliver them an SBC. That SBC pulls its config from my cloud provisioning and I deliver the trusted interface to the customer. For me as a SIP carrier today, I have a DevConnect doc showing how to setup your Aura to a Avaya SBC to my SIP trunks. With a Edgemarc, my DevConnect doc removes the Avaya SBC and just says "point your SM SIP entity to the Edgemarc"

Those devices can also feed in to Ribbon's analytics suite so the SBC can send RTCP stats up to the carrier and you can see if the packet loss was on the customer or carrier side.

Different models can also have PSTN trunks on them and be a SIP registrar for failover. So a smaller branch dosen't need a LSP.

And if I had a customer that didn't want to move from PRI right away, I could deliver SIP from my carrier PSTN to some models of EdgeMarc and deliver PRI to the customer so I, as a carrier, can still deliver PRI to those who need it without maintaining the TDM infrastructure at the CO.

I really really like them and wish I could use them!
 
But to my understanding, you have to deploy the SBC on a Azure VM in a IaaS model and have to manage upgrades on the Avaya software/patches correct?


I am curious if you deploy the Ribbon SBC SWe with the Azure Marketplace instance (not deploying on the Azure VM), would that automatically manage software upgrades and patches? Has anyone had experience with this? It seams like a really cool concept.
 
we have not. our Ribbon SBC's are on-prem and we have SIP trunks going to TEAMS. so everything is physical in our space, no IaaS and no SBCaaS.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top