Integrating TRIP with sipd

Demonstrate call routing using TRIP in our SIP proxy server, sipd.

Which software are we extending? sipd.
Features to be supported and priorities? TRIP.
Existing libraries or modules? Vovida TRIP stack, CINEMA sipd.
Programming language? C/C++
Operating system? Linux and Solaris.
GUI tool kit? existing cinema gui in cgi-tcl.
Component testing? none.
Error logging? existing sipd.
Installation mechanism? integrated with cinema.
Milestones? described in this document.

SIP (Session Initiation Protocol) described in RFC 3261 is used for signaling of Internet telephony calls. 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. We have described the detailed architecture of our SIP telephony test-bed called CINEMA (Columbia InterNet Extensible Multimedia Architecture) in a technical report.

Readings: Skim through section 1 to 6 of the CINEMA technical report. Especially the PSTN interworking, dial plan and call handling topics are useful for this project.

One important service provided by CINEMA is interworking with a regular telephone such that a PC user can call a telephone and vice-versa. A telephone user is also identified as a SIP URI, e.g., <sip:9397063@cs.columbia.edu;user=phone> indicates that the user is a telephone subscriber 9397063 and can be reached from the gateway or server at cs.columbia.edu. This mechanism works if the caller knows that there is a gateway at cs.columbia.edu that can reach this telephone number. In general, this information may not be available to the caller. Moreover, it is possible to have more than one gateways that can reach the telephone. If the caller just dials a telephone number (tel URI), e.g., tel:+12129397063, the system should be able to locate the appropriate gateway and forward the call. There are following ways to do this:

Provide a configuration file or database that indicates what number goes to which gateway. For instance, 93970xx can go to a gateway at 128.59.19.28 and 854xxxx can go to another gateway at cc.columbia.edu.
DNS (ENUM) can be used to convert a telephone number to a host name or SIP URI. e.g., for a number 9397063, it is converted to a global number 12129397063, and a DNS lookup is done for the reverse of the number, 3.6.0.7.9.3.9.2.1.2.1.somedomain.com. The return value from the DNS lookup gives the gateway address or the user SIP URI to reach for this phone number.
Have distributed databases for each service provider. The database indicates which number prefix (e.g., 1212939xxxx) can be reached at what gateway IP address.

This last approach is adopted by TRIP (telephony routing over IP). One advantage is that it allows multiple service providers reaching the same telephone destination model, similar to the current internet model. For example, a number 9397063 may be reached by sip:number@mci.com, sip:number@yahoo.com or h323:number@packetizer.com, using different protocols or different metrics (e.g., cost/pricing model).

Readings: Go through the TRIP tutorial.
Vovida TRIP stack: Go through the Vovida TRIP implementation and API documentation. Download the source code and compile it on Linux platform.

Sipd should try to use every possible means (configuration, DNS and TRIP) to resolve a telephone number to the correct destination. The order in which these mechanisms are searched should again be configurable. We maintain sipd code in CVS. The file sipd/telmap.c contains routines to call the various configuration database (map_gateway) and DNS (tel2uri) functions. The map_gateway function is defined in libdb++/dbaccess.cpp. The TRIP function should be added here to check if a number can be resolved using TRIP.

Code review: Checkout the sipd code from CVS when you meet me. Then review the parts of the code in sipd/telmap.c and libdb++/dbaccess.cpp.

A TRIP location server (lsserver for short) can be provisioned with locally configured routes with various metric. An lsserver also knows its direct peers. It can learn about the reachable destinations of the direct peers as well as indirect peers (separated by more than one hops). In general any connected graph of lsservers, will exchange information about routing such that every node (instance of lsserver) knows how to route any phone number, if the number is routable at all by any of the lsserver. Our lsserver is provisioned using MySQL database "trip". The database runs on "grandcentral.cs.columbia.edu". Ideally each lsserver will have its own database as they will be geographically distant. However, for our experiment we will use a single database for all the lsservers. There are following tables:

lsserver: This contains the global lsserver information indexed by the lsserver hostname. A unique "id" identifies an lsserver if there are multiple lsservers using the same database.
addrfamily: This contains a list of Address family (e.g., POTS, ROUTING NUM) for each lsserver.
localpolicy: This contains a list of local (optional) policy information for each lsserver. Currently there are two policy information: noexport means do not export routes to the given prefix, and discard means discard the routes received from the given IP address.
localroutes: This table stores the locally injected routes for the given lsserver. The route consists of a routing address family, protocol, prefix, next hop server, next port and next ITAD identifier.
peers: This table stores the list of peers for each lsserver. This defines the topology for the TRIP network.
protocol: This contains a list of all the protocols supported for each lsserver. e.g., SIP, H323-RAS, H323-Q921, H323-ANNEX-G. Currently we experiment only with SIP protocol.

If needed we may extend the database or define new tables. Consider the following TRIP network with four lsservers A,B,C and D.

           A ----------- B ----- C
                         |     /
                         |    /
                         |   /
                         |  /
                         | /
                         D

Let each of these be capable of routing some telephone prefix locally, e.g., using a local SIP server or gateway. Let A is capable of routing 9397xxx, C is capable of routing 854xxxx as well as 9397xxx, and D is capable of routing 1-800, 1-888, 1-877, and other US toll free numbers. B is just used for transport of TRIP messages without any local routes. Now suppose a user registered in the ITAD domain of A, or subscribed to the SIP services of A, wants to make a call to 8542000, it should be able to route the call through the SIP server/gateway at C. Similarly a toll free number should be able to be routed through SIP server/gateway at D. On the other hand, a host in domain D, may choose A or C depending of various policy decisions to route the calls to 9397063. We will try to realize the above topology by using SIP servers at A, C and D. B is just a lsserver without any gateway or SIP server functionality. To implement the TRIP functions in the SIP server, you need to modify the sipd code. Essentially this involves having both the lsserver and sipd running in a single application. The current sipd implementation uses a "gateway_map" table with the following format for local routes.

tel_pattern: telephone prefix. e.g., 12129397xxx
gateway: Gateway location, e.g., sip:$@itgw1.cs.columbia.edu
gw_class: faculty, staff, student, phd; for which this is accessible.
priority: priority of this entry if there are multiples.

This is closely related to the "localroutes" table in the trip database. To avoid confusion, we will keep the two tables separate in the initial implementation. In future, these can be merged into a single table. An alternative that prevents combining both lsserver and sipd into a single application is to use external MySQL database instead of trie or internal datastructure in lsserver. However, this involves lots of changes in the existing lsserver code. We combine sipd and lsserver by doing the lsserver related initialization in sipd/sipd.c file, and performing the appropriate number/route lookup in sipd/telmap.c file. The configuration option to enable the lsserver will be stored in sip::sipd_config table.

Initializing trip table: Modify scripts/createdb script to define an option "use_trip" with value "true" or "false". Modify the corresponding web interface to update and view this option in the SIP proxy configuration.

Initializing lsserver in sipd: Once the sipd starts it should use the local hostname as the index in the trip::lsserver table to find appropriate entry. Use gethostname() to get the local host name and perform a database lookup for the appropriate TRIP table entries. Populate the local lsserver initialization routines with this information. At this point, once the sipd starts it should print the appropriate trip table entries.

Number lookup in sipd: Modify the sipd/telmap.c file such that it looks up in the internal lsserver datastructure to find an appropriate route to the given telephone destination. Test it using the sipd/test/siptc script. At this point the modification is complete to allow sipd to use the TRIP functionality.

Testing: Now setup the topology as shown earlier with three sipd instances and an lsserver instance. Use siptc to test calling various numbers like 9397063, 8542000 and 18005556666 through various sipd instances at A, C and D.

TBD: More information will be added as and when needed.