DNS Management & Reporting

•May 24, 2007 • Leave a Comment

We recently had some issues with DNS on the sipx.* domains and decided we needed a secondary DNS server to keep DNS running should the primary go down.  After a little research we signed up with Twisted as a secondary and so far all is looking good.  They offer free secondary DNS hosting for up to 10 domains, signup was painless and easy – with clear instructions on what records needed to be added and where.

After getting DNS back up and running and setting up the secondary – we used the superb DNS checker from DNS Stuff (http://www.dnsstuff.com) to verify all was as it should be.  Thankfully we did – the report picked up a number of things we’d missed – but the detailed report listed exactly what the problems were and guidance on how to fix them.

 Part of the fix involved setting up some glue records for the name-servers – and digging through the GoDaddy  management interface.  An hour later we managed to find where we could setup the glue records.

If you’re a GoDaddy user and need to do the same:

  1. Login to your GoDaddy account
  2. Select Domains
  3. Select a Domain to manage
  4. On the summary screen in the bottom left hand corner you’ll see a box: Host Summary
  5. Once you’re in the host summary page – you can add your own glue records by providing a DNS name and it’s IP address (It’s here you would specify name servers that you manage for the zone)

It’s important to add DNS glue records for domains you manage – it speeds up DNS queries and short-circuits the problem of name servers that are inside the domain they manage; ie: ns1.sipx.ws is a name server for the sipx.ws domain – without being able to plugin an IP address for the name server – DNS doesn’t know how to talk to the domain).

Technorati:

aside:Intelligent VoIP Agents

•May 21, 2007 • 1 Comment

One of the exciting aspects of the work we are doing on SipX is that it builds a framework that allows intelligent VoIP clients – Software Agents that work, on your behalf, to give you the best bang for buck.

Using the call routing framework we are developing – you phone software (behind the scenes) will decide the best way to make a call to anybody, anywhere in the world.  It won’t matter if the person you are calling is using VoIP, Mobile or the Plain Old Telephone Systems (POTS). 

If you have 2 VoIP providers – it will intelligently work out which one to use in every situation for each call.  If you opt for it – at the end of each week, month, quarter and year – you’ll get an analysis of the calls you made and what it cost you – if you could have paid less for the same service then you’ll get the information broken down in ‘Plain Text’ TM

Technorati:

Resolving contacts on other SIP Networks (Part 1)

•May 21, 2007 • 2 Comments

Yesterday in “Operator, Can I be connected with Boston 32192 please” I talked about the problems with VoIP and peering.

Many VoIP have peering arrangements with other VoIP networks (except one of the Italian VoIP providers SkyPhone) – which makes sense – all the VoIP provider is doing is routing the call across the public Internet.  The problem with calling somebody on another network – most current implementations – is that the caller has to prefix with a number defined by their VoIP Provider. 

At first glance this might not look like a big deal – however it means you generally have to dig through a FAQ and then attach the prefix to the number in your contacts.  If you switch VoIP providers (heaven forbid that users might want to change VoIP providers based on the quality of the service) then you’ll need to go through each of your contacts and update each of your contacts with a new prefix (if the new VoIP provider has a peering arrangement).

The solution we are working upon builds upon an approach used by the e164 proposal (e164 is about providing a global contact infrastructure – more info about this in an upcoming post) using DNS.

The basic principle is to use DNS as a mechanism to resolve peer prefixes and numbers.  The process we are developing follows this logical approach:

  • Joe (with a SIP address of 007@Rome.it) dials fred’s SIP address 31294@boston.com
  • Joe’s client software determines that the number is a SIP address (userID@domain.name)
  • The client does a DNS lookup (against the global lookup domain sipx.ws) with one of the following:
    • boston.com.rome.it.sipx.ws ([destinationDomain].[userDomain].[resolverDomain])
      • This would return either:
        • a DNS no-such-entry record – meaning there is no peering arrangement
        • a DNS entry with the prefix (such as **001) which the software client would then prefix the number with
    • 31294.boston.com.rome.it.sipx.ws
      • As with the previous entry it would return either a DNS no-such-entry record – or the full number to be dialed – **00131294

The advantage of using such an approach means:

  • It’s built upon a well-defined scalable infrastructure – DNS
  • It provides a clean & transparent mechanism for users and software clients to resolve and deal with peering arrangements between VoIP providers.

Technorati:

“Operator, Can I be connected with Boston 32194 please”

•May 20, 2007 • 1 Comment

One of the problems with VoIP networks – is that they are designed by geeks.

Now geeks are fine, I flush with pride every-time somebody calls me one, I have my anorak framed on the wall beside me.  But they don’t really think about usability.

For instance – sign up with a reputable VoIP provider and you’ll get some software you can use on your machine (or mobile if you use TruPhone or Fring) and you’ll be assigned a SIP address. 

Your SIP address will be something like 32194@boston.com – where 32194 is your number and Boston.com is your SIP VoIP provider.

Cool! – anybody on the Boston network can reach you just by dialing your number.

But what if somebody not using VoIP wants to reach you?  Humm – well then you need to get a “real” number from a provider (known as a DID number).  Most VoIP Providers give you a DID number – or allow you to purchase one. 

So we’re all fine and dandy now?

Well – people on the Boston VoIP network can call you direct (and for free) – and people using standard telephones can call you on your DID number.  So what’s missing?

What if somebody on a VoIP network Roma.com wants to call you?

This is where it becomes a little more complex.  If you’re lucky Roma.com and Boston.com have a peering agreement.  This means they have an agreement that if somebody on their network dials an address that is on another network – then they will recognise the attempt and direct the call to the appropriate place.  To get this to work – it requires the user to know about the peering arrangement in the first place and use a prefix.

So for a user on Boston.com to call 12345@Roma.com the user would prefix the number with **012 – and thus dial **012 12345.

Not the most intuitive solution to the problem. 

For VoIP in the mainstream it needs to be accessible to the average joe.

There are a few ways to solve the problem Distributed Universal Number Discovery (thankfully abbreviated to DUND) is one approach.  A design thought up and implemented by the Asterix team. 

Another is an approach is one that we have been working on for a short time based on DNS – following the same principle and the e164 project.

In essence it’s a mechanism that allows VoIP software providers to use a standard DNS look-up to find numbers on other networks.

The specifics of how this happens and operates will be in a subsequent post….

Technorati: