Re: Enterprise VoIP Peering Point?

[John Todd <jtodd@loligo.com>]

At 5:59 PM +0100 on 8/11/04, Alex Bligh wrote:
> --On 11 August 2004 15:29 +0000 Paul Vixie <paul@vix.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).
>
> Alex

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 
an ASN.)

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 
is reached...


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