SIP interconnection: what a new carrier partner needs to prepare

Every wholesale voice partnership starts with the same practical question: how will our two networks actually exchange calls? The commercial conversation tends to get the attention, but it is the interconnection work that decides whether traffic flows on the day you expect it to. In our experience most delays have nothing to do with price. They come from details that neither side wrote down early enough, and that surface during testing when a launch date is already close. The good news is that the list of things to agree is short, and none of it is exotic.

What an interconnection really is

Modern voice interconnection is SIP-based. Your platform and ours agree on where to send signalling, where to send media, and how to recognise each other as legitimate. Conceptually that is the whole of it. In practice it means a handful of decisions that both sides need to make explicitly rather than assume, because the default behaviour of two platforms is rarely the same. Writing them down takes an afternoon; discovering them during a cutover takes a week.

• →Signalling endpoints — the addresses each side will send SIP to, and the ports expected in both directions.
• →Media handling — whether audio flows directly between the endpoints or through an intermediate element, which changes what has to be opened on your firewalls.
• →Authentication — carrier interconnections usually identify the far end by its address rather than by credentials, which makes the list of declared addresses a security boundary in its own right.
• →Codecs — which encodings each side offers, in what order of preference, and what should happen when the two lists do not overlap.
• →Capacity — the number of simultaneous calls the interconnection is dimensioned for, and the agreed behaviour once that ceiling is reached.

Number formats deserve their own conversation

The most common source of failed calls at the start of a partnership is not routing. It is disagreement about how numbers are written. One side sends numbers in full international format, the other expects a national format, or a prefix is added or stripped somewhere in between. The call is technically delivered and technically rejected, and both sides can produce logs showing they did the right thing. Agree the format for called and calling numbers before the first test, in writing, with worked examples. Include what should happen to a number that does not match the agreed shape: rejected, normalised, or passed through untouched. That single paragraph in an interconnection document prevents more incidents than any amount of monitoring added afterwards, because it removes the ambiguity rather than detecting its consequences.

Test, then move traffic gradually

Testing is not a formality to be compressed when a schedule slips. A useful test plan covers a successful call in each direction, a call to an unreachable number, a call the far end rejects, and a call that is answered and then released from each side in turn. What you are checking is not only that audio works, but that both platforms agree on how a call ends and on what each release reason means. Those release reasons become your shared vocabulary for every incident that follows, so it is worth spending time on them while nothing is urgent.

Once test calls behave as expected, traffic moves gradually rather than all at once. A partial cutover gives both sides real data — quality figures, release causes, capacity behaviour — while the volume is still small enough to reason about. If something is wrong with the routing, this is when it becomes visible, and correcting it then is far cheaper than after a full migration. If you are preparing an interconnection with us, the fastest way to start is to send your destination list, your expected traffic profile and the name of your technical contact. The rest of the conversation follows naturally from those three things.