[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Enterprise VoIP Peering Point?
At 5:59 PM +0100 on 8/11/04, Alex Bligh wrote:
--On 11 August 2004 15:29 +0000 Paul Vixie <email@example.com> wrote:
And that opens up another can of worms (in an echo from a month ago on
this list) which is that there is no current mechanism (pace TRIP) to
communicate these metrics.
in principal, some of these metrics could also be expressed in DNS.
Communicating it is only a small part of the problem. Having some
language to express it in which can be automatically parsed is another.
At risk of a crossover with another list ( :-) ), another issue is
time-based non-repudiability. IE I want to be able to say "yes you
did offer me $0.013 per minute on that route not $0.014, and I
know it was you as you signed it, and I can show the subsequent
update was signed after I made the call". I am not sure that can
be done at the moment (though you will know better than me).
You've hit on a very important topic; more below.
In my innocence, I have started to work on a document that defines
for my firm how we will accept route/rate advertisements in CSV form.
As soon as I get some more time, I'll have an XML description of the
same data. We have too many carriers sending us too much garbage,
and if we even hope to get things automated we need to come up with
an agreed-upon format. Then it's an easy step to move to real-time
authenticated transfer of those route tables. TRIP is great, but
after looking at it more, I'm uncertain that it's complexity is
required. (Though I do really like the ITAD concept, since it
expresses easily a corporate entity with a single number, just like
If anyone wants the preliminary working document on rate transfer
standardization, mail me and I'll send you the RTF document.
Paul correctly states that this additional cost/preference/etc. data
can be shoehorned into DNS (or DNSSEC) replies, but I worry about two
things: specific differing answers (iow: costs) being given to
specific differing IP address queries adds complexity, and asking a
carrier or vendor to run such a complex system to service a small
(but vocal) customer base is probably nil. Complexity doesn't
necessarily frighten me, but it frightens carriers to the point of
saying "ENUM with rates!" causes them to turn tail and run away
screaming. Therefore, I'm focused on simply modifying the existing
format that I've seen as the de-facto standard (CSV format, or Excel
format) to make it comprehensive. An XML version of the same data is
not a change in content, but slightly different form that will serve
better in the future.
I've considered how I am going to then input these into a back-end
which then provides ENUM answers for my private network. (I could
also just use direct DB queries from my routing engines, but some
platforms only support ENUM.) Some minor hacking I suppose will be
required to make less-specific routes with better rates show up
higher on the SRV list than more specific routes with worse rates, or
even to show less/more specific routes at all in the same SRV reply
list... Also, there would need to be "localpref" available as an
additional marker on routes or carriers, to allow an administrator to
artificially de-preference certain low-quality paths (automatically
or manually - makes no difference.) I'd like to make all of this
open-source using BSD-licensed packages, so that it can be deployed
as a big tarball with instructions.
A reasonably fast database can store this data, and then reconcile
billing with carrier presentations, which is critically important in
this age of razor-thin margins and somewhat underhanded billing
strategies by certain carriers. There is no uncertainty in such a
system - all prices are stored forever, and compared against costs
charged. OSP might be the model for reconciliation; did anyone here
have any insight into how that might work or not work?
As usual, free work progresses at a glacial pace until critical mass
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 <http://psg.com/lists/voip-peering/>.