Sip Trunking 101 – The What and How of SIP Trunking

! This post hasn't been updated in over 2 years.

This blog post is an introduction to SIP Trunking and it will hopefully cover most of the questions that a person/company has when starting their SIP Trunking journey.

We have started seeing an increase in SIP Trunking interest and implementations. I think this interest has increased recently as SIP Trunking now has the reputation of being a stable, mainstream technology and no longer an experiment. SIP Trunking also has the potential to provide huge cost savings. I have been visiting Enterprise Connect for the last 6 years and SIP Trunking has always been a huge topic. For about the first 4 years, it was about how we needed to get customers to pilot it. For the last couple of years, it is now a mainstream solution and it is about how the customer needs to fully leverage the benefits of SIP Trunking. A pilot is still recommended, but there is no need for a lengthy process – just run through a quick test plan and make sure that unsupported functions are working as expected, For example, In the UK, Gamma SIP Trunks are certified to work with a ShoreTel phone system so very little testing is required in the same way that you wouldn’t need to test a ShoreTel phone system to work with a BT ISDN line. Therefore, testing would be for things like modems, fax and franking machines.

SIP Trunking – What?

Before I answer that, I will first explain what SIP is. SIP stands for Session Initiation Protocol. Wikipedia says:

“The protocol defines the messages that are sent between endpoints, which govern establishment, termination and other essential elements of a call. SIP can be used for creating, modifying and terminating sessions consisting of one or several media streams. SIP can be used for two-party (unicast) or multiparty (multicast) sessions”

SIP is not just used for VoIP calls. There is a wide range of applications for SIP, for example, video calls, instant messaging, security cameras etc. As Wikipedia states, it is used for “creating, modifying and terminating sessions” It is not used for the media streams itself. For voice calls, RTP (Teal Time Protocol) is used to transmit the voice traffic. I could go on talking about SIP, how it was developed, the steps required to set p a session etc., however, this YouTube clip does a very good job of it, so I’ll let this man explain:

So now you know what SIP is, lets talk about SIP Trunking. SIP Trunking is a logical SIP connection between nodes. It can run over dedicated or your existing infrastructure. There are two main types of SIP Trunking:

  • Connect applications/servers together
  • Provide PSTN connectivity

SIP Trunks can be used to connect applications together, for example, a conference server to your phone system, a voicemail server to your phone system or to connect two phone systems together. These are known as SIP Trunks but they are just logical connections between your own servers and do not require a SIP Trunking service provider, therefore we will not explore these types of SIP Trunking in this blog entry but an example of this type of SIP Trunking can be seen in my blog post ‘ShoreTel Mobility with VCX’ where I explain the steps of linking a ShoreTel Mobility Router with a VCX phone system.

The other type of SIP Trunking is to provide you with PSTN connectivity over an IP network instead of across traditional phone lines. This is done using an Internet Telephony Service Provide (ITSP) and many ITSP are also traditional PSTN providers – this is the type of SIP Trunking that we are going to cover in this blog post.

As mention above, SIP Trunks are logical connections between you and the ITSP. In the terms of phone calls, Sessions are the number of concurrent calls you are allowed through the SIP Trunk. The number of sessions are normally dependant on how you pay the ITSP and your SIP Trunk connection bandwidth. So if you were to replace an E1 ISDN line with 30 channels, like for like with a SIP Trunk, you would have a single SIP Trunk with 30 Sessions. The nice things with sessions on a sip trunk, unlike channels on a ISDN, you can easily and quickly increase or decrease the number, depending on demand, saving costs.

SIP Trunking – How?

Developing a SIP Trunking design for an enterprise offers interesting architectural options. Three of the major decisions that need to be made are:

  • Trunking architecture
  • Connectivity options
  • To SBC or not to SBC

Trunking architecture

The trunking architecture could be as simple as replacing all your current PSTN connections with SIP Trunks in their current location. Or you can grouping trunks and leveraging your WAN to reduce the number of needed Trunks and SIP sessions (channels in PSTN talk). The 3 SIP Trunking architectural designs are:

  • Centralised
  • Distributed
  • Hybrid


Centralised Sip Trunking with Dedicated connection

All SIP trunks run into one or more existing data centres. This option optimises to the minimum number of trunks and the least trunk network capacity but is highly dependent on WAN capacity. Twin centralised trunk links would provide failover.


distributed Sip Trunking with Dedicated connection


SIP trunks run directly into each significant branch location. This is not so common but there may be good reasons to use it. Remote locations may not have good WAN capacity. Distributed works better if local resilience is needed. It also allows internal chargeback for different divisions, countries and taxation. It requires some form of resilient branch switch at each location.


Hybrid Sip Trunking  with Dedicated connection

Some combination of the above two architectures, with centralised pipes to the data centre(s) and additional distributed lines as required, e.g. for international sites or for important remote locations such as call centres.

Don’t spend too long worrying about the effect that the current location of your PBXs will have on the long term architecture. Consider instead the architecture of the rest of your IT. The widespread availability of virtualisation for IP-PBXs and the option of integrating SIP with line-of-business applications means that the locations of your main servers are more relevant.

Connectivity options

There are 3 main ways to implement SIP Trunking at your enterprise, these are:

  • Dedicated
  • Shared with Dedicated QoS
  • Over the top (OTT)


Dedicated SIP Trunking connectivity is where the ITSP will provide you with a data line directly to your premises to be used exclusively for SIP Trunking. The data line could be ADSL, FTTC, T1 etc. This provides you with very similar architecture to an ISDN Line (albeit much cheaper).

Shared with Dedicated QoS

If your ITSP can also provide you with data connectivity, there are cost savings to be made for only having one line coming into the building. This line may be your dedicated internet line or your WAN connection. The diagram below show a typical installation using centralised architecture with a shared line and dedicated QoS connection over their WAN connection. This particular example has no redundancy. Therefore, dedicated lines or shared internet lines with a dedicated QoS connection is an option at important locations.

Centralised Sip Trunking with shared WAN and Internet connection.

Over the Top (OTT)

‘Over the Top’ means deploying SIP Trunks over the top of your existing internet connection to an ITSP. This is typically not seen as a great enterprise solution as you have no control over the quality. You can apply the QoS setting at your end, but once your RTP hits the internet, QoS doesn’t exist! OTT though does have a place, for example, it is useful for redundancy, connecting to the consumer market (Skype) and it provides you with ridiculously cheap international calls (although probably not wise to use for international customer calls.)

Trunk Redundancy & Business Continuity

With the knowledge of the different architecture models and the connectivity options you have, it is time to consider planning for SIP Trunk redundancy and business continuity. Beyond your premises, the SIP architecture of each carrier should have redundancy in their network, perhaps built around the main internet entry pipes in each country. You may wish to connect to different parts of their network to exploit this.

If you choose multiple vendors then you will be building in further resilience. In many cases, these vendors may share the same country network so try to use different locations for each so that one excavator doesn’t take out both links.

If you choose twin access methods –Over The Top (OTT) plus Dedicated –then you may or may not have as much extra resilience as you might think depending on the extent to which you feel that your high quality Dedicated calls can be rerouted over a lower quality OTT line in the event of failure.

If you operate contact centres then they may merit their own connections and enhanced failover options.

Remember that an IP-PBX can be configured to fail over outbound calls between trunks regardless of whether they are SIP or PSTN. However, with the exception of the manual diversion of specific numbers, the automatic failover of lines or of groups of DDIs for inbound calls can usually only occur between links owned by the same provider.

Don’t forget the Disaster Recovery site. It is relatively easy to divert DDIs over SIP trunks to such a site but you will need to provision the network capacity in advance.

International considerations of availability, price and failover mean that you may need a different carrier in each country where you operate.

To SBC or not to SBC?

Do you need a Session Border Controller (SBC)? The short answer is yes! There are many good reasons to have an SBC, two of the main ones are security and interoperability. Depending on your equipment and SIP Trunk connectivity method, it may be impossible to do SIP trunking without one. There is not a good reason not to have one. Depending on the deployment it can add some complexity and add a little cost, but in the great scheme of the project, it is a very small percentage.

The SBC sits on the border of your network and the public/ITPS network. We use Ingate as our SBC of choice. The interface is not the prettiest, but it has been certified with all the equipment we use on a day-to-day basis and it does the job. More about the ins and outs of SBC can been found in the next post. As this is a 101 introduction to SIP Trunking, the above should be enough of an explanation to talk about the connectivity options of the SBC. They are:

  • Stand-Alone
  • DMZ


SIP Trunking SBC - Stand-a-lone

This method is used instead of or parallel to the firewall. This method suits dedicated connected SIP Trunks or Shared when you do not have access to administration to the firewall.


SIP Trunking SBC - DMZ/LAN set-up

This method gives you the added security of your firewall but the ease of connecting it direct to the Voice network. Typically secure enough for the typical deployment, but there is a more secure option offered in the full DMZ deployment below.


SIP Trunking SBC - DMZ up

This method gives you the most security as all traffic from the ITSP and from the voice network both have to go via the firewall. Not surprisingly this is the most complex to set-up.

Neither DMZ method is really suitable for dedicated lines as they require a firewall. Of course there are exceptions, if the existing firewall has capacity for a second external connection, and you have full administrative rights to the firewall, then there may not be much to lose by doing it.


That’s about it for this post! We have covered the architectural options, the connectivity options and the SBC options for SIP Trunking with an ITSP. If you have any questions, please feel free to use the comments below.

About the author

Peter Doyle I will pretty much do anything UC! My Google+ Page My Linkedin Page


2 pings

Skip to comment form

    • Andy on January 30, 2015 at 11:42 am

    The biggest problem we’ve had with SIP is carriers not supporting sending DTMF tones over all the trunks they use within their network, and one who doesn’t support Caller ID on international calls!

    The DTMF issues we’ve had are mind boggling, how carriers can think it’s acceptable for them to not work is beyond me.

    1. Hi Andy.

      DTMF on SIP can be very problematic. It can be delivered to you as either Out-of-band or in-band.

      Out-of-band is when the carrier listens out for the DTMF tone and sends a SIP-INFO or RTP message when it receives one. Inband is when the DTMF tone is passed in the RTP stream and the PBX is expected to listen.

      It is strange that the service provider will just not support it at all! Have you ask your carrier about both types of delivery methods? Can I ask what carrier are you using?

      Are you using an Ingate? Have you tried doing this:
      • SIP Services–> Interoperability
      • Under B2BUS receive PRACK and B2BUS send PRACK set the options to ‘No’

      This is a know fix for DTMF issues on ShoreTel/Ingate SIP Trunking implantation

        • Andy on January 30, 2015 at 12:50 pm

        Happy to name and shame in the hopes it’ll make them buck up their ideas. It’s definitely an issue within the carrier (they’ve admitted such) tho I will check that setting.

        In the UK we’ve had issues with EasyNet (who were MDNX, who were Viatel) who have been able to route different destination number via different onward carriers/trunks when we’ve given them numbers for webex etc, but the issue ususally returns and new numbers are found weekly. And we only learn of the number after a user complains, so there has already been an issue.

        We have the same issue intermittently in the US with Windstream but haven’t gotten to the bottom of it with their support yet.

        In Australia Optus doesn’t support correct inbound Caller ID on international calls, instead they send random digits! The response we got from their support to extensive debugs is that it’s just not supported and they closed the issue!

        We’ll be reviewing SIP providers in the UK and looking for one who will guarantee DTMF function, if any such provider exists.

        1. This is going to sound a bit like a sales pitch, but it’s not!

          For the UK, we use Gamma as our SIP Trunking provider and for our customers (we are that impressed with them we now work with Gamma). we have had zero issues with DTMF and Gamma, It has just been out of the box configuration. In fact the only issue we have had so far is interoperability with a Fax to email server.

          Also Ingate and ShoreTel are both certified to work with Gamma.

    • John Taylor on January 30, 2015 at 11:48 am

    Some people regard a single trunk as a channel, others as a line with multiple channels. Both versions seem widespread.

  1. […] For information about methods of deploying an Session Border Controller and SIP Trunking, check out my post on SIP Trunking […]

  2. […] For more information, check out this previous blog post. […]

Comments have been disabled.

%d bloggers like this: