Re: VoIP peering: contradiction in terms

["Vincent J. Bono" <vbono@vinny.org>]

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
>
>
> --
> 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/>.
>


--
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/>.