Our definition of VOIP peering is:
Exchanging traffic FROM one company's subscriber base TO our subscriber base
and the reverse VIA a Voice over IP protocol (i.e. SIP) rather than the
traditional SS7 and TDM circuits or TDM circuits with PRI, DTMF, or MF
signaling.
Perhaps a better term would be "IP Based Interconnection" for the more
telco-minded people out there rather than the ISP-centric.
-Vin
----- Original Message -----
From: "John Todd" <jtodd@loligo.com>
To: <voip-peering@psg.com>
Sent: Monday, May 17, 2004 2:07 PM
Subject: VoIP peering: contradiction in terms
[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