About Me

My photo
TsooRad is a blog for John Weber. John is a Skype for Business MVP (2015-2016) - before that, a Lync Server MVP (2010-2014). My day job is titled "Technical Lead, MS UC" - I work with an awesome group of people at CDW, LLC. I’ve been at this gig in one fashion or another since 1988 - starting with desktops (remember Z-248’s?) and now I am in Portland, Oregon. I focus on collaboration and infrastructure. This means Exchange of all flavors, Skype, LCS/OCS/Lync, Windows, business process, and learning new stuff. I have a variety of interests - some of which may rear their ugly head in this forum. I have a variety of certifications dating back to Novell CNE and working up through the Microsoft MCP stack to MCITP multiple times. FWIW, I am on my third career - ex-USMC, retired US Army. I have a fancy MBA. One of these days, I intend to start teaching. The opinions expressed on this blog are mine and mine alone.

2017/03/15

Inbound Call Failures due to TCP configuration

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. 

clip_image002

clip_image004

No comments: