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:
-
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.
-
I believe that this requirement can be fulfilled by implementing a simple
SIP proxy/location server which can perform the required functions.
(Although it is possible to split these two tasks up, I believe that it
will be much easier for me to implement them as a single entity for the
first pass.) I should be able to use the standard "REGISTER"/"UNREGISTER"
methods in SIP to do this.
-
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.
-
It will be necessary to add some additional functionality to the proxy/location
server so that it will be able to track user subscriptions. I believe
that all of the extra information can be passed in a message-body of the
"REGISTER." (Another method may need to be added later if it is useful
to be able to modify subscription information on the fly.) The redirection
may be accomplished by setting up true multicast groups, although I believe
that application level multicast may be the answer in this particular situation,
since I do not wish to impose a fixed set of subscriptions, but instead
wish them to be created dynamically.
-
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.)
-
The limit of only being able to specify 1 URI per message makes fulfilling
this a bit difficult in the current SIP architecture, and it may not be
desirable to force the client to fork the requests. In addition,
the SIP document states (page 16) that "The default is to attempt to reach
the first available callee. If the address is designated as a group
address, a proxy server MUST return the list of individuals instead of
attempting to connect to these." For a notice service, it would seem
more logical to me to have the message fan-out occurring at the server
end, so that network traffic would likely be reduced. In addition,
if we want to maintain some level of privacy, we don't necessarily want
to let everyone know what subscriptions a user has. I would propose
to allow the user to be able to specify more than one recipient per message,
and have the proxy server be responsible for handling fan-out in the case
of notifications.
-
Users should be allowed to transmit notices of any length across the system.
-
Number 4 requires either the use of TCP as the communications protocol,
or the ability to break up components of the notification if they are shipped
via UDP. (In the current SIP architecture, there is a limit on the
size of the message, namely the maximum packet size.)
-
Notices which are sent are assumed to be time-sensitive, and no queuing
mechanism will be provided at the server end.
-
Since SIP poses no constraints on this, it shouldn't be much of a problem.
-
Users should be allowed to choose whether or not delivery of the message
is acknowledged, thereby creating extra network traffic only when necessary.
-
In many cases, especially when the recipient is a subscription, it would
not be desirable to have each receiver acknowledge the receipt of the message.
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:
-
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.
-
Add the necessary framework to the server and client for one client to
be able to send a message to another client
-
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.)
-
Modify the client/server code so that they can use UDP as the transport,
and split/combine user messages as necessary.
-
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.)
-
Modify the client/server so that users can send and receive messages based
on the subscriptions.
-
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