[Asterisk-Users] Opportunistic VoIP

[John Todd]

>  > I'd say it's on-topic, since it's something (if implemented) could
>>  radically change the way Asterisk moves calls between servers.  If
>>  understood correctly, I believe it could be the single biggest change
>>  that the VOIP industry ("movement"?) could use to destroy the
>>  existing traditional infrastructure of the phone system.  Asterisk
>>  seems to be a pretty good hammer right now for starting that job; I
>>  think TRIP would give some extra muscle to the task.
>
>kazaa meets telephony...  i like it.  i'll think about some of this in its
>potential application to IAX2, for more practical uses, too, although I
>don't see IAX2 assimilating all of TRIP's functionality, but the ability
>to plug a phone into a LAN and automatically have it know the dialplan
>would be handy, as would being able to setup a distributed network of
>Asterisk servers with no centralized authority.
>
>mark

Glad to see it's of some potential interest.

The nice thing about TRIP is that it's an RFC already, and there are 
other vendors who have implemented it.  Acme Packet, as an example, 
implements TRIP. 
(http://www.acmepacket.com/html/products/products_sr.htm)

Alas, the only "free" implementation right now that I can find is in 
C++ (from the Vovida/Vocal project) so it would have to be re-written 
for Asterisk in C if it were to be incorporated as a module, though 
again I'll note that it's under a very open license so it can be 
incorporated as part of the distribution without any licensing issues 
even it's current form were utilized.

It may not be necessary to incorporate it as a module, however.  It 
could be the case that the TRIP server is a "separate" process away 
from Asterisk, and would be queried through perhaps a variant of the 
"switch" statement.  This would allow for easy separation of the TRIP 
server for a cluster of Asterisk servers without unnecessary route 
duplication across every single Asterisk box.  Actually, this seems 
to be the way that TRIP was envisioned to work, so perhaps this is an 
optimal configuration.  Or, of course, it could all run on the same 
system and simply communicate through sockets.  Only a small "glue" 
routine would need to be patched into the Asterisk server and the 
TRIP system in order to announce and pre-cache those routes/numbers 
which could be reached through a TRIP peer.  I have no idea how the 
"switch" statement works in IAX2 or what it's limits are...

To your point about "plug a phone into a LAN and automatically have 
it know the dialplan": it would be more like "plug an Asterisk server 
into a LAN and tell it about some peers and it would know the 
dialplan."  Then, phones would simply be dumb agents that would 
forward calls to their "default route" (the Asterisk server.)  I 
don't think that it would be wise to forward full route tables to 
desktop UA's, since those tables could potentially be very, very 
large.  However, that may simply be a "filter" that is installed in 
the iax.conf setting for that friend.  (There's a big ball of wax! 
Filters for IAX2 hosts.)  If you're not already aware of concepts 
like "forwarding table" and "routing table", drop me a line - they 
aren't difficult concepts but they aren't obvious until you've passed 
certain sizes in your route tables, and then they become extremely 
important.  :)


More tidbits:

Papers on TRIP routing and some C++ (bleh) code for libraries:
http://www.cs.columbia.edu/~kns10/projects/summer2002/trip
I don't know what the licesnsing is for this TRIP stack, or if it's 
different than that of the Vocal system - I didn't look too hard.

JT