Internet Engineering Task Force B. Campbell Internet-Draft J. Rosenberg Expires: January 11, 2002 dynamicsoft July 13, 2001 SDP Extensions for SIP Instant Message Sessions draft-ietf-simple-im-sdp-00 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. This Internet-Draft will expire on January 11, 2002. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract SIP instant messages currently follow a pager model, where there is no concept of a message session. It has been proposed that we also need a session based model, where the user experience would be more like a text conference or chat room. This draft proposes an extension to SDP that could be used to describe message sessions. Campbell & Rosenberg Expires January 11, 2002 [Page 1] Internet-Draft SIP IM SDP Extensions July 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. The message media type . . . . . . . . . . . . . . . . . . . . . 3 3. Interpreting the m-line . . . . . . . . . . . . . . . . . . . . 3 4. Interpreting the SIP URL . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 7. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 5 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . 7 Campbell & Rosenberg Expires January 11, 2002 [Page 2] Internet-Draft SIP IM SDP Extensions July 2001 1. Introduction The SIP MESSAGE method does not currently support any sense of a session. Instant messages sent using this method are treated like pager messages; each message stands alone and are not linked together into a conversation. There has been recent interest in the idea of a SIP based instant message session, where the user experience is more akin to a a text conference or a chat room. One proposed approach to that end is the idea of treating SIP instant message sessions as a media type that can be initiated using the same SIP mechanisms as for any other media type. This approach requires extensions to SDP [2] to allow the description of a session of SIP instant messages. This memo proposes a media type of "message" for this purpose. This memo does not describe the semantics of SIP instant message sessions beyond what is needed to illuminate the SDP extension. SIP instant message session semantics are defined in a separate document[3]. 2. The message media type The "message" media type is a new SDP m-line media type descriptor. An SDP m-line takes the following form: m=media port[/number_of_ports] transport format_list In a SDP description of an instant message session, media MUST be "message". Port SHOULD be the port number on which the instant messages will be received. (This is for human readability only, the actual receive port will be specified in the URL.) Number_of_ports SHOULD NOT be present. If the message session is to consist of SIP MESSAGE requests, then the transport MUST be "sip", and format_list MUST contain a single SIP URL. For example: m=message 5060 sip sip:bcampbell@dynamicsoft.com The SIP URL in the format list field MAY contain any legal SIP URL component, as defined in [1]. This may include URL parameters or header parameters. Please note that use of the message media type on an m-line does not absolve one from including all the lines normally required by SDP. However, since message is not an RTP format, the use of rtpmap attributes as recommended in [1] does not apply. 3. Interpreting the m-line When a SIP endpoint receives a request with a media type of "message" and transport of "sip", it MAY elect to participate in the Campbell & Rosenberg Expires January 11, 2002 [Page 3] Internet-Draft SIP IM SDP Extensions July 2001 message session. A SIP endpoint that does not support the message media type MUST treat it in the same way it would treat any other unsupported media types. It is tempting to allow the recipient to ignore the transport field. If the media field is "message" then we know the transport, right? But there is no reason to limit the message media type to just SIP instant messages. It is not only possible but reasonably probable that someone will eventually define additional transports that may be used with the message media type. The recipient MUST ignore the port field, and instead depend on the port information in the SIP URI, following normal rules as defined in [1]. 4. Interpreting the SIP URL All information about where and how to send MESSAGE requests in the instant message session comes from the SIP URL in the format_list field. In particular, the recipient MUST determine the port and transport to which it should send MESSAGE requests from the URL, not the port and transport fields of the m-line. The recipient MUST follow normal SIP URL interpretation rules as defined in [1]. For example, the following m-line means the recipient may send SIP MESSAGE request to 192.168.1.23 port 5062 using tcp. m=message 5060 sip sip:bcampbell@192.168.1.23:5062;transport=tcp When a user receives an SDP containing a "message" media stream with SIP transport, this indicates that a messaging stream is to be established. The recipient of the SDP uses the SIP URL in the SDP for all messages sent on the stream. This allows the recipient of the messages to correlate them together. The URL in the SDP SHOULD be sufficient for the recipient to uniquely identify a message stream. This can be done by choosing a sufficiently unique username: m=message 5060 sip sip:bcampbell_stream8837@192.168.1.23:5060;transport=tcp Alternatively, the URL can contain URL parameters for setting the Call-ID, which can be used to provide uniqueness: m=message 5060 sip sip:bcampbell@192.168.1.23:5060;transport=tcp?Call-ID=98776565 It is anticipated that the URL will frequently contain Route header URL parameters. These are useful to establish a specific route for the messages, primarily for firewall and nat traversal. Campbell & Rosenberg Expires January 11, 2002 [Page 4] Internet-Draft SIP IM SDP Extensions July 2001 If the URL does not contain a Call-ID, one is chosen by the recipient of the SDP. The same Call-ID MUST be used for all messages generated within the stream. Furthermore, each MESSAGE MUST have an increasing CSeq value. 5. IANA Considerations The SDP media type of "message" and the transport type of "sip" will require IANA registration. 6. Security Considerations The usage of a SIP URL in the SDP m-line may reveal an IP address or host name. This issue is further explored in the SIP Instant Message Session document[3] 7. Open Issues This draft only allows for one URL in an m-line. Might there be utility in allowing multiple URLs in the same m-line? This approach puts addressing information in the m-line. One could make a case that this in an incorrect use of SDP, which normally keeps addressing information in c-lines. However, the c-line format does not allow for specifying the address in a URL format. Do we need a way of specifying allowed MIME types for MESSAGE bodies? It has been proposed we need a way to signal "send MESSAGE requests along the signal path." One possibility might be to leave the URL out of the m-line entirely. I am not confident enough in that approach yet to put it in the main body of this draft. 8. Acknowledgments This document is a compilation of the thoughts of many people on the SIMPLE mail list. In particular, the authors thank the following for their contributions: Christian Heitema, Sean Olson, Adam Roach, Robert Sparks, Henning Schulzrinne, and James Undery. References [1] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", draft-ietf-sip-rfc2543bis-03.txt (work in progress), May 2001. [2] Handley, M. and V Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. Campbell & Rosenberg Expires January 11, 2002 [Page 5] Internet-Draft SIP IM SDP Extensions July 2001 [3] Campbell, B. and J. Rosenberg, "SIP Instant Message Sessions", draft-ietf-simple-im-session-00.txt (work in progress), July 2001. Authors' Addresses Ben Campbell dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 email: bcampbell@dynamicsoft.com Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 email: jdrosen@dynamicsoft.com Campbell & Rosenberg Expires January 11, 2002 [Page 6] Internet-Draft SIP IM SDP Extensions July 2001 Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Campbell & Rosenberg Expires January 11, 2002 [Page 7]