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!

Advertisements

Sonus SBC SIP Trunk Config (Registration Mode)

I have recently been tasked with the deployment of a new SIP trunk for an office in Hong Kong, working with a relatively new SIP trunking provider in this region.

The deployment topology itself is straight forward; centralised SfB 2015 pools deployed to central sites, with local gateways servicing local PSTN connections at each geographically dispersed office location, a distributed SIP trunking topology. Each of the local site gateways was provisioned with SBA functionality. The local gateway being provisioned was a Ribbon SBC1000, very familiar technology.

Our SIP circuit was a registration mode trunk, meaning that a registration process must be completed with the trunk to authenticate and then subsequently, each outbound call would also need to respond to a challenge request.

This was the first trunk I had encountered using this mode so I thought it would make a good blog entry. This post, won’t go into the depths of the initial configuration of the gateway and SIP circuit, but will focus on what is needed that is different to the typical SIP trunk configuration.

From here, I assume you have deployed the following:

  • The initial SBC configuration, networking, hostname and SBC certificate
    A signalling group has been created representing the PSTN provider (we will apply additional config here)
  • A signalling group has been created representing an SfB Pool / SBA / STD Edition server
  • Call routing tables have been created
  • Call transformation tables have been created

If you do need some advice on the above, the following blog article but my friend Mark Vale is a great multi-part walk-through:

https://blog.valeconsulting.co.uk/2016/02/29/skype-for-business-and-sonus-part-1-getting-started/

So assuming the above is all in place, the very first thing to configure are the Contact Registrant and Remote Authorisation tables which can be found under the SIP configuration node. I have seen references to configuration guides that state, that only the Contact Registrant table is required, certainly in my instance I had to configure both tables.

The Contact Registrant contains information in relation the Realm and User ID used when registering on the trunk and the Remote Authorisation table contains the credentials. This was my first hurdle and it purely came down to a language translation barrier so one word of advice would be really to clarify that you have all of the information required and in a supported format for the SBC1000.

The following settings were applied across my tables:

Contact Registrant Table:

Contact Registrant Table

 

 

 

 

Remote Authorisation:

Remote Authorisation Table

 

 

 

 

 

 

To confirm that you have successfully registered, the easiest way is to simply view the status of the contact registrant table, for further confirmation you can also monitor the registration request via LX or Wireshark, you will see a 200 OK response for a successful registration. Any failures at this point are likely to be due to the realm, user ID or password across the tables.

 

 

 

 

 

 

 

Once the trunk is registered, like me you will be tempted to make a test call (in my instance I actually believed I had the configuration ready). Now depending on your trunk, these calls may be OK, my test calls were failing and upon viewing an LX trace from the gateway, our provider was immediately responding with 404 User Not Found for a valid local HK telephone number:

404 not found

 

 

 

 

 

 

I went back to the provider and requested [politely demanded] additional configuration information. They responded this time with an internal configuration guide, that, would have been useful at the very start!
Within this guide, the provider stipulated the following:

  • From: DN@sipprovider.com (for example  21111111@sipprovider.com)
  • PAI: PilotDN@sipprovider.com (for example 21111111@sipprovider.com)

This is significant information needed on the trunk for the correct presentation of the call, to the provider before they will accept the call.

To manipulate the FROM header, I initially did a literal replacement of the entire FROM field, resulting in 21111111@sippovider.com being presented using SIP Message Manipulation.

SIP Message Manipulation

 

 

 

 

 

I also did the same for the HOST portion of the PAI field and replaced it with SIPPROVIDER.com

So now, my invites outbound, to the best of my knowledge, should be presented in a format that the provider accepts – boy was I wrong.

Upon sending an invite now, the provider was sending a 401 Challenge Request which was expected, now the issue was that our SBC was simply not responding to the challenge request and re-inviting without any authentication

Invite:
INVITE sip:21111111@sipprovider.com:5060;user=phone SIP/2.O
Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, OPTIONS, REFER, REGISTER, INFO, UPDATE, PRACK
call-ID: call-6A941SOO-OOOO-0010-1911-A@10.239.42.81
Contact: <sip:21111111@local-sbc.com:5060;transport=UDP;maddr=1.1.1.1>
Content-Length: 308
Content-Type: application/sdp
cseq: 2 INVITE
From: <sip:22222222@sipprovider.com:5060>
Max-Forwards: 69
Min-SE: 600
P-Asserted-ldentity: <sip:22222222@psipprovider.com:5060>
Session-Expires: 3600
Supported: replaces,update,timer,100rel
To: <sip:21818888@pccwone.com:5060;user=phone>
Via: SIP/2.O/UDP

This one had me stumbled for a couple of hours, I started looking at the logs, line by line and then noticed that the FROM: field, did not contain a ;tag=xxxx;sgid=x, this tag  information is what a UAS uses to determine that a call is not a duplication session (if you want to dig a little deeper https://www.ietf.org/rfc/rfc3261.txt), and which signalling group should manage the connection and without this our SBC was not responding as we would expect it to. It can be found correctly formatted in the image below:

 

 

Confirmation of this theory became apparent when I found the following errors in the SBC log:

LX Error Log

No tag value in FROM header, it then goes on to fail to find a suitable signalling group.

Taking a step back reviewing my options I decided to revert the FROM manipulation and not implement it using SIP Message Manipulation, and use the more simplified SIP profile options to set a static FQDN for both TO and FROM fields:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

This did the trick, my call was correctly presenting ALL required ITSP information, calls were not permitted inbound and outbound!! SIp Message Manipulation could have achieved what we needed in this point, but the SIP profile is easier configuration for anyone to pickup and read so we opted for this method.

Additional notes:
We were using EXT prefix in a user Line URI and this was affecting the presentation of the P-Asserted Identity field. To overcome this, within the ITSP SIP Profile, we set the following:

  • Calling Info Source: FROM header

Calls fail from Lync to Cisco Call Manager via SBC

Good afternoon everyone!

I have recently been involved in a Lync Enterprise Voice Telephony pilot, coexisting with Cisco Call Manager (CUCM) during the pilot phase.

So to help give a better understanding of the issue, the below diagram summaries the setup.

CiscoSBCLync

 

 

I liked to provide as much info as possible, if you need a quick fix, scroll down to the resolution section 🙂

Continue reading