Re: VoIP peering & routing protocols (revisited)

[John Todd <jtodd@loligo.com>]

At 7:19 PM +0300 on 4/19/05, Kalogiros Constantinos wrote:
> Hello, I' m a PhD candidate interested in VoIP peering and new to this list.
> I always thought that the main shortcoming of TRIP is lack of 
> pricing information (resulting in poor selection criteria). If this 
> is true, why providers don't employ H.323 based protocols (H.225.0 
> Annex G or H.501)?
> I'd be thankful if you shared your thoughts with me.
>
> Costas Kalogiros

I'll agree with both Randy and Richard and say that the complexity of 
TRIP perhaps outweighs it's usefulness, and the fact you mentioned 
that there are large numbers of "real-life" attributes that are 
missing from the spec makes most people hesitant to commit the effort 
into coding an open-source implementation that could expect 
wide-spread use.   Chicken, egg.

I still hold the theory that if a well-written, complete, extended 
(QoS metrics, pricing information, authentication information), 
BSD-licensed version of the TRIP stack were produced or released, 
that it would gather more momentum than it has now, which currently 
hovers right around "absolutely none."  Feel free to pester the guys 
at Acme Packet into releasing their TRIP stack as open-source, which 
I think would be an excellent start.

Another problem with TRIP's basic design is that it is championed as 
being "very similar to BGP."  BGP assumes that routes are 
redistributed with path information to other peers.  I think that in 
the IP telephony world, this model rests on the assumption that those 
entities which are exchanging route information don't mind if their 
peers see information about the actual endpoints.  I think that most 
"carriers" want to disguise this information, so the TRIP model is 
already looking like a hub-and-spoke model instead of a mesh as far 
as the full routing knowledge database is concerned.  (Let's say I'm 
Banzai Telegraph and Telephone, and I buy/exchange routes from/with 
Quince Telecom and I use TRIP as the protocol for exchange.   In 
addition, Quince Telecom buys routes from Sprout Telecom. 
Realistically, Quince Telecom would never tell me (BTT) about the 
fact that a certain route was learned from Sprout Telecom - they 
would want to disguise that fact so that BTT would not circumvent QT 
and send traffic directly to Sprout.)

So, we're back to the model of clearinghouses, even if TRIP (and 
other protocols) emerge as methods for route exchange.  Trust, 
authentication, and centralized control are still unfortunately very 
high on the list of requirements for any route exchange.  If you're 
looking for a TRIP-like model, see the (open-source) Asterisk 
project's DUNDi protocol, which has some interesting concepts but is 
currently stunted by being exclusively integrated into the Asterisk 
call management system.  DUNDi also has some of the same problems as 
TRIP, but at least is being implemented in what seems to be a real 
manner (though it also lacks the pricing and QoS metrics that I think 
are critical for carrier interconnection.)

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