We’ve worked with a few clients recently who needed to migrate to a new trunk group for their tandem traffic.
Sometimes this is driven by the tandem provider – perhaps they’re simply updating their transport infrastructure and need you to use a new set of trunks, but nothing is really changing except the transport.
In other cases this is driven by a desire to move to SIP. Inteliquent and Peerless Network both offer services that potentially allow you to switch to SIP trunking for tandem access (depending on your location).
Whatever the reason, if you’re in this situation you may be wondering how to migrate to your new trunk group smoothly – and in this article we’ll describe the key steps in the process so you know what to expect.

Ordering the trunks
Just kidding. I’m not going to write about this piece, as we don’t get involved in carrier orders – so I’m totally ignorant on how this all works.
Let’s assume that you’ll need to fill out some kind of paperwork with your new tandem provider and that you’ve successfully done this.
Building the trunks
Before we can do anything else we need to get the two switches talking to each other.
For ISUP trunking this will involve turning up TDM circuits, building new ISUP and SS7 configuration reflecting the point-codes and TCICs of the new trunk group, and running various standard tests to validate that everything is configured correctly.
For SIP trunks you’ll need to configure the IP addresses and ports, update your Session Border Controller to route the messages, and specify the codecs and interop settings to use for this SIP trunk.
This phase often involves some troubleshooting to resolve various configuration issues, but when all is said and done, you’ll have a trunk group between your switch and the tandem and the two switches can exchange signaling messages.
Translations for test calls
Before you can test the trunks with any actual calls you’ll need to build some translations – to route outbound calls over this new trunk group and (possibly) to make sure that inbound calls arrive at your test line.
The key here is to configure your switch to use this set of translations only for your test calls, so you don’t impact any live traffic yet.
Test calls
Once the translations are ready, you’ll want to make a few inbound and outbound test calls to verify that the translations, routing and interoperability between the switches is all working well.
And when these calls inevitably fail, you’ll need to troubleshoot the issue and fix it.
Translations for production traffic
Next up you’ll need to integrate your new logic into your production translations – and typically you’ll want to build your new trunks with the existing trunk group as an overflow, so calls can use whichever trunk group is currently active.
This helps because you don’t have to update your translations at exactly the same moment that your tandem provider activates the new trunk group.
Cut date
Ideally, you’ll be able to start using the new trunk group at your convenience – in which case the “cut date” for outbound calls is whenever you activate your new translations.
If you’re using the same tandem provider as before (just new trunks) then they will be able to control when inbound calls start using the new trunk group.
However, if you’re switching to a new tandem provider then there will be a date published in the LERG when your inbound traffic starts being routed to your new tandem provider, and hence arrives on your new trunk group. So you need to make sure you’re ready – you’ve done all the testing and preparation in plenty of time so you can accept calls on the official cut date.
Turn down the old trunks
After a successful cut, we’d recommend leaving the old trunk group in place for a couple of weeks, just in case something goes wrong (and you need to roll-back).
Once you’re happy that the cut was successful don’t forget to remove the old trunks from your switch AND remove them from your translations to keep things clean.
What if we need help?
Most service providers spend their lives working on subscriber equipment and subscriber configuration – and no-one ever needs to mess with the PSTN trunking or the switch translations.
So don’t worry if this seems daunting. That’s entirely normal.
As Metaswitch consultants, we spend most of our time working on those projects that other people find uncomfortable.
No-one hires us to help do the easy tasks that they do every day. We get hired to help with the unusual projects – the situations that only come up once a year, or once every 5 years. So for us, these kind of updates are routine.
If you’re preparing for to migrate to a new trunk group (for tandem traffic – or long distance traffic for that matter), simply fill out our contact form. Just let us know how many trunks you’re moving, and how many switches are involved, and we can quickly get you a quote for some assistance.