[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: VoIP peering: contradiction in terms
We do indeed offer the equivalnet of "Transit" in the voice world, but thats
not what I was getting at.
----- Original Message -----
From: "John Todd" <jtodd@loligo.com>
To: "Vincent J. Bono" <vbono@vinny.org>; <voip-peering@psg.com>
Sent: Monday, May 17, 2004 3:30 PM
Subject: Re: VoIP peering: contradiction in terms
>
> Why would you limit yourself to just the subscriber base? Why not
> use the analogy of "transit" when talking about VoIP routes? Manny
> VoIP providers also require "VoIP transit" (i.e.: settlement-based
> traffic exchange) in addition to wanting their customer base exposed
> to other carriers in a settlement-free (or very low-cost) manner.
>
> I understand why you'd make the distinction, but I think as an
> "industry" we're missing the capital-P Peering, which is the
> functional exchange of any routes between carrier, so I'd say it's a
> bit premature to have semantics of that specificity. After a good
> protocol is devised for route exchange, we can talk about "peering"
> which is the exchange of only those routes which are subscribers that
> have a (financial, technical, political) reason to be announced by
> one provider to another. Not that much different than IP transit, as
> far as I can tell, other than the nightmare of settlement.
>
> JT
>
>
>
> At 2:30 PM -0400 5/17/04, Vincent J. Bono wrote:
> >
> >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/>.