One document matched: draft-jennings-sipping-multipart-00.txt
SIP C. Jennings
Internet-Draft Cisco Systems
Expires: August 12, 2005 February 11, 2005
SIP Offer/Answer with Multipart MIME
draft-jennings-sipping-multipart-00
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with
RFC 3668.
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 August 12, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document addresses the issues around using multipart with the
SIP offer/answer framework. It specifies a way to make an offer with
a multipart/alternative MIME body and for the answer to indicate
which of the parts was selected for the answer. This is needed for
general backwards compatibility to allow migration in situations such
as moving from SDP to SDPng or moving from non end-to-end encrypted
SDP to encrypted SDP.
Jennings Expires August 12, 2005 [Page 1]
Internet-Draft SIP Multipart February 2005
Table of Contents
1. Introduction and Overview . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Sending Offers . . . . . . . . . . . . . . . . . . . . . . 3
3.2 Receiving Offers and Sending Answers . . . . . . . . . . . 3
3.3 Receiving Answers . . . . . . . . . . . . . . . . . . . . 4
4. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Multipart Outside of Offer/Answer . . . . . . . . . . . . . . 4
6. Example SIP SRTP Call . . . . . . . . . . . . . . . . . . . . 4
7. Security considerations . . . . . . . . . . . . . . . . . . . 6
8. IANA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
10.1 Normative References . . . . . . . . . . . . . . . . . . . . 6
10.2 Informational References . . . . . . . . . . . . . . . . . . 6
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 7
Intellectual Property and Copyright Statements . . . . . . . . 8
Jennings Expires August 12, 2005 [Page 2]
Internet-Draft SIP Multipart February 2005
1. Introduction and Overview
SIP (RFC 3261 [5]) uses an offer/answer negotiation mechanism
described in [1]. This system carries offers in formats such as SDP
[6] and various signed and encrypted versions of SDP. However, the
current offer/answer scheme does not allow a backwards compatibility
mode in which a UA can make both old and new types of offers and
allow the other UA to select the type of offer that it supports.
This specification extends the SIP to allow for these backwards
compatible offer/answer schemes.
The mechanism for doing this is based on multipart alternative MIME
types[2]. The UA making the offer uses a multipart alternative and
includes a Content-ID for each one of the parts. The UA receiving
the offer selects one of the parts in the offer and sends an answer
based on that part. When the UA sends the answer, it indicates the
Content-ID of the selected offer part by including this in a new
Content-Related-To header that is defined in this specification.
This approach can allow migration from SDP to SDPng[7]. It can also
allow migration from offers that are not S/MIME protected (as
described in RFC 3261) to ones that are, and allow SRTP [8] keying
material to be passed in the S/MIME protected SDP using a mechanism
such as SDES [8].
2. Conventions
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [4].
3. Mechanisms
3.1 Sending Offers
A UA that can support multiple types of offers SHOULD construct a
multipart/alternative body with a body for each type it supports.
Each body MUST include a unique Content-ID header.
If the UA receives an error response that indicates that
multipart/alternative is not supported, it MAY retry the request
using an offer that consists of only a SDP body.
3.2 Receiving Offers and Sending Answers
If a UA receives multiple SDP offers in an multipart/alternative
body, it MUST interpret these as it would a normal multipart
alternative, as defined in RFC 2046 [2], which means it picks the
Jennings Expires August 12, 2005 [Page 3]
Internet-Draft SIP Multipart February 2005
last alternative that it can support. Any S/MIME bodies that cannot
be decrypted MUST be treated as unsupportable.
When the UA constructs the answer, it MUST include a MIME
Content-Related-To header field as defined in Section 4 with the
value set to the value of the header field for the Content-ID of the
offer that was selected. The answer MAY also be a
multipart/alternative.
3.3 Receiving Answers
When the UA receives an answer, it MUST look at the
Content-Related-To header field value to find which answer has been
used. If the answer is a multipart/alternative, the UA selects the
preferred body in the same way it would for an offer. It then
proceeds with normal offer/answer processing.
4. Syntax
This specification defines a new MIME header called
"Content-Related-To". This updates RFC 2045 [3] with:
rid := "Content-Related-To" ":" msg-id
and adds "[rid CRLF]" to the Identity headers in RFC 2045.
The Content-Related-To header is used in answers and has a msg-id
value that is the same as the Content-ID value of the offer to which
this answer is related.
5. Multipart Outside of Offer/Answer
Applications such as presence and 911 location information result in
information with significant privacy requirements being sent in SIP.
Particular MIME types may define special meanings when both encrypted
and unencrypted bodies are received, but, unless otherwise specified,
the UA SHOULD use the encrypted version if it can decrypt it, and
ignore the unencrypted version. There is no requirement that the two
versions have the same information.
6. Example SIP SRTP Call
In this example, large parts of the message are omitted to highlight
what is relevant to this specification. The lines in the example
that are prefixed by $ represent encrypted blocks of data.
In this example, Alice calls Bob and offers both an RTP and an SRTP
session. The SDP for the SRTP session contains the SRTP keying
Jennings Expires August 12, 2005 [Page 4]
Internet-Draft SIP Multipart February 2005
material, and the SDP is encrypted with S/MIME. It is assumed that
Alice has Bob's public key.
Alice sends an INVITE to Bob that offers two alternative SDP bodies,
one of which is encrypted and contains the SRTP keying information.
The encrypted version is preferred so it comes second. Both parts
contain Content-ID headers.
INVITE sip:bob@biloxi.example.com SIP/2.0
...
Content-Type: multipart/alternative;boundary=boundary
--boundary
Content-ID: 123
Content-Type: application/sdp
Content-Disposition: session
< SDP offer for ordinary RTP only >
--boundary
Content-ID: 456
Content-Type: application/pkcs7-mime
Content-Disposition: session
$ Content-Type: application/sdp
$
$ < encrypted SDP with key for SRTP >
--boundary
Assuming that Bob's UA supports encryption and had Alice's public
key, it would select the second alternative part as the offer and
then construct an appropriate answer. The 200 includes the MIME
Content-Related-To header that indicates which alternative MIME body
was chosen.
200 OK
...
Content-ID: 789
Content-Related-To: 456
Content-Type: application/pkcs7-mime
Content-Disposition: session
$ Content-Type: application/sdp
$
$ < encrypted SDP with key for SRTP >
Jennings Expires August 12, 2005 [Page 5]
Internet-Draft SIP Multipart February 2005
7. Security considerations
TODO
8. IANA
The MIME Content-Related-To header does not require any IANA actions.
9. Acknowledgments
Thanks for comments from Flemming Andreasen, Paul Kyzivat, Mark
Baugher, and Dan Wing.
10. References
10.1 Normative References
[1] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
Session Description Protocol (SDP)", RFC 3264, June 2002.
[2] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996.
[3] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
10.2 Informational References
[6] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[7] Kutscher, D., Ott, J. and C. Bormann, "Session Description and
Capability Negotiation", draft-ietf-mmusic-sdpng-07 (work in
progress), October 2003.
[8] Andreasen, F., Baugher, M. and D. Wing, "Session Description
Protocol Security Descriptions for Media Streams",
draft-ietf-mmusic-sdescriptions-07 (work in progress), July
2004.
Jennings Expires August 12, 2005 [Page 6]
Internet-Draft SIP Multipart February 2005
[9] Baugher, M., McGrew, D., Naslund, M., Carrara, E. and K.
Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC
3711, March 2004.
Author's Address
Cullen Jennings
Cisco Systems
170 West Tasman Drive
MS: SJC-21/2
San Jose, CA 95134
USA
Phone: +1 408 902-3341
EMail: fluffy@cisco.com
Jennings Expires August 12, 2005 [Page 7]
Internet-Draft SIP Multipart February 2005
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Jennings Expires August 12, 2005 [Page 8]
| PAFTECH AB 2003-2026 | 2026-04-23 19:00:30 |