BT Business SIP Trunk and Asterisk PBX – Part II – The experiments with Asterisk and native SIP

Implementing BT SIP Trunk with Asterisk open-source PBX

Part II – The experiments with native SIP

This second article describes my technical experiments with native SIP and the BT SIP Trunk product.

What BT deliver

Recall that BT delivered a username and password.

The username was an 0560 “technology” telephone number, e.g. 05603510001 (made up to protect the innocent). The password was a random string of jibberish – and a pretty “strong” password by all accounts.

There is no “how to” documentation as BT expect their engineers or one of their delivery partners to come in at this point and configure up your Avaya, Cisco, Panasonic, Samsung or similar “out of the box” telephony experience and for it all to work.

But I wanted to use Asterisk PBX, a non-supported, open-source platform.

Experiments in time and space (attempting to use native Asterisk PBX)

I already had a hunch that BT were screening the devices that connect to their server(s) before I even found the “secret document” mentioned previously, so before flinging Asterisk at the BT SIP trunk with gay abandon, I thought I would do some experiments…

I set up a system with the SIP “User-Agent” string set to “My Little Pony” (a well known SIP PBX – not!) and traced the SIP REGISTER to find that BT SIP Trunk server returned a “403 Forbidden” response.

Okay, I thought, what if I set the “User-Agent” string to an Avaya-like string, for example “IP Office 9.0.4.0 build 965” – oh, now I get a “404 Not Found” instead… interesting – this confirms our suspicions as we’re no longer forbidden, but not recognised.

Okay, the “404 Not Found” means that they don’t know who we are… I was using the 0560 number in the form presented to me by BT.  My testing had revealed that the peer I am talking to was a BroadWorks SIP platform by BroadSoft Inc.  and some more googling found that in other countries (eg. Netherlands) users have to present the username in the SIP REGISTER in E164 format, eg. 445603510001.

So, change the username to 445603510001, now I get a “401 Unauthorized” response… getting closer… but there was no way I could get the Asterisk box to register on the service – much later I found out why!

 

I spent a week of evening experimenting with Asterisk and the BT SIP Trunk and couldn’t get it to register

A alternative strategy – use a Session Border Controller

I decided that even if I could figure out a way to get a native Asterisk box to register with BT SIP Trunk

  1. how well would it work
  2. how long would it remain working
  3. what of BT decided to block it?

I reasoned that if BT can provide a SIP Gateway, i.e. a device that is SIP on the BT facing side and ISDN30e for a legacy PBX then it ought to be possible to use a SIP proxy or Session Border Controller.

Further investigation revealed that BT SIP Trunks support Cisco Unified Call Manager (CUCM) with or without a Session Border Controller – Cisco call this Cisco Unified Border Element (CUBE). Further more BT were also supporting Call Manager Express (CME) – the light weight PBX that runs in a Cisco Integrated Services Router (ISR).

Now a Cisco router acting as a Session Border Controller (CUBE) and a Cisco router acting as Call Manager Express (CME) use the same firmware configured differently.  If both of these are supported then surely I can use a Cisco router as a proxy/SBC for an Asterisk PBX?

… and of course the answer is Yes!

Rationale

If BT are happy to accept Cisco signalling from an SBC (CUBE) with Cisco Unified Call Manager (CUCM) behind it or from a CME with a range of phones behind it, then why wouldn’t BT accept an SBC (CUBE) with an Asterisk PBX behind it?

The rationale here is that as long as BT SIP Trunk service is happy with the “front end” signalling that they see then the actual origin of the call signalling can lay deeper in the enterprise and is of no business of BT’s – this is just the same as with their gateway and ISDN30e PRI emulation.

So, this is what I set about building…  read Part III of this article.