Incorporating OverCord into a SIP User Agent
7.5 Modifying the JAIN SIP applet phone
7.5.3 Services
Currently, when a user creates a session using JSAP, theMessengerManagercalls a method such as sendInvite which creates a SIP INVITE message and formats it appropriately. It then creates a client transaction and passes control to the MessageListener which uses a SipProviderto send the message to the appropriate destination. This general model is pre- served in the modified user agent but with one difference: it must first obtain the location of the target user from the distributed location service. For this, it uses the plug-in data retrieval
method, after which, it can then send the message to the proper destination. This process is il- lustrated in Figure 7.3 which shows how a lookup is propagated through the network and a SIP message is subsequently sent to the intended target user.
Figure 7.3: Message relay in OverCord.
Voice, instant messaging and presence services are enabled in a peer-to-peer environment with only slight differences between them. TheMessengerManagerhas asendMessagemethod to send an instant message, asendInvitemethod to request an audio session andsendSubs- scribeandsendNotifymethods to request and return presence information.
In any case the user agent must first obtain the location details of where the destination host is available. These records are present in the location database distributed among all the nodes.
The user agent must therefore then use the active plug-in to perform this query and obtain the location. The MessengerManager object obtains a representation of this binding through the plug-in framework, and then uses the binding to reset the next hop destination. This is necessary since in the absence of a static proxy, the sending user agent must continually redirect this property to the intended user. The user agent does this by resetting theConfiguration object properties outboundProxy and proxyPort accordingly. The user agent’sSipProvider creates a new client transaction for the request and sends the message.
An extension to the SIP messaging system that the user agent introduces is the use of an overlay
name header. This header is appended to each outgoing message that is sent, where the value associated with the header name corresponds with the user’s local overlay name which is ob- tained by parsing the user’s SIP AOR. The advantage of this is that the receiving endpoint is able to parse this header and make an association between a live node and an overlay which can be inserted into a bootstrap list in case the endpoint should want to join this overlay at another time.
Over time, each user agent could build up a list of potential bootstrap hosts that can be attempted in addition to the usual discovery protocols.
When a message reaches the destination user agent, the MessageListener object detects the incoming request event and must determine how the message will be processed. The lis- tener has processRequest and processResponse methods which pass control to the instance of theMessageProcessorclass to handle the specific actions associated with mes- sage handling, such asprocessInviteandprocessMessagefor processing INVITE and MESSAGE requests respectively. The receiving user agent then needs to parse the SIP message that it has received to obtain the identity of the sending user and obtain the corresponding con- tact address or addresses associated with that user. Since this user agent may have a different next hop configuration from a previous communication session with another user, it reconfigures them appropriately so that the response can be sent to the initiator of the request. The destination user agent creates a new server transaction for this new request and responds using the processor object.
7.5.3.1 Audio Capabilities
There is a special need for discovering the capabilities of other users in the overlay without ringing the other party through the use of the SIP method OPTIONS as described in [100].
One use of this method is for establishing audio sessions. Some canonical SIP networks allow user agents with incompatible media codecs to communicate by providing media transcoding on their behalf. In the user agent, while some nodes may provide this service on the behalf of the overlay, user agents may send OPTIONS messages to target parties to discover their abilities before they transmit a media invitation. The user will be notified if there is a problem with media compatibility.
7.5.3.2 Presence Capabilities
Table 2.1 defined the SIP method PUBLISH as a request method that is used by SIP user agents to advertise presence status to a presence agent such as a SIP presence server. Other SIP devices
known as watchers subscribe to this status using the SUBSCRIBE method and the presence agent returns a NOTIFY to the watcher as a notification. In P2P SIP, there is no dedicated presence server to receive PUBLISH methods and as such only the SUBSCRIBE and NOTIFY methods are used in a peer-to-peer fashion. In the user agent, when the presence status of a user changes, the list of watchers with valid subscriptions to presence state is collected and NOTIFY messages are sent to each in sequence. Figure 7.4 shows the buddy list of a user in the domain bamboo.dyndns.org. The figure shows that this user is able to obtain presence information about users in their own overlay and in other overlays.
Figure 7.4: Presence support across heterogeneous overlays with the JAIN Applet.
7.5.3.3 Instant Messaging
Table 2.1 defined the SIP method MESSAGE which is used to convey instant messaging infor- mation. These messages can be exchanged between each user directly. Figure 7.5 shows an instant messaging session between users in different overlays.
Figure 7.5: Instant messing session across heterogeneous overlays with the JAIN Applet.