[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: VOIP Peering Questions
Just one comment on the last section where Alex said he would take any price
as long as it was below a certain level - that is exactly how Arbinet works
- the buyer puts in the maximum price they are willing to pay for a
destination, and then the "trading Floor" matches that order with the
available sellers that are under that price and routes the traffic
accordingly. The buyer pays what the actual matched rate is - not what the
max price was. That matching is updated every four hours, and so it would be
feasible to sell US domestic, say, and adjust the price so that you got
traffic when you had spare capacity.
From: email@example.com [mailto:firstname.lastname@example.org] On
Behalf Of John Todd
Sent: Thursday, June 03, 2004 3:35 AM
To: Alex Bligh
Subject: Re: VOIP Peering Questions
At 9:11 AM +0100 6/2/04, Alex Bligh wrote:
>--On 02 June 2004 00:00 -0700 John Todd <email@example.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?
>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
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
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
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?
To unsubscribe send a message to firstname.lastname@example.org with the word
'unsubscribe' in a single line as the message text body. An archive is at
To unsubscribe send a message to email@example.com with
the word 'unsubscribe' in a single line as the message text body.
An archive is at <http://psg.com/lists/voip-peering/>.