[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: VOIP Peering Questions

At 9:11 AM +0100 6/2/04, Alex Bligh wrote:
John,

--On 02 June 2004 00:00 -0700 John Todd <jtodd@loligo.com> wrote:

I actually _do_ have someone working ~30 hours a week on TRIP, though
he's making slow progress due to the nature of his experience.

Interesting. Does TRIP as a protocol meet your design requirements?

Specifically
a) do you think you will have anyone to talk to?

While that may be a short-term practical response to _any_ new protocol, it is not a long-term valid argument against TRIP. As I've said, the current methodology of typing in multi-page faxes, converting .xls files, and cutting and pasting from web sites only encourages VoIP islands to remain islands, and I think that I'd have a hard time finding people on this list who would disagree.

Every technology that is expected to work between administrative entities has the same problem of "who are the early adopters?" I assert that some type of protocol is required, and it will be adopted as soon as it is implemented in a free (BSD-licensed) and easily-managed manner.

Your point is taken, though, in that many LD providers will probably fight against something that represents an erosion of their pricing model. They may win by ignoring the protocol. Too bad for all of us, then, except for those on this list who make their money out of overpriced termination fees.


b) do you think that is a viable translation between metric minimization
  and LCR decisions which are presumably taken not only on (financial)
  cost minimization but also for QoS / policy reasons

I do not assert that TRIP's description in the RFC is sufficient to solve the problems I have to deal with right now. However, extensions to the protocol could possibly be sufficient to solve those problems, so I continue looking at the spec.

I am not married to TRIP - I could really care less if we use TRIP, or if someone comes up with a dynamic XML-based solution, or something else. TRIP exists as an RFC and even as a minimalist (non-usable) proof-of-concept code by the Vovida folks, and I have neither the time or the inclination to come up with a new protocol, so I've got someone dabbling in what currently exists.

I say that because TRIP is, as I'm sure you are aware, very similar
to BGP. We have coded BGP stuff before, and would probably code TRIP
stuff if we thought it would be useful. So far I've yet to be convinced
that several hundreds of thousands of lines of code later we'd not be
left with just several hundreds of thousands of lines of code. But it's
quite possible my imagination didn't extend sufficiently far beyond my
near requirements.

Alex

Using the "follow-the-money" method, here's what I see as the major issue for adoption: carriers are looking for any way possible to fill their networks with minutes. To some degree, it doesn't matter how cheaply they sell those minutes (above some administrative floor) because any usage is better than zero usage, and as long as they can stay at some minimum traffic level then they can realize some income. However, the methods for telephony providers (at least, on my level) to inform each other as to what routes they have, and what the price is for those routes, remains a horribly manual and slow process. I'm sure that there are termination providers who would (as an example) jump on the chance to somehow fill their 3am-6am usage trough by reducing prices to 30% of the normal rate. Remember the days when there were multiple "rate tables" based on time of day? We're just moving this from a predictive model where there was a discount on static timeframes for a rate to a reactive model where there is a discount/premium based on actual usage.

Of course, price transmission is only one feature of a dynamic telephony routing protocol, and possibly not the most important feature depending on your perspective. Over time, the cost will become less important and the routing vector information will become more important.

To Duane's fears about "price fluctuation": yes, that's exactly what I want. I don't care what my outbound price is, as long as it's below some minimum I can configure. Anything below that minimum is "gravy". Is this not a desired result? Are rapidly-reacting free markets a bad thing?

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