SfB Server – Sonus SBC SIP Trunk – No audio during calls

I have recently been troubleshooting an issue a customer had been facing since installing a SIP trunk from a UK Provider in preparation for a migration away from older ISDN circuits. In this deployment, the customer had already configured the SIP trunk and calls inbound and outbound to and from end-user assigned numbers were working fine, two-way audio, good quality and calls were staying up without any issues.

The problem was apparent, when a call was made inbound to the on premises SfB Server PSTN Dial-in access number. Whenever a call was made to these numbers, the calls would establish, but no audio was being sent from the Conferencing Auto Attendant, greeting a callee and offering meeting ID and pin entry options.

As I hadn’t configured the SIP trunk myself I did the usual checks and reviewed the configuration of:

  • Signalling groups; which were configured correctly (inbound/outbound calls were OK)
  • SIP server tables; which were all defined for both SIP provider and SfB
  • Media lists were in place, the provider used G711 and the appropriate TLS media list was in place for SfB
  • SIP profiles were configured correctly

Using the Sonus logging tool, LX, from a bird’s eye view of the call, I could see the invite being accepted, call being setup and teared down correctly:

Call flow setupThe next step for me was to review the invite, from the outside in (inbound call), firstly reviewing the SIP invite and SDP negotiation between the provider and our SBC appliance. The invite was a routable IP address in our signalling group and SIP server table (ITSP IP) coming in to our internal IP interface for this SIP trunk…


…but then looking at the SDP negotiation, I noticed that for the media endpoint being offered within the SDP (referred to as ITSP IP2 below), the SBC did not have a static route back available to it, and all traffic to this IP address would be sent to the default route 0.0.0.0, pointing to an internal gateway (and therefore no way of reaching the ITSP):

The SDP negotiation provides valuable information, from the media processing endpoint, to the codecs and capabilities of the call. For further reading, the following are good references:

The customer has decided to strictly define the endpoints presented to them by the ITSP, in the static route table using a /32 notation and therefore would need to explicitly define each of the endpoints required for communication to ensure correct routing. In this instance, an IP address had been missed but by correctly configuring the static route table in the SBC to account for this IP (ITSP IP2), we were now being presented audio for inbound calls to the conferencing service.

An important note I would like to make is that in this scenario, it is crucial to ensure that all endpoints/networks have been accounted for – I continued to work with the customer to ensure that the static routes covered all potential endpoints as there is the potential for the ITSP to failover between endpoints and therefore reintroducing the issue we have faced above!

Advertisement

Lync Phone Edition Devices – Not updating

During a recent engagement, I had ran into an issue updating the firmware version on Lync Phone Edition Devices.

I initially kicked off with checks around DNS, Certificates, Ports and everything checked out but phones would still not update.

Test Devices had been configured correctly (using serial number and one using MAC) – still no joy.

The IIS logs are extremely useful; Jeff Schertz has excellent blog posts on Configuring LPE for Lync and Updating LPE devices which go into reviewing the IIS logs. In summary, it enables you to confirm whether devices are communicating with the device update site running on within the front-end pool, or in our case – NOT.

Continue reading

Lync Networking Guide v2.3 Released!

Microsoft have released a new version to the [Amazing] Lync Network Planning, Monitoring and Troubleshooting guide.

I have recently passed 74-335 Network Readiness Assessment and must say that understanding the Microsoft Network Assessment Methodology along with this guide was absolutely crucial.

Now at v2.3, it seems to have been updated with additional Wi-Fi and QoS Guidance, the following extract has been taken from the download site;

“An updated version of the Networking Guide is now available including the new Microsoft Call Quality Methodology Scorecard for Lync Server. This scorecard should be used to implement the Lync Call Quality Methodology or CQM as outlined in Appendix C. CQM is a holistic way to systematically define and assert call quality based upon the methods outlined in the Networking Guide. CQM divides a Lync implementation into ten discrete areas that impact quality, defining targets and a remediation plan for each one. CQM is a framework to tackle call quality problems – you can modify or extend it to address the particular conditions on your network. Appendix D includes techniques to troubleshoot poor streams that CQM surfaces.

The Networking Guide download now includes the list of Lync Server 2010 and an updated list of Lync Server 2013 KHIs to validate server health, a complete set of CQM queries, and a PowerShell script file to collect KHI data.”

Download Microsoft Lync Network Planning, Monitoring and Troubleshooting Guide