	Cookbook

Contents

Directory Considerations

Dennis Baron <dbaron@mit.edu> (May 29, 2003)

After a user's device (UA) locates a SIP.edu SIP server and forwards a SIP INVITE to it, that server needs to be able to identify the terminating user's SIP address and forward the request to the actual called device. SIP servers typically do this by keeping a location database that maps users that have registered with it to the actual SIP device or devices where the use might be present. Thus sip:alice.smith@bigu.edu can be redirected to IP address of Alice's actual device at sip:10.1.2.3.

For SIP.edu that device may not be a SIP device but a traditional telephone connected to the university PBX. A gateway is used to interconnect the university's IP network and their PBX. This gateway can convert packet switched voice on the IP network to circuit switch voice on the PBX. It also converts SIP signaling on the on the IP network to the appropriate signaling for the PBX and vice-versa. Typically this allows calls to sip:23456@gateway.bigu.edu to connected to extension 23456 on the PBX and calls to 27890 on the PBX to get connected to sip:27890@bigu.edu . The SIP server can map sip:23456@bigu.edu to sip:23456@gateway.bigu.edu . This is typically done in the dial plan in the server by redirecting or forwarding addresses of the form 23XXX to to the gateway.

To allow sip:alice.smith@bigu.edu to connect to Alice's PBX phone we need a way to map that address to sip:23456@bigu.edu. This requires two things.

A SIP server that can do the mapping
The data needed to do the mapping

An ideal situation would involve an authoritative, online, real-time directory service (such as LDAP); standard formats for presenting a user's electronic mail address and PBX extension; and a SIP server that could query the directory service and retrieve the mapping data. Lacking the ideal a more manual approach can be used.

One of the first tasks is to identify the source, or the best source, for the necessary mapping data. The following should be considered in identifying that source.

The data used should be publicly available and consistent directory information.

While most universities consider the entire directory (the traditional "phone book") to be restricted to internal access most allow access to individual listings to the public via a web interface or via the universities main telephone number. The data should be consistent with what would be offered by a web directory or university directory assistant operator.

One and only one entry should be provided for each electronic mail address.

Directories may list multiple extensions for an individual. Where individuals share PBX extensions it is appropriate to have multiple electronic mail addresses map to the same extension. If there is no PBX extension associated with a user then a mapping should not be provided.

Only listings on the gatewayed PBX should be provided.

Directories may list phone numbers that are not PBX extensions. Since SIP.edu allows unrestricted access non-PBX numbers should not be included - particularly if calls to those numbers involves a per-call or per-minute charge.

While the primary goal of SIP.edu is to allow SIP connectivity to individuals one could also provide access to groups or services. Thus sip:postmaster@bigu.edu could map to a PBX extension for the university postmasters. Or sip:snow@bigu.edu could map to the weather announcement line, 27669. Care should be taken to insure that these mappings are appropriate. For example, snow@bigu.edu may be the mailing list for the Ski Club. It is best to keep to published directory information to avoid inappropriate mappings.

Many universities have sub-domains such as med.bigu.edu. Care should be taken to avoid confusing the mappings for sip:alice.smith@bigu.edu and sip:alice.smith@med.bigu.edu since these may or may not be the same individual.

Specific examples on retrieving, formatting, and loading mapping data into the SIP server are included in the recipe sections.