Internet Engineering Task Force SIP WG INTERNET-DRAFT Mick O'Doherty draft-odoherty-root-sip-servlet-00.txt Nortel Networks August 2000 Root SIP Servlet Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. 1. Abstract This Internet draft builds on and refines the SIP Servlet API defined in [3]. The SIP Servlet API defines an API for SIP Clients that allows them, via a SIP Servlet engine, present messages to 'Servlets' which can then interact with the message and the Client to change the behavior of the CIP Client. This document expands on this concept to: - Suggest a standard way to identity or name SIP Servlets - Introduce the concept of a 'Root' SIP Servlet - Introduce some rules and mechanisms for SIP Servlet interaction - Suggest some Permission parameters for invoked SIP Servlets 2. Introduction 2.1 Background The SIP Servlet API Internet Draft [3] defines a powerful way of extending the functionality of a SIP client by allowing it to pass received messages to SIP Servlets. The SIP Servlets can then process the message and even interact with the SIP client to generate new messages (if the security settings allow it). The concept is similar to Java Servlets in the HTTP client web server model. However, as noted in the SIP Servlet API draft[3], a mechanism is needed to identify which SIP Servlet to invoke on receipt of a message. O'Doherty Internet Draft 1 Root SIP Servlet August 2000 Also, a mechanism to allow Servlets invoke or pass control to other Servlets is likely to be very useful. Finally, to allow both of the above mechanisms function fully, a mechanism to allow the invoker of a SIP Servlet specify what 'permissions' the SIP Servlet has is needed. This document introduces and outlines mechanisms to meet these needs. Note: it is assumed the reader is familiar, at least at a high level, with the SIP Servlet API draft[3]. 2.2 Overview The key to the mechanisms described in this document is the introduction of a Root SIP Servlet. Each SIP Client's SIP Servlet Engine will have identified as part of its configuration a single Root SIP Servlet. This Root SIP Servlet will be invoked on receipt of any and every message by the SIP Client (assuming it supports SIP Servlets). This Root SIP Servlet can then look at the received SIP message and invoke other SIP Servlets based on various factors such as the content of the various fields in the SIP message, the time of day, the workload of the SIP Server etc. In the case where the SIP Client is a SIP Proxy Server or a SIP redirect server, the Root Server may simply look at the SIP address (e.g. "user@domain") the message is for (or from) and immediately call a SIP Servlet which is associated with that user and which in effect acts as the Root SIP Servlet for that user (similar to the approach in section 2.2 of the SIP Servlet API [3] but using a Root Servlet instead of a rules engine). The Root SIP Servlet has all the advantages of any other SIP Servlet (discussed in [3]). It provides the flexibility to allow the Root Servlet do just about anything within the confines of the API (and the security settings configured on the SIP Client). At the same time it does not stop the definition of well known and commonly implemented Root SIP Servlets which in effect can provide a simpler and less flexible rule based or pattern matching SIP Servlet invocation scheme where this is required. To support this approach a number of requirements are put on SIP Servlets: - there must be a way to uniquely identify a SIP Servlet - there must be a way for one SIP Servlet to invoke or pass control to another SIP Servlet - It would be highly desirable to be able to able to specify the permissions of a Servlet when it is invoked This document addresses these requirements one by one and then specifies in more detail the Root SIP Servlet. 2.3 Terminology O'Doherty Internet Draft 2 Root SIP Servlet August 2000 The following are general terms that are used in this document: SIP Client: An application program that sends and receives SIP requests. Clients may or may not interact directly with a human user. User agents and proxies contain clients. Host system: The computing platform that the SIP client is running on. 3. SIP Servlet Naming To allow a SIP Servlet be invoked, either by the Root SIP Servlet or by being explicitly requested in the received SIP message (see SIP Servlet Delivery [4]), it is necessary to have a way to uniquely identify SIP Servlets. To meet this need the following naming scheme is proposed: Org-SIPServletname-Version eg: JoeBloggs-webpicturereply-03 where: - Org is the name of the organisation or Individual who developed the SIP Servlet - SIPServletname is the name given to the particular SIP Servlet by the Individual or organisation that developed it - Version is the version of the particular SIP Servlet It is not proposed that any restriction be placed on how or where the SIP Servlet Engine stores SIP Servlets in its local store (for example by specifying that the directory structure must match the name structure). So long as the SIP Servlet Engine has a way to search for and retrieve, if found, a particular named SIP Servlet, how it does it can be left to individual implementations. 4. Servlet interaction - chaining, invocation, and communication A key requirement of the Root SIP Servlet approach is for SIP Servlets to be able to invoke other SIP Servlets. This is a tricky area, as the method of invocation, the passing of any information between the invoker and the invokee and where control is passed to after completion are keys parts of the mechanism that need to be clearly defined. At one end of the spectrum, if we allow full flexibility, invoking a SIP Servlet will simply look and behave like a method call. On the other hand if we only allow a SIP Servlet to specify in its return code which SIP Servlet should be invoked next we may loose too much flexibility. It is likely a number of mechanisms will be needed. This parallels the world of Java Web Servlets which also have a number of ways in which Servlets can interact. 4.1 SIP Servlet Chaining O'Doherty Internet Draft 3 Root SIP Servlet August 2000 This is the simplest case and is a relatively straightforward idea (note the concept of chaining SIP Servlets is mentioned in the original SIP Servlet API draft [3]). The mechanism works like this: - the SIP Servlet engine invokes a SIP Servlet, say ietf-test-01 - ietf-test-01 processes the message and decides it wants to send the resulting message to another SIP Servlet, or group of SIP Servlets - ietf-test-01 returns to the SIP Servlet Engine a list of SIP Servlets which should be invoked in the listed order before control is returned to the SIP Client - the SIP Servlet engine invokes the list of SIP Servlets in the specified order until the end of the list is reached or until one of the SIP Servlets returns an error code. The output message from one SIP Servlet is input to the next SIP Servlet in the chain. - If one of the SIP Servlets in the chain returns another SIP Servlet or a chain of SIP Servlets the SIP Servlet Engine invokes these in order until the end is reached and then moves onto the next one in the original list (and so on if the one of the second level chain also returns a chain). While this is a nice easy approach to conceptualise, obviously it could lead to problems in practice: - a loop could occur where one of the SIP Servlets in a chain or 'sub-chain' might refer to one of the previous Servlets - the overall functionality of the SIP Client could change quite radically with quite a small change in one of the SIP Servlets - if it add in a chain which in turn adds in more chains etc. - the overall chain could quickly become very complex and it would be hard to test and manage the effect of adding new Servlets. To counter the first problem above, the SIP Servlet Engine is probably the best place to implement loop detection. The second and third problems are not so easy to avoid. In general, as with any similar system, the key is in the design and testing of the various Servlets to make sure they work well together. This is certainly possible where Servlets are delivered or installed as bundles and are from a trusted provider who will have done the necessary testing and verification. However, it would still be nice to be able to add individual SIP Servlets to a SIP Client to provide specific functionality. One way to allow this would be to use the concept of a separate Chain of SIP Servlets that the SIP Servlet Engine will invoke either before or after the Root SIP Servlet is invoked. This may be worth looking at for further study. One thing that can be done is to allow a SIP Servlet which returns a list of one or more SIP Servlets to specify whether the returned SIP Servlets are in turn allowed to return further chains of SIP Servlets. If they are not allowed to do so the complexity is much reduced. So in summary the proposal is that a SIP Servlet when invoked will return: O'Doherty Internet Draft 4 Root SIP Servlet August 2000 - a list of zero or more SIP Servlets to daisy chain in the order they appear in the list - an indication of whether the SIP Servlets in the daisy chain are allowed in turn to return a further list of SIP Servlets (plus potentially other permission information - see the section on Permissions below). - a return code to indicate if there were any problems in the execution of the SIP Servlet. 4.2 SIP Servlet to SIP Servlet Communication Communication between SIP Servlets basically mirrors that of standard Java Web Servlets. There are two basic types of communication: - Direct Method invocation. There are two flavours for this - the calling SIP Servlet invokes general public methods which all SIP Servlets have (can be used to save current state of all SIP Servlets for example) or the calling SIP Servlet actually invokes a public method specific to a particular SIP Servlet (in which case it must obviously know the exact interface for the required method call for that particular SIP Servlet). - Communicating via a shared object. Although there are different ways to implement this the concept is the traditional shared object between two Servlets or Processes. The object can be anything that both can access and which is able to store the information (a shared object, a file, etc). As the mechanisms for achieving this type of communication are well understood and implemented in the Java Web Server world it is suggested that as much as possible they be reused in the SIP Servlet environment and it is not intended to go into further detail in this document. On area that potentially may be worth looking at, however, is the issue of starting a SIP Servlet up that is not already running on the SIP Servlet Engine. This may be necessary when a particular SIP Servlet wants to invoke a method on another SIP Servlet that is not currently running. Java Web Servlets are not able to request that the Servlet Engine fire up a particular Servlet which leads to slightly messy workarounds. It may be worth deciding whether SIP Servlets should have the ability to do this directly. 5. SIP Servlet Permissions In the daisy chaining case, when one SIP Servlet requests that one or more other SIP Servlets be invoked it may want to limit in some ways what the SIP Servlets can do. For instance the Root SIP Servlet may grant a wide range of permissions to a small number of key tested and trusted SIP Servlets from a known supplier of Servlets and only very restricted permissions to a further group of Servlets which may be from less well known sources. To do this it is necessary to associate with each SIP Servlet name in the daisy chain list, a permissions set which will define what that SIP Servlet is and is not allowed to do. O'Doherty Internet Draft 5 Root SIP Servlet August 2000 A SIP Servlet which is invoked with a certain set of permissions can only grant the same or less permissions to any other SIP Servlets which it invokes. Some examples of permissions that might be associated with a particular SIP Servlet are: - Permission to return a chain of one or more SIP Servlets to be invoked - Permission to modify the received message - Permission to generate new messages (specifying how many are allowed or no limit) - Permission to initiate new Sessions or Transactions (again specifying how many are allowed or no limit) Note where a SIP Servlet is given permission to chain further SIP Servlet it must be careful that they are given restricted permissions so that the total number of messages generated by them (for example) falls within the limit for this permission granted to the original SIP Servlet. 6. Security The security aspects of SIP Servlets are outlined in the SIP Servlet API document [3]. 7. Acknowledgements The author would like to thank all the people in Nortel Networks who provided input and feedback. In addition this document is simply building on and refining the work done by the authors of the SIP Servlet API draft [3] and on all the work done by those who developed the various parts of the Java Web Servlet API. 8. References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 Handley, et al., "RFC 2543 SIP: Session Initiation Protocol March 1999" 3 A.Kristensen, A. Byttner, "The SIP Servlet API draft- kristensen-sip-servlet-00.txt" Sept 1999 4 O'Doherty, M. "SIP Servlet Delivery draft-odoherty-sip-Servlet- delivery-00.txt" July 2000 Author's Address Mick O'Doherty Nortel Networks Concorde Road Maidenhead Berkshire SL6 4AG England mdoherty@nortelnetworks.com O'Doherty Internet Draft 6 Root SIP Servlet August 2000 O'Doherty Internet Draft 7