The session initiation protocol (SIP) is one of the most popular signaling protocols used in applications that require a session setup and parameter negotiation before actual communication, as well as for session management and termination. Though SIP was designed primarily for voice over IP (VoIP) telephony, it currently is used in a variety of applications, including those for multimedia conferencing and multimedia content distribution.

SIP allows two or more participants to establish a session consisting of multiple media streams using text-based request and response messages. A user, termed a SIP endpoint, is addressed by a SIP URL in the form of an e-mail address, such as sip:alice@vocal.com or sip:alice@192.168.0.2. The application used for communication is called the user agent (UA). Call initiation and modification is done through INVITE messages of SIP. Two endpoints can communicate with each other directly, or they can make use of a SIP entity called the redirect server. The user first sends the request for call initiation to this server, which queries a location service to retrieve the IP address and port of the other user. The location service keeps track of the current location of the users.

One of the ways to populate a location service is to use a SIP entity called the registrar. The registrar takes registration requests in REGISTER messages from users to keep a dynamic record of the current location of the user. In some situations, it is undesirable for a network to give away its users' actual IP addresses for security reasons. In this case, a SIP proxy server forwards SIP requests and replies to other SIP messages on behalf of the user. In the rest of this article, the user agent, the redirect server and the proxy server are referred to collectively as a SIP network. More details about SIP can be found in RFC 3261.

Mobility is a key aspect of many applications requiring signaling. A user using a wireless phone may move from network to network and still expect to be reached seamlessly by other callers, even while in the middle of a call. However, no open-source SIP implementation currently supports mobility. In this article, we provide the first open-source SIP implementation that supports mobility. We use the open-source VoIP software VOCAL from Vovida.org and add mobility support to it. The result is a complete, open-source SIP implementation with mobility support that other developers can use to build SIP-enabled mobile applications. The software supports seamless SIP signaling when the user moves from network to network, as well as automatic hand-off if the user is in the middle of a call while changing networks. The implementation is done on Linux and currently is in the process of being contributed back to Vovida.

VOCAL was chosen as the core of this work because this software suite is a robust implementation of the SIP protocol and its various entities and is used widely. It therefore was felt that adding mobility support to VOCAL would allow the software to be used by a wider community of mobile application developers. The potential to contribute back to the Open Source community and the chance to interact with an active SIP community also were notable motivators for us to opt for VOCAL.

VOCAL contains a SIP user agent and various types of SIP servers. The user agent is called GUA, which also can be run from a GUI front end called SIPset. The implementation of the SIP proxy server in this suite is called a marshal server (MS). The redirect server and the registrar in SIP are combined together as the redirect server (RS). The location service contains two types of information—a database of users' current locations and a database called the Dial-Plan. The Dial-Plan is used to keep track of users in other VOCAL systems; it is a mapping of SIP URLs to the appropriate SIP server's address to which the SIP request message should be forwarded by MS.

The communication between two independent VOCAL systems is achieved by one-to-one correspondence of a marshal gateway (MSGW) on each system. Thus, a VOCAL system needing to communicate with multiple other VOCAL systems requires multiple marshal gateways. A standard SIP network also requires the users to subscribe to that network for authentication purposes. This subscription is implemented in VOCAL in the form of provisioning to a server called provisioning server (PS). VOCAL systems are provisioned from a Java-based GUI. The data from PS is stored in the MS, which the latter uses to authenticate the user before accepting any message from the user, including a REGISTER message to register the user in the location service. VOCAL contains some other SIP entities that are not relevant to this work.

Mobility in SIP has two aspects. Re-registration from a foreign location by the mobile user agent helps the registrar in the home SIP network keep a record of the user's current location in the form of IP address or DNS name. Mid-call or hand-off mobility keeps an active SIP session alive even when the IP address of the user agent changes. Re-registration from a mobile SIP UA can be done in various ways (see the on-line Resources section). We implement two models, Home-Registration-Only and Outbound-Proxy-Intercept, that are widely applicable. In the first model, the mobile UA can communicate directly with the home registrar, without having to register itself in the foreign network. This model is applicable to simple networks that do not need security, for example, multiple SIP networks within a single company.

The second model is more generic and allows for better security. In this model, a local SIP proxy server in every network, called the Outbound Proxy, intercepts every outgoing SIP request sent by the mobile UA. On a registration request by the mobile UA, a temporary registration is made for the user in the foreign network by the proxy. The proxy then registers the user's current location as its own IP address in the home registrar of the user on behalf of the user by sending a REGISTER message. Henceforth, any SIP message for the user sent to its original IP address in its home network is forwarded to the proxy, which then forwards it to the user. More details about these registration models can be found in the SIP Registration Internet Draft (see Resources).

The other form of mobility, hand-off, is achieved by resending the same INVITE message originally used to initiate a call with modified parameter(s). Though the connection actually is broken and re-initiated, the end user can get a seamless experience if the call reestablishment can be done automatically and quickly.

In this article, we have implemented the home registration only and the outbound proxy intercept models. The article also implements a handoff that allows active calls to be reestablished automatically with low latency and hardly any discernible effect on the user.

In this case, the mobile GUA triggers a fresh registration request to its home registrar upon detecting a change in its IP address. The home agent treats this registration request in the same way it treats any other registration request from any user, static or mobile. The main change in the GUA was adding a thread that can detect a change in the host's IP address (by polling). If a change is detected, the GUA triggers a fresh registration request.

The other functionality added to the GUA was that of hand-off. In this simple situation, the call session establishment and termination processes remain the same in the GUA. The mobile GUA always must send the INVITE message directly to the callee if it has to initiate a call. On the other hand, any other UA trying to call the mobile GUA should send the INVITE message to its home VOCAL system.

Adding mobility support in this case required the modification of some of the SIP servers in VOCAL. The marshal server was modified to make it forward registration requests from visiting mobile hosts to their corresponding home networks. If the registration request with the home network is successful, the MS temporarily would register the same mobile GUA as a visitor in the current network. Originally, the MS would authenticate any message coming from any SIP UA. The authentication would be successful only for the users who have subscribed to the network. Here, subscription is equivalent to provisioning the VOCAL system with an account for the user.

We have assumed a policy that every mobile host subscribes to only its home network. So when a mobile host roams into a foreign network, it must be registered temporarily as a visitor. To facilitate this, the MS was made to check the message type and the destination of the message. If it is a REGISTER message and the destination is in some other SIP network's domain, the MS does not invalidate it. Instead, it forwards the message to the redirect server, which in turns informs the former about the appropriate route (appropriate gateway of this SIP network) to take in order to send the REGISTER request to its home network. The authentication of the mobile host in a foreign network totally depends on the reply from the home network. If the home network successfully registers the user, the foreign network then would register the mobile host temporarily on its network with the IP address of the proxy as the user's IP.

The temporary registration in the foreign network is accomplished by creating a new temporary user identifier by concatenating the visitor's address and the proxy's domain. For example, if the user user1 with home network cse.iitkgp.ernet.in enters the foreign network ece.iitkgp.ernet.in, the temporary user name in the foreign network is user1%40cse.iitkgp.ernet.in, where the %40 is the URL-escaped @ symbol. This temporary ID is created by the MS, which had received the 200 OK SIP response from the visitor's home network. The MS then generates a REGISTER message with this temporary ID and sends it to the RS, which creates a temporary subscription for the visitor, along with registering it. After this, the RS sends a 200 OK message to the MS, which in turn forwards this to the user agent. So, the user agent, through one REGISTER message to its home network, registers both in the home network and temporarily in the foreign network.

The necessary modification made in the Redirect server was to make it look up and return back the proper gateway in its database, using the dial-plan for the REGISTER messages. It would do the same earlier for INVITE messages but not for REGISTER messages.

Two types of call initiation involving the mobile GUA can happen when it is in the foreign network—when somebody else (a static GUA) calls the mobile GUA and when the mobile GUA calls somebody else. In the case where a GUA (static or mobile) initiates a call to the mobile GUA, the invitation first reaches the home VOCAL system, which, based on the registration entry for the mobile GUA, forwards this request to the marshal gateway of the foreign VOCAL system, where the mobile GUA currently is located. The foreign VOCAL system checks for the normal registration entry. In case of a failure, it checks if the user is a visitor who had been registered temporarily in the system. On success, it forwards the request to the mobile GUA directly. All the responses and acknowledgements follow the same path.

When the mobile GUA tries to initiate a call with anyone else anywhere, the MS by default checks the authenticity of the user. In case of a visitor such as the mobile GUA, which is not a subscriber of the network, the MS compares it with the temporary visitor ID in the system's database. It then forwards this invitation request directly to the VOCAL system to which the callee is registered, which in turn forwards it to the callee.

The signaling required for the hand-off is done by sending a re-invitation from the mobile GUA to the other participant in the call. This is done independently of who initiated the call. In both models of the re-registration process described above, the re-invitation request is sent by the mobile GUA only after it has re-registered successfully (that is, after receiving a 200 OK message) with its home network from wherever it currently is. The re-invitation informs the other call participant about the new IP address, which then is used by the RTP session for any subsequent audio transfer.

When a SIP user moves into a foreign network, it first needs to find the SIP proxy server in the foreign network. The SIP proxy server can be detected by querying for DNS SRV records for the SIP service (see Resources). This method requires configuring the DNS server with a SRV record for the SIP proxy server in the domain. The mobile GUA has been programmed to trigger a DNS SRV query when it is started in the mobile mode and, subsequently, when its IP address changes when it changes networks. It then retrieves the proxy server's IP address as well as the port from the query result and configures its proxy server entry with this information. All subsequent SIP communications are done by way of this outbound proxy. An example of a SRV entry in the DNS server for a SIP proxy running on UDP port 5060 is shown below.

_sip._udp.cse.iitkgp.ernet.in  10  IN   
↪SRV  0   0   5060   144.16.192.97

In case the DNS server of a domain does not support SRV records for SIP service, this DNS SRV query feature of the mobile GUA may be turned off. For this, we have introduced a new flag, named DNS, in the configuration file of the VOCAL GUA. If DNS SRV query is turned off but mobility is turned on, the user is expected to enter a list of domains along with their corresponding SIP proxy servers in the configuration file to support mobility across these domains. The domains can be represented by either a range of IP addresses or a domain name. We have added a tag with a special syntax to the configuration set for this purpose.

The test bed for our experiments is comprised of two 802.11b D-Link Access Points connected to two different subnets inside the same building. We set up three different PCs to run three independent VOCAL systems representing three different SIP networks. For the time being, the networks are divided on the basis of certain IP ranges. One of the hosts is a PC and represents a static UA. The mobile host is a Toshiba laptop that uses D-Link's DWL-650 PCMCIA wireless card. The laptop has been configured to get its IP address through DHCP. Therefore, when it hops from one access point to another, it gets a new IP address, because the access points are in different subnets. This involved minor changes to the wireless driver to make it inform a running dæmon called wland about the wireless card's reassociation with a new access point. This dæmon program comes as a part of the open-source driver package the linux-wlan Project. The dæmon, after being informed by the driver about this change, triggers a fresh DHCP request for an IP address in the new subnet that it enters into. The DHCP request also should be able to retrieve the domain name. The mobile GUA running on the laptop takes this as entering a new SIP network.

The administrative setup for the VOCAL software suite remains the same, and no extra features have been added to the administrative configuration. Three independent VOCAL systems run on three different PCs to represent three independent SIP networks. Moreover, we follow a policy of assigning a particular SIP user ID pattern to a particular SIP network (VOCAL system). The subscribers of the three networks have the user ID of the form 1xxx, 2xxx and 3xxx, respectively. The VOCAL software supports numbers (such as phone numbers) as SIP user IDs (or user names) for the time being.

A SIP signaling path between two VOCAL systems is determined by a one-to-one correspondence between two marshal gateways, one on each of the systems. One VOCAL system can have more than one such gateway. Because we are dealing with three VOCAL systems, each of them is configured (using the Java-based provisioning GUI) to run two gateways each, so there is a pair of gateways for every pair of VOCAL systems. In our experiment, the gateways run on ports 5065 and 5066 in each VOCAL system. MS runs on port 5060, which is the default port for SIP services.

The next important aspect of administrative configuration (or provisioning) is setting up the dial-plans. If the VOCAL system does not get back the route from the redirect server's registration database, it redirects the invitation and other requests to the appropriate SIP entity, depending on the user ID of the final recipient of the requests, by using this dial-plan. Each entry in the dial-plan consists of a particular pattern of SIP address mapped to an address of the SIP entity to which the MS should forward the SIP requests. So, if the requests are for a user who is in another VOCAL system, and is neither a subscriber nor a visitor of this VOCAL system, then they should be forwarded to the gateway pointing to that other VOCAL system.

The software has been tested in our lab; however, more testing by the Open Source community is needed.

SIP Registration Internet Draft: www.iptel.org/info/players/ietf/mobility/draft-schulzrinne-sip-register-01.txt

Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, “SIP: Session Initiation Protocol”, RFC 3261, June 2002.

Rosenberg, J., Schulzrinne, H., “Session Initiation Protocol (SIP): Locating SIP Servers”, RFC 3263, June 2002.

A. Gulbrandsen, P. Vixie, and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV)”, Request for Comments 2782, Internet Engineering Task Force, Feb. 2000.

VOCAL Manual: www.vovida.org/document/vocaldoc/guide/userguide.pdf

Vovida: www.vovida.org

The linux-wlan Project: www.linux-wlan.org