Telephony Routing over IP (TRIP) is a policy-driven inter-domain routing protocol that is used to advertise information about the reachability of telephony destinations along with other associated information. SIP (Session Initiation Protocol) described in RFC 3261 is used for signaling of Internet telephony calls. The SIPD is a SIP Server which is part of CINEMA (Columbia InterNet Extensible Multimedia Architecture). This project involved the integration of an existing implementation of TRIP with SIPD, so that SIPD would be able to route calls using gateways found through TRIP.
The integration of SIPD and TRIP calls for the instantiation of a threaded implementation of a TRIP Location Server (LS) within the SIPD server. This TRIP thread would then be called up by SIPD when the SIPD server starts. When routing information is needed for a telephone number associated with a SIP URI, the number is passed to the TRIP thread which then returns the gateway for the closest matching prefix.
TRIP offers several advantages over DNS (ENUM) and database lookups of gateways. For example, providers are able to find the best route according to metrics such as cost/pricing. In addition, TRIP can support multiple protocols, like H323. Another advantage of TRIP over DNS and local database lookup is that is fits nicely into the current heirarchical Internet based BGP (Border Gateway Protocol) for inter-domain routing. TRIP is modelled after BGP.
SIP identifies a user by an email like address called a SIP URI, e.g., sip:alice@cs.columbia.edu. Every domain, e.g., cs.columbia.edu, will typically run a SIP server (proxy, registration, redirect). Sipd is one such SIP server that can be used. When a user, say Alice, starts her phone, either a software program or a hardware ethernet phone, it registers the current location (IP address) of the user identified, sip:alice@cs.columbia.edu, with the SIP server at cs.columbia.edu. Now, if another user, say, Bob with address sip:bob@office.com, wants to contact Alice, he dials (makes a call to) sip:alice@cs.columbia.edu. The Call reaches the SIP server at cs.columbia.edu, which in turn forwards (proxies) the call to the current IP address of Alice's phone.
Background information on the TRIP protocol and its implementation can be found here.
The architecture of the integration of the two programs is illustrated in then diagram below:
If SIPD is run with the option using TRIP, the TRIP thread is started with the hostname of the server SIPD is running on. The TRIP thread starts an LSSessionManager thread, which manages peering sessions between LSs to obtain the gateway information requested. When a SIP client, SIPUA for example, makes a call to some number, the SIPD server calls upon its telmap function to use TRIP to find a gateway address. If a gateway is not found using TRIP, then SIPD resorts to either an ENUM or database/configuration file lookup.
Implementation DetailsThe sipd.c file was modified so that if the StartTRIP option was specified in the 'sipd_config' config table of the SIPD database, the RunTRIPthread() method is called to start the TRIP thread for the given host. The StartTRIP option was also added in the sipd-config.c file.
In order to be able to search for the gateway using TRIP, the telmap.c file had to be changed. A function called trip_gateway() was added so to locate the TRIP gateway by calling upon the TRIP thread with the get_trip_route() function on it. Overall, the map_tel() function had to be modified so that if the StartTRIP option was detect, TRIP would be the first gateway resource, followed by an ENUM look-up, and a configuration file/database look-up as the final resort.
The get_trip_route() function is defined in the tripthread.c file and it simply calls the findSIPGateway() method on the LSSessionManager thread running within SIPD to return a gateway.
The LSSessionManager thread uses the function findSIPGateway() in order to find a gateway for the given number. The way it does this is by searching through locally configured routing information to see if there are any perferred routes. Then the entries of the tables in the TRIB database. The TRIB database consists of four tables:
1. Adj-TRIB-In: This stores routing information that has been learned from inbound UPDATE messages. This information is unprocessed, and is used as input to the decision process. An LS has one for each internal LS as well as for each external LS that is its peer.These tables are arranged as alphabetical Tries. All tables are scanned by the findSIPGateway() function to see if there is a matching gateway available. When looking for a prefix, we look for the full length of the number first, and gradually decrease the number of digits used, going from right to left. So for example, if the number was 12129397063, it would look that up first, then 1212939706, then 121293970, and so on. All of the database tables at the LS are searched in findSIPGateway(), although I was not sure if the Adj-TRIB-In table should be used since it contains newly arrived UPDATE messages which have not undergone local policy enforcement.
The route advertising components take care of issues such as metrics, tie-breaking, and local policy enforcement to allow for the most inexpensive and valid routes.Serveral tests have been done to verify the working of TRIP within SIPD. For example, tests to see whether gateways in different ITADS and gateways that were not directly connected were tested were able to return gateways addresses for one another. These tests were done using SIPUA. The tests were done on the following topology:
A number of useful enhancements can be made to the program. One would be to find gateways using all three search methods and somehow determine which was the best to use. Another would be to use SIPD's authentication information in conjunction with IPSec and TRIP's Authentication Header for mutual authentication between LSs.