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]