I will not attempt to embellish this content past commenting that this call failure is not common. I have rarely seen it, most likely because my implementation practice for upgrades is to match system settings before testing.
Having said that, I think I would have thought the initial setup described here would have worked. But apparently not. Inbound calls follow the original port. Something to be aware of.
Thanks to Josh Walters, CDW Senior Consulting Engineer for writing this up for us.
YMMV
Scenario:
Customer is deploying a new 3-node Skype for Business Enterprise Pool to replace their existing 2-node Lync 2010 Enterprise pool. Enterprise voice is enabled in Lync 2010 and Lync call traffic is directed inbound from their PRI and delivered to an Avaya Session Manager appliance, then it is delivered to Lync. Internal call flow functions as below:
PRI --> Avaya Aura System Manager --> Lync 2010 Enterprise Pool
After deploying the new Skype for Business FE Enterprise Pool, Edge Pool, and Back-End we decided to migrate a test user who was enabled for Enterprise Voice to the new Skype for Business Pool and test call flow with the new infrastructure. The new expected call flow should function as below:
PRI --> Avaya Aura System Manager --> Lync 2010 Enterprise Pool --> Skype for Business Enterprise Pool
After moving the user, the user was able to successfully place an outbound call to both internal and external recipients but was unable to receive an inbound call. When attempting to dial the Line# for the migrated user we were being routed directly to Voicemail (Exchange 2010 Unified Messaging). What gives?
Inbound Traffic
Avaya Aura System Manager --TCP 5060--> Lync 2010 Enterprise --TCP 5060--> Skype for Business Enterprise
Outbound Traffic
Skype for Business --TCP 5060 or TLS 5067--> Lync 2010 Enterprise --TCP 5060 or TLS 5067--> Avaya Aura System Manager
Well, what we found was that Avaya was routing SIP traffic to Lync 2010 using TCP port 5060 only (as seen above). When Lync 2010 received the SIP request it attempted to route the traffic to the Skype for Business pool where the user is homed and it tried to use the same port it received the traffic on, but we had not yet activated TCP on the Skype for Business pool for Mediation. The Skype for Business pool was therefore rejecting the traffic and then sending the call to Voicemail.
The fix: Enable TCP (and make sure to use the correct port for YOUR environment) so that the Skype for Business pool is listening for traffic on said port. After enabling TCP 5060 on the Mediation Server (Collocated) all inbound call routing for the user started working.
No comments:
Post a Comment