Internet Engineering Task Force SIP WG INTERNET-DRAFT Mick O'Doherty draft-odoherty-sip-servlet-delivery-00.txt Nortel Networks July 2000 SIP Servlet Delivery 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 document defines an extension to the SIP [2] protocol to combine some of the concepts introduced by the SIP Servlet API work [3] and by Java Enhanced SIP [4] 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. This document proposes a way to distribute SIP Servlets to SIP clients using the SIP protocol itself, including a way to authenticate the source of the Servlet. This may prove a useful mechanism for rolling out new services across multiple SIP clients. In addition it proposes a way for an originating SIP Client to specify in a message generated by it that it wants the message to be passed to a particular named SIP Servlet in the receiving SIP Client. Note: The SIP Servlet Internet draft [3] mentions that it may be useful in future to package SIP Servlets together with deployment information (e.g. quoting from the document "Servlet parameters, invocation mappings, and security information"). If this is added to the SIP Servlet API specification, and it seems that it would O'Doherty Internet Draft 1 SIP Servlet Delivery March 2000 likely be a good idea to do so, then this proposal for a SIP Servlet Delivery mechanism would include the delivery of the complete package (SIP Servlet and deployment information). 2.1 Overview This document defines an extension to the SIP [2] protocol to build on the SIP Servlet API using some of the concepts introduced in Java Enhanced SIP to: - Allow a SIP Servlet, or a URL reference to SIP Servlet, be distributed to SIP User Agents and SIP proxies by using SIP messages themselves (similar to JES using SIP messages to transport Java Byte code or Java Mobile Agents) - to define the actions that a SIP User Agent or Proxy should take on receiving a message which is being used to deliver a SIP servlet - to include a mechanism or the framework for a mechanism whereby the SIP User Agent or Proxy can authenticate that the SIP Servlets are from a trusted source - to define a mechanism to allow an originating (or 'sending') SIP client specify that a specific named SIP Servlet should be invoked by the terminating or receiving SIP client. Figure 1 below shows how a SIP client, receiving a SIP msg with a SIP Servlet (or a URL to a SIP servlet) in it, stores the Servlet(after having retreived it from the URL if the message just contained a reference to it) in some SIP Servlet Storage facility. +------+ +------+ +-----------------+ | SIP | SIP msg with SIP Servlet | SIP |---->| SIP Servlet | |CLIENT| -----------------------> |CLIENT| | Storage | | A | | B | | | | | | | | | +------+ +------+ +-----------------+ Figure 1 Figure 2 shows how the same SIP client, upon receiving a SIP Invite message, will present this message to the first SIP Servlet that may be interested in looking at it. In this case the SIP Servlet may be merely being used to log all received Invite messages. A possible way of deciding which SIP Servlet gets to look at the message first is outlined in the SIP Servlet API Internet draft [2]. Note that this Internet draft does not yet specify a way for multiple Servlets to act on the same message, nor how they should interact with each other, but it is noted in the document for further study. +------+ +------+ +-----------------+ | SIP | SIP Invite | SIP |---->| SIP Servlet | |CLIENT| -----------------------> |CLIENT| | Storage | | A | SIP ack | B | | | | | <---------------------- | |<----| | +------+ +------+ +-----------------+ O'Doherty Internet Draft 2 SIP Servlet Delivery March 2000 Figure 2 In Figure 3 the SIP client again receives a SIP message which it passes to the first SIP Servlet interested in looking at it and this time the SIP Servlet decides that another call should also be set up from the SIP client as well as continuing with the first call. It initiates the sequence for the new call (instructs the Client to send an Invite message) and then passes control back to the SIP client to continue as normal with the first Call. Figure 3 +------+ +------+ +-----------------+ | SIP | SIP Invite | SIP |---->| SIP Servlet | |CLIENT| -----------------------> |CLIENT| | Storage | | A | SIP ack | B | | Directory | | | <---------------------- | |<----| | +------+ +------+ +-----------------+ \ SIP Invite \ \ \ \ \ \ V +------+ | SIP | |CLIENT| | C | | | +------+ 2.2 Terminology 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 message implications The `Require' request-header is used to indicate that SIP-Servlet- delivery must be supported to process a message which is being used to distribute SIP Servlets. It is also used when an originating SIP Client wants to indicate that a specific SIP Servlet be used to handle this particular message. The feature to be supported that is specified in the require header for the SIP Servlet delivery feature is (for example): org.ietf.sip.SIP-Servlet-delivery The format of a SIP message as defined in the SIP RFC [2] is shown below and how it would be used to transport SIP Servlets or to O'Doherty Internet Draft 3 SIP Servlet Delivery March 2000 indicate that a particular SIP Servlet should be used to process the message is noted: Request = Request-Line ; *( general-header | request-header | entity-header ) CRLF [ message-body ] ; general-header = Accept ; | Accept-Encoding ; | Accept-Language ; | Call-ID ; | Contact ; | CSeq ; | Date ; | Encryption ; | Expires ; | From ; | Record-Route ; | Timestamp ; | To ; | Via ; entity-header = Content-Encoding ; | Content-Length ; | Content-Type ; < - This will indicate request-header = Authorization ; the content is a | Contact ; SIP Servlet | Hide ; contained in a | Max-Forwards ; MIME extension in | Organization ; the case where the | Priority ; message is being | Proxy-Authorization ; used to deliver a | Proxy-Require ; SIP Servlet | Route ; | Require ; < - This will indicate | Response-Key ; SIP Servlet | Subject ; delivery must be | User-Agent ; supported to response-header = Allow ; process this | Proxy-Authenticate ; message for the | Retry-After ; Servlet delivery | Server ; case or it will | Unsupported ; indicate the name | Warning ; of a specific SIP | WWW-Authenticate ; Servlet to be invoked upon receipt of this message Table 3: SIP headers An example invite message for the SIP Servlet delivery case might be: C->S: INVITE sip:watson@boston.bell-tel.com SIP/2.0 Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell To: T. Watson Call-ID: 3298420296@kton.bell-tel.com CSeq: 1 INVITE Subject: Mr. Watson, come here. O'Doherty Internet Draft 4 SIP Servlet Delivery March 2000 Content-Type: multipart/mixed; boundary=3E4A567F4C8A (or URL for SIP Servlet) Content-Length: ... Require : org.ietf.sip.sip-servlet-delivery (within the message body) --3E4A567F4C8A Content-Type: application/x-SIP Servlet Content-Encoding: binary Content-length: xxx ...SIP-Servlet --3E4A567F4C8A-- Content-Type: application/x-authentication-key (for example) Content-Encoding: binary Content-length: xxx ...authentication key --3E4A567F4C8A-- Note the Authentication key is optional - see the section on authenticating the source of a SIP Servlet in this document. Similarly an example of an INVITE specifying a particular SIP Servlet is: C->S: INVITE sip:watson@boston.bell-tel.com SIP/2.0 Via: SIP/2.0/UDP kton.bell-tel.com From: A. Bell To: T. Watson Call-ID: 3298420296@kton.bell-tel.com CSeq: 1 INVITE Subject: Mr. Watson, come here. Content-Type: SDP/audio Content-Length: ... Require : SIP-Servlet.ACMEServices.CallScreening 4. Required Client behavior As per the SIP Internet RFC, SIP proxy and redirect servers MUST ignore features that are not understood. If a particular extension requires that intermediate devices support it, the extension MUST be tagged in the Proxy-Require field as well (see Section 6.28 of the SIP RFC [2]). 4.1 Actions on receipt of a message delivering a SIP Servlet A SIP Client that supports SIP Servlet delivery, upon receiving a message which contains a SIP Servlet, MUST NOT present the message to SIP Servlets already stored in the directory Instead it MUST extract the SIP Servlet from the message, or retrieve the SIP Servlet from the indicated URL, and store it in the SIP Clients storage facility for SIP Servlets. It MAY O'Doherty Internet Draft 5 SIP Servlet Delivery March 2000 authenticate the source of the SIP Servlet before deciding to store it (see the authenticating the source of a SIP Servlet section in this document). It MAY also require the user or the administrator of the SIP Client to confirm that the Servlet be stored. A SIP client having received a SIP Servlet, whether it has stored it locally or not, MUST NOT then present the received message to the SIP Servlets. It should continue to process the message as a Normal SIP message. If the SIP Client does not follow the procedures above because it does not support this functionality, or because it chooses not to, then it MUST immediately respond by returning status code 420 (Bad Extension) and list org.ietf.sip-servlet-delivery in the Unsupported header. 4.1.1 Authenticating the source of a SIP Servlet Being able to check that a received SIP Servlet is from a trusted source is important as it can save the SIP client having to have the intelligence fro this or requiring manual intervention when a SIP Servlet is delivered to it. A particular user may not want to bother setting up the services on their SIP client themselves and instead may subscribe to some trusted service deployer to provide the services by delivering SIP Servlets to their SIP client. The service deployer may then use SIP Servlet delivery on SIP as described in this document as a convenient way of deploying and updating the services they provide. To enable such an approach it must be possible to authenticate that the SIP Servlet is from the trusted service deployer. This document specifies a way to carry authentication information in the SIP message body - it does not prescribe a particular authentication scheme: A SIP Client receiving a SIP message with SIP Servlet for delivery, having retrieved the SIP Servlet MAY also look in the body of the Multi-Part MIME message for some form of authentication application that has been agreed between the SIP Client and the source of the SIP Servlets. If the SIP Client supports the authentication feature it MAY decide not to store the Servlet locally until it has authenticated the source using the scheme agreed with the source and the authentication information passed in the message (for example a software key). 4.2 Actions for messages specifying a Servlet to pass the message to When a SIP client that Supports SIP Servlets receives a message indicating that the message should be presented to a particular SIP Servlet it MUST search for the specified SIP Servlet and if found it MUST present the message to the specified SIP Servlet. If the client does not support this functionality, or if the specified SIP Servlet cannot be found, or if the SIP Client does not wish to pass control to the specified SIP Servlet, then the SIP Client MUST respond by returning status code 420 (Bad Extension) and list the specified SIP Servlet name (as it appears O'Doherty Internet Draft 6 SIP Servlet Delivery March 2000 in the requires header in the original message) in the Unsupported header. 4.3 Actions on receipt of normal SIP message(not containing Servlets) When a SIP client that Supports SIP Servlets receives a message it should make the message available to Servlets that may want to act on it. The interaction between a SIP Client and SIP Servlets is defined in the SIP Servlet API Inter Draft [2]. 5. Interactions between SIP Servlets and Java Enhanced SIP (JES) JES [4] requires that a client that supports JES immediately execute the Java Applet or Java Mobile Agent on receipt of the message containing them. This means that for SIP Clients which support both JES and SIP Servlets, JES will execute before a message is presented to a SIP Servlet - in fact the Java Applet or Java Mobile Agent could even delete the message meaning it never gets to the SIP Servlet if this is the desired behavior and if the SIP Clients security settings allow this behavior (see the JES internet draft [4]). 6. Security The security aspects of SIP Servlets are outlined in the SIP Servlet API document [3]. This document adds a framework for authenticating the source of particular SIP Servlets which are delivered to a client. 7. Acknowledgements The author would like to thank all the people in Nortel Networks who provided input and feedback. 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. "Java Enhanced SIP draft-odoherty-sip-java- enhanced-00.txt" March 2000 Author's Address Mick O'Doherty Nortel Networks Concorde Road Maidenhead Berkshire SL6 4AG England mdoherty@nortelnetworks.com O'Doherty Internet Draft 7 SIP Servlet Delivery March 2000 O'Doherty Internet Draft 8