Java Enhanced SIP Dec 2000 Internet Engineering Task Force SIP WG INTERNET-DRAFT Mick OÆDoherty draft-odoherty-sip-java-enhanced-02.txt Nortel Networks Dec 2000 Java enhanced SIP (JES) 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 protocol to do a number of things: to extend SIP messages to carry Java applets or Java Mobile Agents, to define a Java SIP API which will allow the Java applet or Java Mobile Agent to interact with the receiving host system and to extend the SIP protocol client so that the Java applet or Java Mobile Agent is run before any other actions are taken on the receipt of a message by the receiving host SIP client. 2. Introduction 2.1 Overview This document defines an extension to the SIP [2] protocol to: - extend SIP messages to carry Java applets or Java applets plus their state and runtime contexts - in other words Java mobile agents (or URLs to either the applet or the Java Mobile agent) - to define a Java SIP API which will allow the Java applet or Java Mobile Agent interact with the receiving host system and receiving SIP client - to extend the SIP client so that the Java applet or Java Mobile Agent is run before any other actions are taken on the receipt of a message by the receiving host SIP client. Java enhanced SIP includes security measures to allow a client to be configured to enable and disable certain actions between the JVM running the Java applet or the Java mobile agent virtual machine running the Java Mobile Agent in the message and the clients SIP client and host system. O'Doherty Internet Draft 1 Java Enhanced SIP Dec 2000 Figure 1 below gives an example of how several Java-enhanced-SIP clients might interact: SIP client A sends a SIP message with a Java Applet to SIP client B who immediately passes the message to be executed on a Java Virtual Machine associated with that client. The code in the Applet creates two new messages. One goes to Client D and contains a Java Mobile agent that Client D will execute at the point indicated by its context (if it has the capability) and one goes to Client C and is a normal SIP message (no Java Applet). The Java Mobile agent in Client D suspends it self at some point in the execution and sends itself to SIP client E by including itself in a SIP message. SIP Client E will run the Java Mobile Agent in its Java Mobile Agent virtual machine (again if its has the capability). +------+ +------+ +-----------------+ | SIP | SIP msg with Java applet | SIP |-----|Java VirtualMach.| |CLIENT| ---------------------- > |CLIENT| | which | | A | | B | | interacts with | | | /| |-----| SIP Client | +------+ / +------+ +-----------------+ / \ / \ SIP msg / \ With Java SIP msg Mobile/ \ agent/ \ / \ ------------------ \ / \ / \ V V +------+ +-------------------+ +------+ | SIP |------|Java Mobile Agent | | SIP | |CLIENT| | virtual machine | |CLIENT| | D | | which interacts | | C | | |------| with SIP Client | | | +------+ +-------------------+ +------+ | | | Java Mobile | Agent | | V +------+ +-------------------+ | SIP |------|Java Mobile Agent | |CLIENT| | virtual machine | | E | | which interacts | | |------| with SIP Client | +------+ +-------------------+ Figure 1. Note: there are various different implementations available for Java Mobile Agents and the Virtual Machines or hosts that run them (e.g. Aglets, Voyager etc)- it is not intended to specify a particular one here but to keep the description general so that it may apply to any Java Mobile agent. So in a nutshell : a client sends a SIP message to another client containing an indicator in the header that a Java applet or a Java Mobile Agent is included as part of the message body (or a URL to O'Doherty Internet Draft 2 Java Enhanced SIP Dec 2000 the applet is included in the message body). The receiving client immediately retrieves the Java applet or Java Mobile Agent and runs it on a Java Virtual Machine or Java Mobile Agent virtual machine on itÆs host system. The Java code can interact with the host system in the usual way that a Java applet or Java Mobile agent can and in addition can interact with the SIP client, subject to security restrictions which the receiving host may apply at the users discretion - in a similar way to normal Java security for untrusted applets. 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. Changes to SIP messages The æRequireÆ request-header is used within all Java-enhanced-SIP SIP messages to indicate that Java-enhanced-SIP must be supported to process this message. The Java applet or Java Mobile Agent itself is either stored in a multipart MIME section in the body of the message or a URL to it is in the message. The feature to be supported that is specified in the require header is (for example): org.ietf.sip.java-enhanced-sip (for a normal Java applet) org.ietf.sip.java-mobile-agent-enhanced-sip (for a Java Mobile Agent) Note: for Mobile agent it will likely be necessary to specify exactly what format the Mobile agent adheres to e.g. org.ietf.sip.java-Aglet-mobile-agent-enhanced-sip The format of the a SIP message as defined in the SIP RFC [2] is shown below and Java-enhanced-SIPÆs use of it 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 ; O'Doherty Internet Draft 3 Java Enhanced SIP Dec 2000 | Timestamp ; | To ; | Via ; entity-header = Content-Encoding ; | Content-Length ; | Content-Type ; < - This will indicate request-header = Authorization ; the content is a | Contact ; Multi part MIME | Hide ; Message or that the | Max-Forwards ; content is a URL | Organization ; for a the Java | Priority ; byte code or the | Proxy-Authorization ; Java Mobile Agent | Proxy-Require ; | Route ; | Require ; < - This will indicate | Response-Key ; Java-enhanced-SIP | Subject ; must be supported | User-Agent ; to process this message. response-header = Allow ; | Proxy-Authenticate ; | Retry-After ; | Server ; | Unsupported ; | Warning ; | WWW-Authenticate ; Table 3: SIP headers An example invite message is given below 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: multipart/mixed; boundary=3E4A567F4C8A (or URL for java applet) Content-Length: ... Require : org.ietf.sip.java-enhanced-sip (within the message body) --3E4A567F4C8A Content-Type: application/x-sipjava Content-Encoding: binary Content-length: xxx ...Java applet or Java Mobile Agent --3E4A567F4C8A-- 4. The JSIP API and changes to SIP Client behavior All SIP clients are able to recognise the new Require: org.ietf.sip.java-enhanced-sip or org.ietf.sip.java-mobile-agent- O'Doherty Internet Draft 4 Java Enhanced SIP Dec 2000 enhanced-sip request-header. When they recognise it in a message they MUST immediately extract the Java applet or Java Mobile Agent and run it on a Java virtual machine before processing the SIP message any further or, if the content type indicates that the content is a URL, they must immediately get the applet or Java Mobile Agent from the URL and execute it on the JVM or Java Mobile Agent virtual machine. If they cannot because the client does not support this functionality, or do not, because they choose not to, then they MUST respond by returning status code 420 (Bad Extension) and list org.ietf.sip.java-enhanced-sip (or the equivalent for the Java Mobile Agent) in the Unsupported header. The applet or Java Mobile Agent MUST also have access to a set of Java Classes or applets on the clientÆs host defined in an API called a JSIP API. This API MUST provide access into the SIP client to allow SIP messages be built and sent (subject to security restrictions - see the security section later in this document). Thus the received applet or Java Mobile Agent can generate and receive SIP messages on the receiving SIP client. In cases where the code initiates a SIP session and wants to wait for a SIP response, it can specify that it will either go to sleep and wait for the next SIP message which matches a particular pattern, or it can decide to wait for and deal with all SIP messages itself. Thus control does not pass back to the SIP client until the applet or Java Mobile Agent wants it to even if SIP messages from other sessions are arriving. The SIP client MUST be able to support this functionality including the ability to accept patterns to match incoming SIP messages to, and in the event of a match to æwake upÆ the waiting applet or Java Mobile Agent. In addition it should be noted that the applet or Java Mobile Agent can interact with the host system in the same way as any untrusted applet might interact with a host system on a web browser (for example) - in other words in a very restricted manner unless the user decides to allow certain operations from certain sources (or indeed decides to allow all operations). 4.1 The JSIP API The JSIP API will provide an interface into the SIP client to allow a received Applet or Java Mobile Agent access to SIP messaging functions on the Client. The methods that the JSIP API will support are: sendSIPMessage - sends a SIP message and establishes a context for the Session if one does not already exist. The invoker can indicate if it wants the message to be part of an existing Session. receiveSIPMessage - retrieves a SIP message from the Clients input buffer on a FIFO basis receivedMessageSummary - returns a summary of any received messages in the Clients input buffer along with a count of messages received. If the Client does not support buffereing input messages this is indicated. O'Doherty Internet Draft 5 Java Enhanced SIP Dec 2000 queryCapabilities - returns the capabilities of the Client. These include the ability to buffer incoming messages, the buffer size,etc querystatus - returns the status of any sessions the Client is currently involved in. matchMessageAndWake - checks incoming messages against a particular pattern and if they match wakes up the indicated applet or Java Mobile Agent and passes the messages directly to them. processMessage - sends a message to the Client and passes control to the Client for the message to be processed as normal - - this might be used after an applet or Java Mobile Agent has looked at the message or altered it in some way and then wants to pass it back to the Client to be processed as normal. processMessageAndReturn - as above except control is passed back to the invoker after the Message has been processed. processFromBufferAndReturn - processes the next message on the INPUT buffer as normal within the Client and then returns control to the invoking Applet or Java Mobile Agent. NOTE: With the increased focus on standard interfaces and APIÆs into SIP there may not be a need for a specific one for JES. This will be monitored as the JAIN SIP API evolves and the next version of this document may be updated to reflect this change. There may still be a need for a lightweight interface with a minimal set of functions, so the interface suggested here may be retained in that role. 4.2 JES and changes to SIP proxy and SIP server 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]). 5. Security In addition to the usual Java security mechanisms, Java enhanced SIP includes security mechanisms to allow a user specify what he will allow the Java applet or Java Mobile Agent running on his host to do. The user may either configure the client to always allow or disallow certain operations or they may specify that certain actions result in a security prompt to the user before allowing the action to proceed. The actions and the method of specifying the security mechanism for a particular action will follow the standard Java security mechanism practices. All the methods in the JSIP API will check with the security manager before executing. 6. Examples Mulitmedia conferencing system ------------------------------ Lets take as a very simple example of how JES might be used, a Multimedia conferencing service which adopts an architecture where meetings are set up by the chairperson sending out SIP invite messages containing Java Applet which will execute on the host machines of the invited attendees. O'Doherty Internet Draft 6 Java Enhanced SIP Dec 2000 For instance the Java Applet may set up connections from the attendees machine to several video sources, connect to an electronic whiteboard to be shared for the meeting, start up a web browser to a page relevant to the meeting and set up all the audio paths with everyone but the chairman initially on mute. The Java Applet will also be clever enough to adapt to the different capabilities of the attendees host - for instance someone on a mobile may just have the audio set up, while a full multimedia caller might receive audio, video, data and web references (it is recognised that SDP can provide this type of functionality also - this is merely an example). All the attendee has to do is to accept the incoming call and everything will be set up for them automatically. Alternatively, the attendee may call the conference number, which will then send the Java Applet in the reply. Note that the usual Java and JES security restrictions and authorisations apply so the above will only work if the receiving host has its security set up to allow the required actions from this source, or if the user decides to allow them when prompted. A typical call flow for the case where a user dials the conference number might be: -A user wanting to join a conference call sends a SIP invite message to the conference number from his terminal. -The call is received on the multimedia conferencing system (MCS). -The MCS send an ack message back which includes a Java Applet using the Java enabled SIP constructs. -The users client receives the ack and extracts and runs the Java Applet -The Java Applet queries the exact capabilities of the users SIP client and host machine and initiates SIP sessions for the audio, video and data streams associated with the conference provided that the userÆs client and host can support them (for instance on a mobile - at least the current generation of voice orientated mobiles - the user might just have the audio stream set up as mentioned before). -Depending on how the user has their JES security mechanisms set they may be prompted before the sessions are set up for the various media streams. -Depending on the number of people in the call the SIP calls may be to either a conferencing bridge facility or may simply use a software based conferencing technique to connect the various parties. Simple Hunt group System ------------------------ The example above used only Java applets in the SIP messages. To look at the use of Java Mobile Agents in JES, lets take as a very simple example an application to ring a number of phones within a defined group (such as a team in an office) until one of them answers. The first SIP client receiving the message will after a certain number of rings (having decided that it is not going to be answered) check a predefined default client to forward to, and create a Java Mobile Agent and send it in a SIP message to this client. O'Doherty Internet Draft 7 Java Enhanced SIP Dec 2000 The Java Mobile Agent will apply ringing to the Client it is received and executed by and will also query the ClientÆs details and send these back to the original caller. In addition it will display to the host system of the called Client (if it supports this functionality - i.e. if has a display system associated with it) the information on the call and the fact that it has been forwarded from the first Client. If the new Client does not answer after a certain time, it will check the default Client that has been predefined for that client to forward onto and will send itself in a SIP message to that Client and repeat the above steps, this time with the extra information that it has been forwarded again. After moving through a predetermined number of clients in this manner it will send itself back to the original called client and display or log the route it has taken and the fact that it was not answered. Similarly if the call is answered at a particular client, it will send itself back to the host client and display or log the route it has taken and the fact that a certain client has answered the call. Client test System ------------------ Another example of the use of JES with Java Mobile Agents is a test system for a predefined group of SIP clients. A Java Mobile Agent is created and sent to any of the SIP clients in the group. From there it sets up a number of test sessions and measures and stores in its private data whatever parameters are considered important. It then sends itself to another Client in the group and repeats the process. When it has visited all the clients in the group it sends itself back to the originating Client and reports the results of its tests. It could also initiative other actions to fix and faults it finds as it finds them. Distribution of SIP Clients --------------------------- In this example a SIP client is distributed using Java-enhanced- SIP. Lets say a Client developer wants to be able to distribute a SIP client to upgrade or replace many SIP Clients which all support JES. The software for the SIP client is built into an applet and sent in a SIP message to the all the SIP Clients that the developer wants to either replace or upgrade with the new SIP client. On receipt of the message the existing SIP client will run the applet which will in effect replace the SIP client on that device (how far it actually goes in doing this, for example deleting the old SIP Client will depend on the security interactions and the type of client). This example could be expanded to allow delivery of software updates to any device (or any æthingÆ which has an IP address), not just a SIP Client. It might be worth considering having a specific port number associated with the OA&M system for a given device. A specialised SIP client would listen to this port for O'Doherty Internet Draft 8 Java Enhanced SIP Dec 2000 OA&M communications and set up OA&M related sessions. This would act independently of any standard SIP clients located on that device. Note: the examples above were chosen to illustrate how JES might be used. It is recognized that there are other ways to achieve the same ends in many cases, but the manner in which the functionality is realized is important nonetheless. 7. Intellectual Property This document in part describes intellectual property claimed by Nortel Networks. 8. Acknowledgements The author would like to thank all the people in Nortel Networks who provided input and feedback, in particular Mark Watson who saved the author many hours of background reading and provided many suggestions that have ended up in the document. 9. 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ÆÆ AuthorÆs Address Mick OÆDoherty Nortel Networks Concorde Road Maidenhead Berkshire SL6 4AG England mdoherty@nortelnetworks.com O'Doherty Internet Draft 9