Internet Engineering Task Force SIMPLE WG Internet Draft J.Rosenberg dynamicsoft draft-rosenberg-simple-message-session-00.txt May 2, 2002 Expires: November 2002 Using MESSAGE for IM Sessions 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 To view the list Internet-Draft Shadow Directories, see http://www.ietf.org/shadow.html. Abstract The SIMPLE working group has been debating the issue of the IM session model for quite some time. The primary issue is what transport to use for the IMs once the session is established with SIP. Proposals have included the SIP MESSAGE request itself, IMSX, and a SIP spin-off, called IMTP. The usage of SIP MESSAGE, the very first proposal, had been rejected by the group because of several technical issues. This document revists that decision, based on the recent enhancements made to SIP itself. We believe that SIP MESSAGE now represents the ideal transport choice for the IM session model. J.Rosenberg [Page 1] Internet Draft MESSAGE sessions May 2, 2002 Table of Contents 1 Introduction ........................................ 3 2 History ............................................. 3 3 Proposal ............................................ 5 4 Benefits ............................................ 7 5 Example ............................................. 8 6 The Bigger Picture .................................. 8 7 Author's Addresses .................................. 9 8 Normative References ................................ 9 9 Informative References .............................. 9 J.Rosenberg [Page 2] Internet Draft MESSAGE sessions May 2, 2002 1 Introduction Within the SIMPLE group, two models of IM operation are under discussion. One is the "paging" model of operation [1]. In this mode, each IM is sent as an independent message using the SIP MESSAGE method. There is no setup or session establishment needed to send a message. There is no notion of a session or persistent conversation. The paging model mimicks the operation of SMS in wireless networks today. The second model of operation is the "session" model. In this model, the IM traffic is viewed as a "media stream" which is part of a session established with SIP. Before communication, a SIP INVITE would be used to set up the session [2], and the IM stream would be described using the SDP [3] carried in that INVITE. When the communications are terminated, a BYE would be sent. The session model offers many advantages, mainly in the ability to apply many other SIP extensions, such as third party call control [4], multiparty conferencing [5], and preconditions [6] to IM in the same way they would be applied to voice or video calls. The missing piece of the session model is this: what transport is to be used to carry the IMs? Is it RTP [7]? Is it the SIP MESSAGE method? This subject has been the source of much debate. In this document, we review this history of this problem, focusing on the initial proposal of the MESSAGE request, followed by the compromise IMTP protocol. Then, we propose a MESSAGE solution that uses loose routing, and show how it solves the problems with the prior two proposals. We then give some call flow examples. 2 History When the initial concept of the IM session model was proposed, the MESSAGE method was the assumed transport for IMs within the session. The SDP in the INVITE and in the 200 OK would contain a URI for sending the IM. This URI would generally be a contact URI for each endpoint, but could also be an address of record, or contain a series of route headers as URI parameters, learned from record-route, for example. After some investigation, problems were found with this approach. The problems were: Forking: Since the MESSAGE was sent as a regular SIP request, there was nothing that could prevent a proxy from forking this request. Forking an IM in the session model didn't make sense. The IM should clearly be delivered to the peer in then session, and no one else. J.Rosenberg [Page 3] Internet Draft MESSAGE sessions May 2, 2002 Redirection: There was no clear way to prevent a session MESSAGE from getting redirected. This could prevent it from being delivered to the session peer. Record-Routing: Could the MESSAGE requests themselves be record-routed? Would such a route override the original route that the request used? Separate Paths: There was a strong desire to decouple the path of proxies used for the signaling, from those possibly used as intermediaries for the MESSAGE requests comprising the session. It was not clear how to accomplish this goal with the proposal. Congestion Control: There was general agreement that IMs in the session model should use congestion control. This implies end-to-end TCP. However, a regular SIP request will normally use UDP. There was no clear way to prevent a MESSAGE request within a session from traversing a UDP hop. However, despite these drawbacks, there were clear benefits to using MESSAGE. Proxies could serve as useful intermediaries, providing a solution for firewall and NAT traversal. It would allow a unified treatment of the page and session modes, which was desirable. It provided much of the features that were needed - MIME carriage, sender and recipient identification, and subject and date headers, for example. The general observation was that SIP MESSAGE provided the necessary features, but SIP itself was too feature rich. It had capabilities, such as forking, redirection and record-routing, which appeared to get in the way of proper operation in the session model. This led to a compromise proposal - the IM Transport Protocol (IMTP) [8]. This protocol was a proper subset of SIP, but with lots of features removed. There was only TCP, for example. Forking, redirection, and record-routing were removed. This meant that IMTP had the benefits of MESSAGE for the session model (unified page/session treatment, and the ability to use proxies for intermediaries), but without the drawbacks above, since the unneeded features were removed. Proxies could be used as IMTP intermediaries if properly configured (record-routing turned off, TCP only, etc.). However, IMTP had some problems of its own. First, since it was a separate protocol, the protocol name in the requests was changed from SIP/2.0 to IMTP/1.0. This meant that there would be interop problems if a SIP proxy was to play the role of an IMTP intermediary. If the name SIP/2.0 was retained, we might not be able to guarantee that the J.Rosenberg [Page 4] Internet Draft MESSAGE sessions May 2, 2002 appropriate configuration was being used. The most serious problem was that it was undesirable to have a separate specification that was "almost SIP". What would happen if these were inconsistent? How would it evolve as SIP went to draft? Additional proposals were sought. The BEEP community contributed the IMSX protocol [9]. There was some concern at IETF 53 that IMSX replicated many of the negotiation features of SIP itself. 3 Proposal We have observed that a lot has changed in the SIP protocol since the original MESSAGE proposal was made. The most important change is the loose routing capabilities which have been added to SIP. It is our belief that these capabilities, properly utilized, make the usage of the MESSAGE request as an IM transport in the session model viable once more. The approach is straightforward. When a UAC wishes to initiate an IM session, it sends a standard SIP INVITE. The SDP in the body indicates a stream of type message, with a transport of SIP. The c line and port fields of the SDP provide the address to where the IMs should be sent on the UAC. There is also a new "user" SDP attribute, which provides additional addressing. Effectively, the combination of the c line, m line port, and the "user" attribute, are used to create a SIP URI that identifies the UA where IM requests are to be sent. An example INVITE would look like: INVITE sip:callee@example.com SIP/2.0 Content-Type: application/sdp Content-Length: ... v=0 o=bob 2890844730 2890844732 IN IP4 host.example.com s= c=IN IP4 host.example.com t=0 0 m=message 54344 SIP/TCP a=user:bob The INVITE is processed normally by proxies. However, some proxy on the path might decide that the messaging stream needs to pass through an intermediary. To do that, it modifies the SDP, adding a "hop" attribute, containing a SIP URI for the hop. This URI need not be the URI of the proxy at all, but MUST always have a transport of TCP. J.Rosenberg [Page 5] Internet Draft MESSAGE sessions May 2, 2002 Furthermore, the proxy that inserts this URI need not record-route. An example of a MESSAGE request modified in this fashion is: INVITE sip:callee@example.com SIP/2.0 Content-Type: application/sdp Content-Length: ... v=0 o=bob 2890844730 2890844732 IN IP4 host.example.com s= c=IN IP4 host.example.com t=0 0 m=message 54344 SIP a=user:bob a=hop:sip:relay.example.com;transport=tcp;lr In this case, the proxy has requested that the MESSAGE requests flow through sip:relay.example.com. These hop attributes can be added by each proxy that the request passes through. New hops are added on top of the existing set. A proxy could even insert multiple hop attributes. When the request arrives at the UAS, the UAS sends a 200 OK as normal. This 200 OK would have an SDP structured identically to the SDP in the INVITE. Proxies along the path of the 200 OK could insert hop attributes, as they did for the INVITE. The result is that both the UAC and UAS will learn, through the SDP, the address of the ultimate recipient (from the user, m, and c lines), along with URI of hops along the way that must be traversed. Both UAC and UAS will then construct a route set from the hop headers, and use that to populate a Route set in MESSAGE requests sent within the session. The request URI is constructed from the user attribute, m, and c lines of the SDP, and thus points to the ultimate recipient. As an example, if the INVITE fragment above were received by the UAS, an IM sent to the caller might look like, in part: MESSAGE sip:bob@host.example.com:54344;transport=tcp SIP/2.0 Route: sip:relay.example.com;transport=tcp;transport=tcp;lr Content-Type: text/plain Content-Length: ... Hey! J.Rosenberg [Page 6] Internet Draft MESSAGE sessions May 2, 2002 Based on the loose routing techniques of bis, this request would first visit sip:relay.example.com, which would strip that Route header before sending it on to sip:bob@host.example.com. 4 Benefits We believe our proposal resolves all of the identified problems with the original MESSAGE approach: Forking: In bis, it is clearly stated that the location service cannot be executed if the proxy does not have control over the domain in the request URI. In the MESSAGE requests above, the domain in the request URI is that provided by the UA in fields of the SDP. This will either be the IP address of their host, or their FQDN. No proxy owns that domain, only the UA does. Forking can only occur when the location service is executed. Therefore, the request will never fork through any bis compliant proxy. Redirection: This will never occur either, for the same reason that forking will never occur. Record-Routing: Record-routes from the MESSAGE, if present, are always ignored. The route for the MESSAGE requests is learned from the SDP. Separate Paths: The path of subsequent SIP requests in the dialog is determined from the record-route headers. The path of MESSAGE requests in the IM session is determined from the hop headers in the SDP. These are unrelated. Thus, the two paths are completely independent. Congestion Control: Proxies are forced by the specification to place URI in the "hop" attribute that indicates a congestion controlled transport. Furthermore, a UA would construct the route set using the transport=tcp parameter if none was provided in the hop attribute. This means that, in order for the MESSAGE path to use a non-congestion controlled hop, BOTH a UA and a proxy would need to be misimplemented or conspire to violate the spec. Additionally, this proposal does not define a new protocol. It merely defines some new SDP attributes that enable a particular usage of the MESSAGE request for session model. Thus, there are no issues with diversion of specifications, as there were with IMTP. There are also no interoperability issues beyond bis, or the potential for problems in the face of misconfiguration. J.Rosenberg [Page 7] Internet Draft MESSAGE sessions May 2, 2002 An even bigger benefit is the elimination of state. In the IMTP proposal, the proxy needed to install forwarding state in the relay, through a REGISTER request. Now, such state is no longer needed. The forwarding state is encapsulated in the loose Route headers stored by the UA. This avoids the fate sharing problem of the IMTP approach. 5 Example Figure 1 provides a more detailed call flow example. In step 1, the caller sends an INVITE to its proxy. The SDP indicates a message session. The c line provides an IP address of 1.2.3.4, and the m line provides a port of 54344. We ignore the user attribute for simplicity's sake. The proxy doesn't record route, but adds a hop header with the SIP URI of "sip:relay". The explicit transport=tcp has also been omitted for clarity. This reques is forwarded to the UAS, which answers. The 200 OK from the client indicates an IP address of 4.3.2.1:44345 in the c and m lines. The proxy once again inserts a hop header pointing to the same relay. When the callee sends a MESSAGE, it uses a request URI of "sip:1.2.3.4:54344;transport=tcp" and a Route header of "sip:relay;transport=tcp". Based on bis routing rules, this gets sent to the relay. The relay pops its route, and then forwards to the ultimate recipient. The message flow in the reverse direction is similar. When the caller hangs up, the BYE goes directly from the caller to callee. This is because the proxy didn't record route. As the example shows, there is no relationship between the MESSAGE path and the SIP path. 6 The Bigger Picture The usage of the "hop" attribute in the SDP has some problems. It requires proxies to violate the SIP specification. Proxies are, for good reason, forbidden from modifying the contents of bodies in SIP messages. Adding the hop attribute requires proxies to perform a modification of the body. The hop attribute is also specific to the IM session concept. However, insertion of media intermediaries is a problem for messages, voice, and video alike. Therefore, we have developed an alternative model that attempts to solve the problem more broadly [10]. Readers are referred to that document for more detail. We do not propose that this mechanism be used for the initial IM session specification. This is principally for reasons of timing. The above draft would need to first become a requirements RFC in sipping, and then move on to a protocol extension in SIP, all assuming it is accepted. This would delay the message session drafts by too much J.Rosenberg [Page 8] Internet Draft MESSAGE sessions May 2, 2002 time. We would rather specify the SDP approach here, and migrate to the right thing if and when it becomes available. 7 Author's Addresses Jonathan Rosenberg dynamicsoft 72 Eagle Rock Avenue First Floor East Hanover, NJ 07936 email: jdrosen@dynamicsoft.com 8 Normative References [1] J. Rosenberg et al. , "SIP extensions for instant messaging," Internet Draft, Internet Engineering Task Force, July 2001. Work in progress. [2] J. Rosenberg, H. Schulzrinne, et al. , "SIP: Session initiation protocol," Internet Draft, Internet Engineering Task Force, Feb. 2002. Work in progress. [3] M. Handley and V. Jacobson, "SDP: session description protocol," RFC 2327, Internet Engineering Task Force, Apr. 1998. 9 Informative References [4] J. Rosenberg, J. Peterson, H. Schulzrinne, and G. Camarillo, "Third party call control in SIP," Internet Draft, Internet Engineering Task Force, Nov. 2001. Work in progress. [5] J. Rosenberg and H. Schulzrinne, "Models for multi party conferencing in SIP," Internet Draft, Internet Engineering Task Force, Nov. 2001. Work in progress. [6] W. Marshall, G. Camarillo, and J. Rosenberg, "Integration of resource management and SIP," Internet Draft, Internet Engineering Task Force, Apr. 2002. Work in progress. [7] H. Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: a transport protocol for real-time applications," RFC 1889, Internet Engineering Task Force, Jan. 1996. [8] J. Rosenberg et al. , "A proposal for IM transport," Internet Draft, Internet Engineering Task Force, Nov. 2001. Work in progress. J.Rosenberg [Page 9] Internet Draft MESSAGE sessions May 2, 2002 Caller Proxy Relay Callee |(1) INVITE | | | |m=54344 | | | |c=1.2.3.4 | | | |------------------>|(2) INVITE | | | |m=54344 | | | |c=1.2.3.4 | | | |hop=sip:relay | | | |-------------------------------------->| | |(3) 200 OK | | | |m=44345 | | | |c=4.3.2.1 | | |(4) 200 OK |<--------------------------------------| |m=44345 | | | |c=4.3.2.1 | | | |hop=sip:relay | | | |<------------------| | | |(5) ACK | | | |---------------------------------------------------------->| | | |(6) MESSAGE | | | |ruri=1.2.3.4:54344 | | | |Route=sip:relay | | | |<------------------| |(7) MESSAGE | | | |ruri=1.2.3.4:54344 | | | |<--------------------------------------| | |(8) 200 OK | | | |-------------------------------------->| | | | |(9) 200 OK | | | |------------------>| |(10) MESSAGE | | | |ruri=4.3.2.1:44345 | | | |Route=sip:relay | | | |-------------------------------------->| | | | |(11) MESSAGE | | | |ruri=4.3.2.1:44345 | | | |------------------>| | | |(12) 200 OK | | | |<------------------| |(13) 200 OK | | | |<--------------------------------------| | |(14) BYE | | | |---------------------------------------------------------->| |(15) 200 OK | | | |<----------------------------------------------------------| Figure 1: Call Flow Example J.Rosenberg [Page 10] Internet Draft MESSAGE sessions May 2, 2002 [9] M. Rose, "Im simple exchange (imsx)," Internet Draft, Internet Engineering Task Force, Dec. 2001. Work in progress. [10] J. Rosenberg, "Supporting intermediary session policies in sip," Internet Draft, Internet Engineering Task Force, May 2002. Work in progress. Full Copyright Statement Copyright (c) The Internet Society (2002). 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. The IETF has been notified of intellectual property rights claimed in regard to some or all of the specification contained in this document. For more information consult the online list of claimed rights. J.Rosenberg [Page 11]