• Skip to content
  • Skip to primary sidebar

Award Consulting

Metaswitch consultants

  • Home
  • About
  • Services
  • Questions
  • Training
  • Articles
  • Podcast
  • Contact

Taming Flippant Fluctuations in your VoIP Network

February 8, 2023 By Andrew

There’s no chatty preamble today, because I’ve got a puzzle for you. Are you ready?

Let’s suppose that you want to build a nice redundant VoIP network, and so you deploy two Session Border Controllers in geo-diverse locations, along with a single Metaswitch CFS. These two SBCs have IP addresses 1.1.1.1 and 2.2.2.2 (because you got very lucky when the IP Gods assigned IP addresses). You create DNS records for your domain name, and point that domain name at both SBCs for redundancy:

sip.mytelco.com.  IN  A  1.1.1.1
sip.mytelco.com.  IN  A  2.2.2.2

You then configure all your SIP endpoints to register with sip.mytelco.com.

This all sounds very sensible, but unfortunately you’ve made a big mistake. What is it?

…

…

…

Flippin’ registrations

Here’s the problem – you’ve configured the two DNS entries with equal weight. This doesn’t seems like it should be an issue, but actually when you get into the details of the SIP flows it becomes a problem very quickly.

Here’s why.

  • Bob’s phone does a DNS query for sip.mytelco.com and gets back 1.1.1.1.
  • Bob sends a SIP REGISTER to 1.1.1.1.
  • The SBC (acting as a back-to-back UA, as is typical), sends an internal registration from its core IP address (call it 10.10.10.10) to the CFS.
  • The CFS confirms the registration and notes that Bob can be contacted via 10.10.10.10.
  • Some time passes, and Bob decides to make a phone call.
  • Bob’s phone does another DNS query for sip.mytelco.com and this time gets 2.2.2.2.
  • Bob sends a SIP INVITE to 2.2.2.2 in an attempt to set up a call to Alice
  • The SBC (again, acting as a B2B UA) sends an internal INVITE from its core IP (call it 10.10.10.20) to the CFS.
  • The CFS looks at the INVITE, and rejects it, because there’s no registration associated with Bob at the 10.10.10.20 address.

That’s complicated I know, so let’s make a terrible analogy, in case that helps. Imagine Bob is an 8 year-old flying on a plane all by himself to go visit his Grandma Alice.

It’s as if Alice is waiting at the airport to meet her Bob, and Bob told her he was going to be arriving at Terminal 1 on Southwest (that’s the registration), but then Southwest had a massive system failure and cancelled all their flights (implausible, I know), so instead Bob gets re-routed via Delta and arrives at Terminal 2 (the INVITE). But because Alice isn’t expecting Bob to arrive at Terminal 2 she’s not there to meet him. And because he’s a little boy with no-one to meet him, the airline rejects his arrival and sends him all the way back to where he started with a 404 Not Found sticker on his shirt.

Image created by DALL-E 2

How do I avoid this?

I should first note that this problem can only impact you if you have two separate SBCs. If you have a single Perimeta SBC with two blades (but they act together as a redundant pair) then this is not an issue because they share both public and core-side IP addresses.

However, if you genuinely do have two SBCs, then the best way to handle this is to assign a weight in your DNS configuration (so you have a designated primary and secondary).

You can’t do this using A records, so you have to get more advanced and explore DNS NAPTR and DNS SRV records which give you more control, and allow weighting and the ability to assign different DNS mappings for different services. For example, something like this might be used:

sip.mytelco.com.  IN  NAPTR  10  100  "s"  "SIP+D2U"  ""  _sip._udp.sip.mytelco.com.
sip.mytelco.com.  IN  NAPTR  20  100  "s"  "SIP+D2U"  ""  _sip._udp.sip.mytelco.com.

_sip._udp.sip.mytelco.com.  IN  SRV  10  5060  1.1.1.1
_sip._udp.sip.mytelco.com.  IN  SRV  20  5060  2.2.2.2

If you want to get really fancy, you could have different priorities given to SIP clients based on their location – learn more about GeoDNS here.

I hope you enjoyed the puzzle. I’m continuing to play with ChatGPT, and asked it to write you a short verse to conclude this message.

May your flights take off on time,
Never delayed, never denied.
May your networks run smoothly, fast,
With no issues to disturb your rest.

About Andrew

Award Consulting is focused on helping ILECs and CLECs who use Metaswitch products to thrive as they improve their networks through migrations, strategic projects and improved service offerings.

Our goal is to create highly specific, highly valuable content targeted specifically at US regional service providers, and especially those who are running Metaswitch equipment. Join our email list to be notified of new content.

Reader Interactions

Primary Sidebar

Our goal is to create highly specific, highly valuable content targeted specifically at US regional service providers, and especially those who are running Metaswitch equipment. Join our email list to be notified of new content.



Articles by Theme

  • Hosted PBX (16)
  • Interviews (1)
  • IP Networks (7)
  • Network Evolution (22)
  • Network Ops (50)
  • Product (17)
  • STIR-SHAKEN (22)
  • Strategy (17)
  • Technical (28)

Copyright © Award Consulting Services 2023