SIPNoTE: Extending SIP with Notice Transport and Delivery Services

While the main purpose of SIP (Session Initiation Protocol) is to, as the name indicates, provide the necessary tools to aid in the connection of  users to a variety of multimedia conferences and the like, I believe that the underlying framework could provide much more than that.  I believe that will a few extensions, SIP would be able to support the needs of a full fledged notice transport and delivery service that could provide immediate and "reliable" communication in a distributed environment.  To explore the potential benefits of such an extension, as well as to discover the necessary modifications which must be made to SIP to support it, I would like to create a distributed version of the Unix write utility, in the flavor of the Zephyr Messaging System,  which would enable users to send a single message to others who are also on the "system."

In order to better focus my efforts, I have come up with the following set of properties which I believe that such a system should possess:

  1. The system should support user mobility by having the user register themselves and provide their current location, so that notices can be forwarded automatically.  This mechanism will also allow others to determine who is logged onto the system.
  2.  
  3. Upon registering with the system, users should be able to express interest in certain "multicast" groups (by subscribing to them), and have all notices which are sent to these groups redirected to them.
  4.  
  5. Users should be allowed to send notices to multiple recipients at a time without necessarily ever having to know who the exact recipients are.  (This is a use of the "multicast" groups mentioned above.)
  6.  
  7. Users should be allowed to transmit notices of any length across the system.
  8.  
  9. Notices which are sent are assumed to be time-sensitive, and no queuing mechanism will be provided at the server end.
  10.  
  11. Users should be allowed to choose whether or not delivery of the message is acknowledged, thereby creating extra network traffic only when necessary.
I am by no means attempting to implement the full functionality of SIP, but instead only implementing those components  which will be necessary for the distributed write to function, at least at a basic level. Nor am I attempting to address any of the security issues which must be addressed if this is to be used in any widespread manner.

Checkpoints for my project will be as follows:
 

  1. Implement a "proxy" server and client in Java which can register/deregister the user without keeping track of the user's "subscription" information, using TCP as the transport.
  2. Add the necessary framework to the server and client for one client to be able to send a message to another client
  3. Modify the framework in the step above so that a single message can be delivered to multiple recipients.  (These are arbitrary groups of users, like with email, and not multicast groups.)
  4. Modify the client/server code so that they can use UDP as the transport, and split/combine user messages as necessary.
  5. Modify the client/server so that "subscription" information can be transferred from the client to the server to enable application level multicasting (I believe that for large numbers of varying subscriptions, application level multicasting may be the only feasible solution.)
  6. Modify the client/server so that users can send and receive messages based on the subscriptions.
  7. Modify the "proxy" server to enable the creation of peers for load balancing purposes.
 


Bill Nagy
nagy@watson.ibm.com
Last modified: February 5, 1998