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:

The 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:

• https://tools.ietf.org/html/rfc5939
• https://andrewjprokop.wordpress.com/2013/09/30/understanding-session-description-protocol-sdp/

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!