[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

            SDP Extensions for SIP Instant Message 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 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

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on January 11, 2002.

Copyright Notice

   Copyright (C) The Internet Society (2001). All Rights Reserved.


   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

   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 port 5062 using tcp.

        m=message 5060 sip sip:bcampbell@;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@;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@;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.


   [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

Authors' Addresses

   Ben Campbell
   5100 Tennyson Parkway
   Suite 1200
   Plano, TX  75024

   email: bcampbell@dynamicsoft.com

   Jonathan Rosenberg
   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

   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


   Funding for the RFC editor function is currently provided by the
   Internet Society.

Campbell & Rosenberg    Expires January 11, 2002                [Page 7]

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