About Me

My photo
This is a blog for John Weber. One of my joys in life is helping others get ahead in life. Content here will be focused on that from this date forward. John was a Skype for Business MVP (2015-2018) - before that, a Lync Server MVP (2010-2014). I used to write a variety of articles (https://tsoorad.blogspot.com) on technical issues with a smattering of other interests. 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. 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:

test 02 Feb

this is a test it’s only a test this should be a picture