TRIP deployment?

John Todd jtodd at loligo.com
Wed Dec 3 17:53:51 UTC 2008


[sorry for late reply - .us Thanksgiving plus LIFO mailing list  
reading creates posting latency]

On Nov 24, 2008, at 9:20 AM, cayle.spandon at gmail.com wrote:

> I'm not sure if this is the right mailing list for this question:  
> how widely is TRIP (Telephone Routing over IP [RFC3219]) deployed /  
> used in current networks?

There was a reference stack made in the Vovida package for TRIP, but  
in my experiments with it a number of years ago I was unable to  
implement it in any satisfactory way, and the code was far from  
complete.  There was a TRIP commercial implementation in the Acme  
Packet SBC (Session Border Controller) equipment, and one in the  
Jasomi SBC IIRC, but I don't know what the status of those two stacks  
is today or if anyone uses them.

I've never seen TRIP offered as a peering method in any exchange of  
any sort, so the short answer to your question as far as I know is  
"There is no significant use of TRIP today."  This is a shame, since  
it seems like it would be useful.  My belief is that there are  
significant economic dis-incentives for E.164 interconnection that are  
easily implemented and which create fluid, low-cost (or zero-cost)  
marketplaces for minutes, and I will not discuss the obvious opponents  
to such marketplaces.  E.164-based ENUM is another casualty of that  
economic structure as it is inextricably linked to political  
decisions.  There are additional problems with large-scale distributed  
routing of E.164 numbers as the trust model for number ownership is  
difficult to manage (the root cause of so many problems) and routing  
failures are much more operationally painful and difficult to resolve  
during unexpected failures.  I'd be happy to be proven wrong on my  
assumption that TRIP is not used - does anyone have evidence of TRIP  
being used in readily-joinable federations, either in conjunction with  
geographic layer 3 peering fabrics or otherwise?

Despite the failure of TRIP to catch on, there was some use that has  
come out of RFC3219 (TRIP).  The ITAD concept, which defines an IANA- 
allocated unique identifier to telephony entities in other use cases.   
An ITAD is much like an ASN, except 32 bits, and currently zero-cost.   
The freenum.org project uses ITADs as part of a lookup mechanism based  
on ENUM-like DNS methods, in effect creating a phone keypad-friendly,  
IP communications-focused alternative to the normal E.164 phone  
numbers that are the standard for PSTN dialing.  This moves quickly  
out of typical NANOG charter areas, but is worth mentioning as ITAD  
resources are being used to uniquely identify worldwide telephony  
networks that are layered on top of existing IP networks.  As of  
2008-12-03, the ITAD number space of the next assignment block will  
cross into the four-digit range.  (full disclosure: I manage the  
Freenum project, so I'll be biased and suggest that anyone who manages  
any sort of IP-based telephony system with public inbound SIP  
capability should examine this - it's trivial to set up.)

Other routing or routing-like protocols for telephony you might find  
interesting include OSP (Open Settlement Protocol), DUNDI (Distributed  
Universal Number DIscovery), and ENUM (ENUM).  Each protocol has niche  
areas in which they are used for different purposes, but none have  
been overwhelmingly successful in a public setting, though ENUM has  
been very successful in "private" interconnects and mildly successful  
in some locations which have enlightened and technically educated  
national regulators.  North America is not implementing ENUM in any  
public manner at this time to my knowledge.

References:
   http://www.freenum.org/
   http://www.ietf.org/rfc/rfc3219.txt
   http://www.iana.org/assignments/trip-parameters/
   http://www.vovida.org/protocols/downloads/trip/ (death via Cisco?)
   http://www.voip-info.org/wiki-DUNDi
   http://www.voip-info.org/wiki-OSP
   http://www.voip-info.org/wiki-ENUM

JT





More information about the NANOG mailing list