The War over DNS and VoIP

Many people don't like using DNS to route VoIP traffic. I suspect other distributed applications have similar questions. They've had too many problems with DNS being reliable, or too slow for real-time call processing. In addition, many VoIP carriers use private IP addresses for their servers! This breaks Internet Engineering principles, and severely complicates name-to-address lookup services.

So instead of using DNS, they usually go with one of these options:

(a) Don't use DNS at all; instead, just do everything with IP addresses. The upside is that there aren't and DNS or directory lookups. The downsides are that they lose a level of indirection, which makes the system less flexible for reconfiguration. They also lose the mnemonic that makes the system manageable; traffic is now going to "4.2.2.2" instead of "ns1.level3.net"

(b) Use /etc/hosts-type name lookups; i.e., they have an OS-level or application-level lookup service that maps names to IP addresses. The problem here is most name-to-IP-address lookups only support the equivalent of a single DNS A record. They can't do sophisticated records, like MX records, or SRV records.

Today, I learned that some folks are using a third option in a leading VoIP Carrier Softswitch system with a Quebecoise accent:

(c) "namedefs", a fake DNS zone file integrated into the application itself. This "namedefs" file vaguely resembles the DNS zonefile, but doesn't include an SOA (Start of Authority) section. It supports more complex lookups, like SRV, but doesn't seem to support MX, and has an extremely restricted syntax. The application consults this file before accessing the

The "namedefs" is a new idea. It gives the application the power of certain fancier lookups, but it can contradict DNS or /etc/hosts lookups. It's only used by the VoIP Softswitch application, so it's possible that the application will use these lookups, while another component will use DNS or /etc/hosts to do related lookups.

Why duplicate the functionality of DNS? Network Politics, probably. The DNS servers are usually operated by the ISP / Data group, and the VoIP softswitch is operated by the Switch Engineering and Translations groups. Fred Brooks predicted this in his book, "The Mythical Man Month: Essays on Software Engineering", first published in 1975. The organization of Software Systems will match that of the Business Organization that created them.

Modern VoIP Networks are large software systems and fit this model neatly. The sad thing is that DNS already provides a mechanism for this organizational boundary: DNS zones and delegation.

I haven't had time to analyze this new approach in depth. But my hunch is that it's not a good step. Rather than bypassing or avoiding DNS, Engineers should have the courage to make DNS work properly --

1. Setup dedicated, redundant DNS servers for important applications.

2. Use DNS zone delegation to give complete control over important applications.

3. Avoid breaking Internet Engineering rules: VoIP servers should have public IP addresses, and be integrated into the global DNS hierarchy, even if they're protected by firewalls.

4. Learn how to manage zone files safely.

Black-Box Testing Fring for SIP and SkypeOut

"Fring" is a Instant Messaging and VoIP client for the iPod and iPhone Touch. It's a free download, and I decided to try it.

Fring Setup

When you start Fring, you have to register for a Fring User ID -- before you even enter your IM, SIP, or Skype contact info. That suggested to me that it was doing this stuff through a central server.

I setup my MSN, AOL, and Yahoo IM contacts and sent a few IMs. It sets your IM status to "Mobile with Fring".

Configuring VoIP

Then I setup my Skype account. I bought some SkypeOut credit. But I was never able to get it to place a call outbound. I deleted my Skype login on Fring, then tried to set it up again -- but it wouldn't let me login.

I also configured a SIP account with a VoIP carrier, Vwave.net, an NGTelecom Company. NGTelecom is a sister company; they're a very modern SIP VoIP provider: they have an Acme Packet SBC and DNS SRV records. I entered my SIP username, SIP authentication password, and the Vwave domain, "vwave.net".

The Fring system did a proper DNS SRV lookup, then registered through the NGTelecom Acme Packet SBC. I noticed that it registered from 63.215.199.71, an IP address assigned to CWIE, LLC of Tempe, AZ.

The CWIE IP Address did not stay registered after I left the Fring application on my iPod Touch. In fact, when I restarted Fring, it wasn't always able to re-register; the progress spinner would keep on spinning.

Call Quality Problems

While Fring was registered, I placed several (maybe 6) calls. Two (2) of them carried intelligible speech. In a couple of cases, I heard weird feedback, on my iPod Touch, before the call was even connected. But I don't know of any similar examples from The Cisco "Duck Quack" page of Voice Quality Symptoms. In some of the call cases, I had one way audio. (Vwave's Acme Packet SBC generally solves all NAT problems for moderately-well-behaved SIP clients, but symmetric RTP is required if the RTP flows through a NAT device or stateful firewall.)


Comments and Conclusions

I was hoping for a SIP client that actually runs on the iPod Touch. Fring apparently sends the call across the Internet, so that means your SIP proxy has to be reachable from the Internet.