VoIP peering: contradiction in terms

[John Todd <jtodd@loligo.com>]

[This post is not in specific reply to any previous comments on the 
list - it's been sitting on my screen for a day or two, and I'm 
finally hitting the "send" key]


So, at the moment, I am wondering what exactly "VoIP Peering" means. 
I have the following vague ideas that I hear various firms and 
pundits throwing out in various industry rags and blogs:

 - "It's a layer 2 thing, where a bunch of VoIP providers all connect
     to the same ethernet switch and set up BGP sessions."

 - "It's all about using ENUM.  Don't ask question on how, exactly,
     we use ENUM.  ENUM is a routing protocol, right? You can peer
     with ENUM, right?"

 - "It's about SS7 over IP.  Please, step into this room where the
     technician will fit your skull with this bell-shaped helmet..."

 - "It's about QoS."

From the very clueful, I get these comments:

 - "It's about models like OSP that allow settlement between providers
     in some standardized way."

 - "VoIP Peering is the sound of one hand clapping."


Well, here's my definition of VoIP peering - it's open for revision:

  "The ability for two administrative entities to directly or 
indirectly interconnect with each other via TCP/IP, and then for 
those entities to exchange in an automated and dynamic manner the 
e.164 address ranges that each believes the other should know, 
including metrics such as monetary cost, gateway information, 
protocols, and other relevant details which relate to the passing of 
voice, video, or other media over the underlaying IP network."

You'll note that this definition misses some important points are not 
covered (which are 100% in the spirit of this group, but perhaps 
outside of the definition of "peering"):

What is not covered in that statement:
   - the settlement of costs that may be incurred in the use of any 
of these routes
   - the actual transport protocol of those media streams, or the 
details of those media streams
   - the IP network or criteria for the IP network that moves bits 
between any two points
   - the "signalling" protocol that is used for transporting those 
e.164 prefixes
   - the ability to filter/modify e.164 ranges or associated criteria 
on an "in" or "out" basis from a particular entity's perspective

So, in essence, I say that VoIP Peering doesn't exist right now. 
It's hot air and sales.

"Wow, that's a bold statement." you might say.  I am willing to be 
proven wrong, because it would allow me to leave my office before 
dark a few more days a week.  I spend hours (and hours, and hours) 
each week taking dozen of spreadsheets from various telephony 
carriers, and digesting them through a huge set of scripts and manual 
convolutions that turns their rates into something I can work with in 
a single sheet of a spreadsheet. Then, when I'm done with that step, 
I digest them further and weed out the carriers whose routes are so 
bad that I don't want to use them no matter what the price.  Then, I 
figure out what the effective dates of these routes are.  Then, I 
figure out what hosts I should point each route to, and what protocol 
I should use.  Then, finally, I insert these various data into my 
routing engine so that my customers can get their calls handled in 
the appropriate way.  Now that I've completed this work, I turn right 
around and generate a spreadsheet that I give to _my_ customers, 
almost certainly throwing them into the same nightmare that I just 
came out of.  (Note: I actually have a web interface in both 
directions - in and out - but good luck getting someone at a telco to 
use it.)  Now, I do this every time we have a price update.  Well, 
the solution is (of course!) to not update prices very often.  That's 
always a good strategy to keep up with my competition and keep 
pressure on my vendors, right?  Right?

If someone can point me to the magic routing protocol that solves all 
these problems, I'm willing to  say that I've been wasting my time 
for the past few years.  But I don't think that magic bullet 
exists... yet.  (TRIP, anyone?)

Those who say that it's a Layer 2 issue, or a Layer 3 issue - they're 
probably well-meaning, but ultimately have not thought the issue 
through nor have they actually tried to configure routing for 
telephony with their own two hands.  Yes, there is a Layer 2 and 
Layer 3 component, but that's not the "Vo" part - that's the "IP" 
part.  I _know_ how the IP part works - there's no secret there. 
Private interconnections, BGP, QoS, MPLS blah blah blah - Yes, I know 
how to get packets from place to place with five nines, or whatever 
zany metric you want to come up with.  What I'm missing is the 
telephony part.  What traffic to what end telephony stations am I 
sending over this low-latency, high-bandwidth, super-reliable link? 
If that can't be answered, then we're not really doing VoIP Peering, 
are we?  We're just doing typical IP route peering, so don't call it 
VoIP Peering.

ENUM is not the answer for non-specific routing, in my opinion.  If 
you can tell me how you do fast, cost-based ENUM lookups that allow 
for my two dozen carriers or my two hundred carriers who all offer me 
the same e.164 prefix (i.e.: +1-650-xxx-xxxx), I'm willing to 
withdraw my comments.  Otherwise, let's talk about why DNS is not a 
routing protocol.  ENUM is great for exact answers - it is 
insufficient for PSTN prefix-based routing.  I am a big proponent of 
ENUM, but unless I hear some very different things on implementation 
schemes for ENUM, I do not think that private ENUM roots are the 
right or scaleable approach for route exchange.  I am open to 
"private" ENUM interconnections, but I'm fairly sure I want a single 
ENUM root to deal with in the long run (the slapdash overlap of 
various providers who have chosen "unoccupied" e.164 space in which 
to number their customers is an example of why multiple roots may be 
problematic.)

In response to Paul Vixie's comment about an alternate e.164 
registry, there are guys in Australia who are already starting 
something close (but not exactly) - see http://www.e164.org/  - well 
meaning, but ultimately will collapse under the weight of it's own 
success.

Of course, as should be fairly obvious, ENUM is just a kludge until 
we've got phones that dial with email-style (user@domain.tld) 
addressing.  I'm not sure that kludge will go away in any of our 
lifetimes, given the number of 12-digit keypads currently on the 
planet.

Next post: What is RFC3219 (TRIP) and why isn't everyone running it? 
What is OSP and why isn't everyone running it?  (I have the answer to 
the first question, but not the second - anyone else here know?)

JT


--
To unsubscribe send a message to voip-peering-request@psg.com with
the word 'unsubscribe' in a single line as the message text body.
An archive is at <http://psg.com/lists/voip-peering/>.