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:

 

 

 

 

Remote Authorisation:

 

 

 

 

 

 

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:

 

 

 

 

 

 

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.

 

 

 

 

 

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:

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