Internet Engineering Task Force B. Campbell Internet-Draft J. Rosenberg Expires: January 11, 2002 dynamicsoft July 13, 2001 SIP Instant Message Sessions draft-ietf-simple-im-session-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 The current specification for the SIP MESSAGE request method indicates that SIP instant messages according to a model similar to that of a text pager, in that each message stands alone. There is no concept of a chat session or a text conference where there is a stream of messages that are grouped into a session. This memo proposes a method of describing MESSAGE sessions by treating the message session just like any other media session described in an SDP body in an INVITE request. Campbell & Rosenberg Expires January 11, 2002 [Page 1] Internet-Draft SIP IM Sessions July 2001 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of Operation . . . . . . . . . . . . . . . . . . . . 4 4. User Agent Client Behavior . . . . . . . . . . . . . . . . . . 5 5. User Agent Server Behavior . . . . . . . . . . . . . . . . . . 6 6. Nature of MESSAGE sessions . . . . . . . . . . . . . . . . . . 6 7. Ending Message Sessions . . . . . . . . . . . . . . . . . . . 7 8. Identifying Sessions . . . . . . . . . . . . . . . . . . . . . 7 9. Message Sessions over SIP Proxies . . . . . . . . . . . . . . 7 10. Security Considerations . . . . . . . . . . . . . . . . . . . 8 11. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 9 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 10 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 12 Campbell & Rosenberg Expires January 11, 2002 [Page 2] Internet-Draft SIP IM Sessions 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 is not linked 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. This document proposes 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. In this approach, a SIP endpoint that wishes to initiate a text chat session would send an INVITE request with an SDP body that describes the session [2]. The sender and recipient then negotiate MESSAGE sessions using normal SIP conventions. 2. Motivation The SIP MESSAGE request method [3] does not create a session. Each MESSAGE request/response exchange fully stands alone, and is not affected by previous exchanges. This is a perfectly good model for many uses of instant messages, such as SMS messages to wireless devices, etc. This document in no way deprecates the stand-alone model of instant messaging, as a session concept is an undue burden for a single message. However, many Instant Message applications support the concept of a message session in the form of a conference or a chat room, in which two (or commonly more) users hold a conversation that is displayed as a coherent whole. The stand-alone model has a number of limitations. It only supports multi-party messaging in very clumsy ways, while using INVITE to establish a session allows reuse of the various multi-party conferencing models supported by SIP[5]. The stand-alone model by necessity causes MESSAGE requests to follow the SIP signal path, which is intended to manage sessions, not transfer content. Forking of MESSAGE requests does not work well either. The sender will not know how many recipients have gotten the message. The sender will not be able to select one of those recipients as the target for future messages. These problems are resolved by establishing a session with INVITE. In that case, the caller does know who has received the session invitation, and can select which recipient(s) to communicate with. Finally, MESSAGE sessions treated as a normal media stream allow us to combine MESSAGE streams with other types of media. For example, Campbell & Rosenberg Expires January 11, 2002 [Page 3] Internet-Draft SIP IM Sessions July 2001 one could establish a conference call with a text sub-channel, or send closed captioning along with a video stream. 3. Overview of Operation Let us imagine a SIP endpoint Alice, which wishes to initiate a chat session with Bob. Alice constructs an INVITE request with an SDP body, and includes the following line in the SDP:[4] m=message 5060 sip sip:alice@alicepc Bob's UAS receives the INVITE, and responds with a 200 OK containing the following SDP line: m=message 5061 sip sip:bob@bobpda:5061 Finally, Alice follows up with an ACK request. At this point, Alice and Bob can each send MESSAGE requests directly to the other. Note that each direction is an independent media stream, and will have a distinct combination of To, From, and Call-ID headers, as well as distinct CSeq spaces. Additionally, the To, From, and Call-ID headers and CSeq spaces are independent from those of the signaling session. The following call flow illustrates the basic message session model, where the signal path goes through a record-routing proxy, but the message session path is end-to-end. Campbell & Rosenberg Expires January 11, 2002 [Page 4] Internet-Draft SIP IM Sessions July 2001 ______ _______ _______ | Alice| | Proxy | | Bob | | | | | | | ------ ------- ------- | | | |--------INVITE---------->| | | |---------INVITE--------->| | |<-----F3 200 OK----------| |--------ACK ------------>| | | |---------ACK------------>| |-------------------MESSAGE-(Call leg A)----------->| |<------------------200 OK--------------------------| | | | |<------------------MESSAGE-(Call leg B)------------| |-------------------200 OK------------------------->| | | | }---------BYE------------>| | | |----------BYE----------->| 4. User Agent Client Behavior A UAC wishing to initiate a MESSAGE session MUST construct and INVITE request. The headers of the INVITE must be generated according to the normal rules of SIP [1]. The methods for negotiating the MESSAGE streams is the same as for SIP in general, except that the The UAC MUST include an SDP body in the INVITE containing the description of the desired inbound MESSAGE session, i.e. the URL at which it would like to receive MESSAGE requests as part of this session. The SDP format for describing SIP message sessions is described in the SIP Message SDP draft [2] This is different than in general SIP which allows the UAC to defer proposing its media selection until the ACK request. It is tempting to allow the UAC to defer the media specification, so that the SDP is carried in the 200 class response and the ACK request, instead of in the INVITE request and the 200 class response. This would be useful for 3PCC style applications. However, if the UAC omits the media description for the MESSAGE session, there is a high likelyhood that the UAS will not propose a message media type in the 200 response. There is still a possibility for the UAC to accept a non-text media type proposed by the UAS, but it will no longer be possible to accomplish the original goal, i.e. establish a MESSAGE session. The UAC MUST be prepared to receive MESSAGE requests to its proposed URL prior to the completion of the INVITE transaction; that is, before receiving a 200 class response or sending an ACK request. Campbell & Rosenberg Expires January 11, 2002 [Page 5] Internet-Draft SIP IM Sessions July 2001 5. User Agent Server Behavior A UAS that receives an INVITE containing an SDP description handles media negotiation according to the normal rules of SIP[1] Since the message media type does not have a concept of codecs, negotiation of message media sections is considerably more simple than for RTP media sections. The UAS must be prepared to receive MESSAGE request to its proposed URL prior to the completion of the INVITE transaction; that is, before receiving an ACK request. 6. Nature of MESSAGE sessions A MESSAGE session takes the form of a SIP call-leg, and is identified in the same way as general SIP call legs. A message session is peculiar in the fact that each call-leg is one way only. A two-way chat between two SIP endpoints contains two call legs; one in each direction. Each endpoint may send MESSAGE requests to the URL that was advertised in the opposite end-points SDP. An endpoint MUST NOT send any request other than MESSAGE on a message session call leg, and it MUST NOT violate the directionality of the call-leg; that is to say it SHOULD respond to MESSAGE requests sent to it, but it MUST NOT attempt to send MESSAGE request back along the same call leg. If an endpoint receives a request that violates directionality, it SHOULD respond with a 481, as if the call leg never existed. If an endpoint receives a request with a method other than MESSAGE it SHOULD respond with a 405. When a UAC sends a MESSAGE request on a session, it MUST set the Request-URI to the URL specified in its opposite's SDP, and send the request according to normal SIP rules for resolving a Request-URI. If the supplied URL contains headers, the UAC MUST include those headers in its MESSAGE request.One exception is CSeq; if the URL included a CSeq header, the UAC SHOULD ignore it, and generate its initial CSeq normally. The UAC MUST repeat this process for each MESSAGE requests it sends, following normal SIP rules for sending requests on a call-leg. Note that since MESSAGE requests and their responses will not contain CONTACT headers, each MESSAGE request on a call leg MUST be sent along the same path as the initial request. A MESSAGE request MUST include a pre-loaded route set if the advertised URL containted ROUTE headers. The MESSAGE method is specified to have no session semantics into itself. In particular,a proxy should not insert a Record-Route header into a MESSAGE request[3]. To do would have no meaning. Campbell & Rosenberg Expires January 11, 2002 [Page 6] Internet-Draft SIP IM Sessions July 2001 Even though the MESSAGE request may occur in the context of a message session, they may go through a proxy that has no knowledge of the session, and will treat each request as a stand-alone MESSAGE. If that proxy needs to stay in the MESSAGE path for one reason or another (for example, it is a firewall proxy) it cannot use Record-Route to accomplish this. If subsequent MESSAGE requests went to the URL in a Contact header, it would not be possible for the proxy to stay in the path. MESSAGE requests inside a message session MUST NOT overlap. That is, when the UAC sends one MESSAGE request, it may not send another until the first transaction has completed. 7. Ending Message Sessions Under normal conditions, SIP endpoints use the BYE request on the signal channel to end a message session just like they would with any other session. If the session is bi-directional, that is, consists of two unidirectional session call legs, the BYE request tears down both call-legs. And endpoint MUST not attempt to send the bye in the message session itself. If a UACs attempt to send a MESSAGE request fails, either do to a negative responsd from the UAS or a timeout waiting for a response, it should behave as it would for any other media stream failure. 8. Identifying Sessions A SIP endpoint MUST advertise a URL which allows it to determine which call legt an incoming message is for. It can do that by embedding a Call-ID header in the URL, or by using a special user name unique to the call leg. 9. Message Sessions over SIP Proxies In a perfect world, all message sessions would be end-to-end. In this case, end-to-end refers to the scenario where the URL advertised by each endpoint directly maps to the endpoint itself. In reality, there are situations where message sessions may need to cross SIP proxies. For example, an endpoint may wish to conceal its address, or may be behind a firewall where all traffic must go through a particular proxy. In the simplest proxy case, the endpoint merely advertises a URL to a proxy that knows how to route MESSAGE requests to the desired endpoints. For example, a the endpoint might send the following registration: Campbell & Rosenberg Expires January 11, 2002 [Page 7] Internet-Draft SIP IM Sessions July 2001 REGISTER sip:biloxi.com SIP/2.0 Via: SIP/2.0/UDP bobpda.biloxi.com From: <sip:bob@biloxi.com>;tag=23qk To: sip:bob@biloxi.com Call-ID:739421@bobpda.biloxi.com CSeq: 13 REGISTER Contact: sip:bob@bobpda.biloxi.com; methods=MESSAGE Expires: 600 Then the endpoint could send an invite where the SDP contained sip:bob@biloxi.com. In this case, all MESSAGE requests sent on the session would transverse the proxy. Another approach is to place a pre-loaded route header directly to the advertised URL. For example, Alice might include the following m-line in the body of the INVITE she sent to Bob: m=message 5060 sip sip:alice@atlanta.com?Route=sip:alicepc.atlanta.com&Call-ID=34reid2jk@alicepc.atlanta.com Bob then sends each MESSAGE request to the proxy at sip:atlanta.com with a pre-loaded route header instructing the proxy to route the request to sip:alicepc.atlanta.com. And endpoint may also need to route MESSAGE requests through a default outbound proxy, regardless of whether they are in-session or stand-alone. Since each request follows the same path as the initial request this will work without a problem. It is interesting to note that the default outbound proxy will stay in the message session path even if it does not request Record-Routing. 10. Security Considerations Message sessions have all of the same security considerations as any other media type used with SIP sessions. A primary issue is the exposure of end-point addresses to the opposite end-point (and anything in between.) This is slightly mitigated with message sessions, as an intervening proxy may be used to hide the end-point address. The deprecation of Contact headers in MESSAGE transactions also mitigates that issue slightly. Another issue is the possibility that a rogue endpoint could establish a message session in the absence of an INVITE transaction by simply guessing the URL to which to send messages. This opportunity is reduced if the endpoints add difficult to guess Call-ID headers into the URLs advertised in their SDP, and only accept MESSAGES with a matching call ID. Still, an attacker could Campbell & Rosenberg Expires January 11, 2002 [Page 8] Internet-Draft SIP IM Sessions July 2001 sniff the network and capture the Call-ID if the INVITE transaction is transmitted in the clear. Note that this problem is much worse for audio media streams since they only have 64k ports to guess from, while Call-ID space is effectively infinite. An endpoint may apply any of the general SIP authentication methods to message sessions. 11. Open Issues We assert that all requests in a message session must follow the same path as the initial MESSAGE request. But what if we encounter a redirect server? It seems inefficient to require each request to individually get redirected, instead of remembering the contact from the redirect server. The inability for a proxy to Record-Route a MESSAGE request causes some ugliness. Since we are then forced to send all request via the same path as the original MESSAGE, we make it impossible for a proxy to _not_ stay in the message session path. At the same point in time, it would be really ugly to have different semantics for MESSAGE requests depending on whether they were in-session or stand-alone. Another point that came up on the list is we need a way to tell and endpoint to route messages along the signal path. This draft does not address that problem. It might be possible to simply leave the URL out of the m-line, and have endpoints recognize that to mean to use the signal path. I am not confident enough in that approach to propose it in the main body of this draft. Does this draft need to discuss negotiating what mime-types are permitted in the bodies of in-session MESSAGE requests? This approach handles forking of the INVITE transaction just fine. But what if the message session itself crosses a forking proxy? Each subsequent request in the call leg will also fork. Is this a problem? Robert brought up a concern about the performance of message sessions, since we cannot overlap MESSAGE transactions in a call-leg. The fact that each call-leg is one-way helps this a little, but it is still sub-optimal. Do we need to make special considerations for message sessions over TLS? We have effectively introduced the idea of SIP call leg nesting. Should this be generalized? Campbell & Rosenberg Expires January 11, 2002 [Page 9] Internet-Draft SIP IM Sessions July 2001 12. 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] Campbell, B. and J. Rosenberg, "SDP Extensions for SIP Instant Message Sessions", internet-draft draft-ietf-simple-im-sdp-00.txt, July 2001. [3] Rosenberg, J. , Willis, D. , Rosenberg, J. , Sparks, R. , Campbell, B. , Schulzrinne, H. , Lennox, J. , Huitema, C. , Aboba, B. , Gurle, D. and D. Oran, "SIP Extensions for Instant Messaging", draft-ietf-simple-im-01.txt (work in progress), July 2001. [4] Handley, M. and V Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [5] Rosenberg, J. and H. Schulzrinne, "Models for Multi Party Conferencing in SIP", draft-rosenberg-sip-conferencing-models-00.txt (work in progress), November 2000. Authors' Addresses Ben Campbell dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 email: bcampbell@dynamicsoft.com Campbell & Rosenberg Expires January 11, 2002 [Page 10] Internet-Draft SIP IM Sessions July 2001 Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 email: jdrosen@dynamicsoft.com Campbell & Rosenberg Expires January 11, 2002 [Page 11] Internet-Draft SIP IM Sessions 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 12]