About Me

My photo
TsooRad is a blog for John Weber. John was a Skype for Business MVP (2015-2018) - 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 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.


Lync 2013 with Cox SIP Trunk

I recently participated in a project where the SIP trunk provider of choice (the customer’s choice – not mine) was Cox.  As a refresher, here is the validated SIP Trunk provider list.  As a best practice, choosing a provider from the list means that the service offered has been vetted against Lync, and will work as expected with a base Lync setup.

Needless to say, we had “issues.”  Here are four things you may run up against if you choose to use Cox as your SIP trunk provider with Lync Server.

First, Cox provides their own E-SBC (Enterprise Session Border Controller).  This unit is setup by default with ONLY UDP.  You need to tell Cox that Lync does TCP and UDP.    And no, I do not know of a way to make Lync do just UDP.

Second, the Cox Lync 2010 setup guide on pages 29-30 indicates setting up the PSTN gateway with EITHER FQDN or IP. Their guide text and pretty pictures show using an FQDN. 


Guess what.  While that FQDN may have worked in their test lab, it does not work in real life.  You MUST create the Gateway and Trunk with IP.  If you are using FQDN with the Cox gateway and noticing that the Cox gateway is ignoring all of your SIP OPTIONS requests  - then this will fix it.


Lastly, once we got past those two issues, caller ID did not work for outbound calling.  Make sure to clear the check box for “enable forward P-asserted-Identity data.” MVP Brian Ricks has a nice explanation of why this is so. After letting that change percolate, you should have your caller ID for outbound calls.


Finally, we could not get calls to forward very well  - as in not at all.  Going back to the trunk configuration, set the refer support to NONE.



No comments:

Sfb 2019 July 2019 CU

Script to update sfb 2019 install to enable the new control panel contained in the SfB July 2019 CU. Add-WindowsFeature RSAT-ADDS, Web-Serve...