[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00

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: &ltsip: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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/