draft-ietf-mmusic-rfc4566bis-16.txt   draft-ietf-mmusic-rfc4566bis-17.txt 
Network Working Group M. Handley Network Working Group M. Handley
Internet-Draft UCL Internet-Draft UCL
Obsoletes: 4566 (if approved) V. Jacobson Obsoletes: 4566 (if approved) V. Jacobson
Intended status: Standards Track PARC Intended status: Standards Track PARC
Expires: May 6, 2016 C. Perkins Expires: December 24, 2016 C. Perkins
University of Glasgow University of Glasgow
A. Begen A. Begen
Unaffiliated Networked Media
November 3, 2015 June 22, 2016
SDP: Session Description Protocol SDP: Session Description Protocol
draft-ietf-mmusic-rfc4566bis-16 draft-ietf-mmusic-rfc4566bis-17
Abstract Abstract
This memo defines the Session Description Protocol (SDP). SDP is This memo defines the Session Description Protocol (SDP). SDP is
intended for describing multimedia sessions for the purposes of intended for describing multimedia sessions for the purposes of
session announcement, session invitation, and other forms of session announcement, session invitation, and other forms of
multimedia session initiation. This document obsoletes RFC 4566. multimedia session initiation. This document obsoletes RFC 4566.
Status of This Memo Status of This Memo
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 6, 2016. This Internet-Draft will expire on December 24, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 31 skipping to change at page 3, line 31
6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 37 6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 37
6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 38 6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 38
7. Security Considerations . . . . . . . . . . . . . . . . . . . 39 7. Security Considerations . . . . . . . . . . . . . . . . . . . 39
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
8.1. The "application/sdp" Media Type . . . . . . . . . . . . 41 8.1. The "application/sdp" Media Type . . . . . . . . . . . . 41
8.2. Registration of Parameters . . . . . . . . . . . . . . . 43 8.2. Registration of Parameters . . . . . . . . . . . . . . . 43
8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 43 8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 43
8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 43 8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 43
8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 44 8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 44
8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 44 8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 44
8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 46 8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 47
8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 46 8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 47
8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 47 8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 48
8.2.8. Registration Procedure . . . . . . . . . . . . . . . 47 8.2.8. Registration Procedure . . . . . . . . . . . . . . . 48
8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 48 8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 49
8.4. Reorganization of the nettype Registry . . . . . . . . . 48 8.4. Reorganization of the nettype Registry . . . . . . . . . 49
8.5. Reorganization of the att-field Registries . . . . . . . 48 8.5. Reorganization of the att-field Registries . . . . . . . 49
9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 49 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 50
10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 54 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 55
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 56
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 56
12.1. Normative References . . . . . . . . . . . . . . . . . . 55 12.1. Normative References . . . . . . . . . . . . . . . . . . 56
12.2. Informative References . . . . . . . . . . . . . . . . . 56 12.2. Informative References . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 60
1. Introduction 1. Introduction
When initiating multimedia teleconferences, voice-over-IP calls, When initiating multimedia teleconferences, voice-over-IP calls,
streaming video, or other sessions, there is a requirement to convey streaming video, or other sessions, there is a requirement to convey
media details, transport addresses, and other session description media details, transport addresses, and other session description
metadata to the participants. metadata to the participants.
SDP provides a standard representation for such information, SDP provides a standard representation for such information,
irrespective of how that information is transported. SDP is purely a irrespective of how that information is transported. SDP is purely a
skipping to change at page 4, line 33 skipping to change at page 4, line 33
2. Glossary of Terms 2. Glossary of Terms
The following term is used in this document and has specific meaning The following term is used in this document and has specific meaning
within the context of this document. within the context of this document.
Session Description: A well-defined format for conveying sufficient Session Description: A well-defined format for conveying sufficient
information to discover and participate in a multimedia session. information to discover and participate in a multimedia session.
The terms "multimedia conference" and "multimedia session" are used The terms "multimedia conference" and "multimedia session" are used
in this document as defined in in this document as defined in [RFC7656]. The terms "session" and
[I-D.ietf-avtext-rtp-grouping-taxonomy]. The terms "session" and
"multimedia session" are used interchangeably in this document. "multimedia session" are used interchangeably in this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[RFC2119]. [RFC2119].
3. Examples of SDP Usage 3. Examples of SDP Usage
3.1. Session Initiation 3.1. Session Initiation
skipping to change at page 44, line 47 skipping to change at page 44, line 47
format. format.
For other protocols, formats MAY be registered according to the rules For other protocols, formats MAY be registered according to the rules
of the associated "proto" specification. of the associated "proto" specification.
Registrations of new formats MUST specify which transport protocols Registrations of new formats MUST specify which transport protocols
they apply to. they apply to.
8.2.4. Attribute Names ("att-field") 8.2.4. Attribute Names ("att-field")
8.2.4.1. New Attributes
Attribute field names ("att-field") MUST be registered with IANA and Attribute field names ("att-field") MUST be registered with IANA and
documented, because of noticeable issues due to conflicting documented, because of noticeable issues due to conflicting
attributes under the same name. Unknown attributes in SDP are simply attributes under the same name. Unknown attributes in SDP are simply
ignored, but conflicting ones that fragment the protocol are a ignored, but conflicting ones that fragment the protocol are a
serious problem. serious problem.
New attribute registrations are accepted according to the New attribute registrations are accepted according to the
"Specification Required" policy of [RFC5226], provided that the "Specification Required" policy of [RFC5226], provided that the
specification includes the following information: specification includes the following information:
o Contact name, email address, and telephone number. o Contact Name.
o Attribute name (as it will appear in SDP). This MUST conform to o Contact Email Address.
the definition of <att-field>.
o Attribute value: The name of an ABNF syntax rule defining the o Attribute Name: The name of the attribute that will appear in
syntax of the value. Absence of a rule name indicates that the SDP). This MUST conform to the definition of <att-field>.
attribute takes no value. Enclosing the rule name in "[" and "]"
indicates that a value is optional.
o Usage level of the attribute. (One or more of: session, media, o Attribute Syntax: For a value attribute (see clause 5.13), an ABNF
source). definition of the attribute value <att-value> syntax (See
Section Section 9) MUST be provided. The syntax MUST follow the
rule form as per Section 2.2 of [RFC5234]. This SHALL define the
allowable values that the attribute might take. It MAY also
define an extension method for the addition of future values. For
a property attribute, the ABNF definition is omitted as the
property attribute takes no values.
o Whether the attribute value is subject to the charset attribute. o Attribute Semantics: For a value attribute, a semantic description
of the values that the attribute might take MUST be provided. The
usage of a property attribute is described under purpose below.
o An ABNF definition of the attribute value rule. The rule MUST NOT o Attribute Value: The name of an ABNF syntax rule defining the
match anything that is not also matched by <att-value>. The rule syntax of the value. Absence of a rule name indicates that the
name MUST NOT be defined as an Incremental Alternative to <att- attribute takes no values. Enclosing the rule name in "[" and "]"
value>. indicates that a value is optional.
o An explanation of the purpose and usage of the attribute. o Usage Level: Usage level(s) of the attribute. One or more of:
session, media, source, dcsa, dcsa(subprotocol). For a definition
of source level attributes, see [RFC5576]. For a definition of
dcsa attributes see: [I-D.ietf-mmusic-data-channel-sdpneg].
o A specification of appropriate attribute values for this attribute o Charset Dependent: Whether the attribute value is subject to the
(If not included in syntax). charset attribute or not (Yes/No).
o Offer/Answer procedures as explained in [RFC3264]. o Purpose: An explanation of the purpose and usage of the attribute.
o Indication of which "category" o O/A Procedures: Offer/Answer procedures as explained in [RFC3264].
o Mux Category: Indication of which multiplexing "category"
[I-D.ietf-mmusic-sdp-mux-attributes] an attribute is associated [I-D.ietf-mmusic-sdp-mux-attributes] an attribute is associated
with. with.
o Reference: A reference to the specification defining the
attribute.
The above is the minimum that IANA will accept. Attributes that are The above is the minimum that IANA will accept. Attributes that are
expected to see widespread use and interoperability SHOULD be expected to see widespread use and interoperability SHOULD be
documented with a standards-track RFC that specifies the attribute documented with a standards-track RFC that specifies the attribute
more precisely. more precisely.
Submitters of registrations should ensure that the specification is Submitters of registrations should ensure that the specification is
in the spirit of SDP attributes, most notably that the attribute is in the spirit of SDP attributes, most notably that the attribute is
platform independent in the sense that it makes no implicit platform independent in the sense that it makes no implicit
assumptions about operating systems and does not name specific pieces assumptions about operating systems and does not name specific pieces
of software in a manner that might inhibit interoperability. of software in a manner that might inhibit interoperability.
Submitters of registrations should also carefully choose the Submitters of registrations should also carefully choose the
attribute usage level. They should not choose only "session" when attribute usage level. They should not choose only "session" when
the attribute can have different values when media is disaggregated, the attribute can have different values when media is disaggregated,
i.e., when each m= section has its own IP address on a different i.e., when each m= section has its own IP address on a different
endpoint. In that case the attribute type chosen should be "session, endpoint. In that case the attribute type chosen should be "session,
media". The default rule is that for all new SDP attributes that can media". The default rule is that for all new SDP attributes that can
occur both in session and media level, the media level overrides the occur both in session and media level, the media level overrides the
session level. When this is not the case for a new SDP attribute, it session level. When this is not the case for a new SDP attribute, it
should be explicitly stated. MUST be explicitly stated.
IANA has registered the initial set of attribute names ("att-field" IANA has registered the initial set of attribute names ("att-field"
values), with definitions as in Section 6 of this memo (these values), with definitions as in Section 6 of this memo (these
definitions replace those in [RFC4566]). definitions replace those in [RFC4566]).
8.2.4.2. Updates to Existing Attributes
Updated attribute registrations are accepted according to the
"Specification Required" policy of [RFC5226], provided that the
specification updating the attribute (for example, by adding a new
value) considers the registration information items from
Section Section 8.2.4.1 according to the following bullets:
o Contact Name: A name MUST be provided.
o Contact Email Address: An email address MUST be provided.
o Attribute Name: MUST be provided and MUST not be changed.
Otherwise it is a new attribute.
o Attribute Syntax: The existing rule syntax with the syntax
extensions MUST be provided if there is a change to the syntax. A
revision to an existing attribute usage MAY extend the syntax of
an attribute, but MUST be backward compatible.
o Attribute Semantics: A semantic description of new additional
attributes values or a semantic extension of existing values.
Existing attribute values semantics MUST only be extended in a
backward compatible manner.
o Usage Level: Updates MAY only add additional levels.
o Charset Dependent: MUST not be changed.
o Purpose: MAY be extended according to the updated usage.
o O/A Procedures: MAY be updated in a backward compatible manner
and/or it applies to a new usage level only.
o Mux Category: No change unless from TBD to another value. It MAY
also change if 'media' level is being added to the definition of
an attribute that previously did not include it.
o Reference: A new reference MUST be provided.
Items SHOULD be omitted if there is no impact to them as a result of
the attribute update.
8.2.5. Bandwidth Specifiers ("bwtype") 8.2.5. Bandwidth Specifiers ("bwtype")
A proliferation of bandwidth specifiers is strongly discouraged. A proliferation of bandwidth specifiers is strongly discouraged.
New bandwidth specifiers ("bwtype" fields) MUST be registered with New bandwidth specifiers ("bwtype" fields) MUST be registered with
IANA. The submission MUST reference a standards-track RFC specifying IANA. The submission MUST reference a standards-track RFC specifying
the semantics of the bandwidth specifier precisely, and indicating the semantics of the bandwidth specifier precisely, and indicating
when it should be used, and why the existing registered bandwidth when it should be used, and why the existing registered bandwidth
specifiers do not suffice. specifiers do not suffice.
skipping to change at page 48, line 32 skipping to change at page 49, line 38
|nettype | ATM | NSAP, GWID, E164 | [RFC3108] | |nettype | ATM | NSAP, GWID, E164 | [RFC3108] |
|nettype | PSTN | E164 | [RFC7195] | |nettype | PSTN | E164 | [RFC7195] |
-------------------------------------------------------------------- --------------------------------------------------------------------
Note that both [RFC7195] and [RFC3108] registered "E164" as an Note that both [RFC7195] and [RFC3108] registered "E164" as an
address type, although [RFC7195] mentions that the "E164" address address type, although [RFC7195] mentions that the "E164" address
type has a different context for ATM and PSTN networks. type has a different context for ATM and PSTN networks.
8.5. Reorganization of the att-field Registries 8.5. Reorganization of the att-field Registries
This document combines all the five "att-field" registries into one This document combines all of the (currently) five "att-field"
registry called "att-field" registry, and update the columns to registries into one registry called "att-field" registry, and updates
reflect the name, usage level(s), charset dependency and reference. the columns to reflect the name, usage level(s), charset dependency
That is, the new registry uses the following columns: and reference. As such IANA is requested to create a new combined
registry using the following columns:
Name | Usage Level | Dependent on charset? | Reference Name | Usage Level | Dependent on Charset? | Mux Category | Reference
The "Name" column reflects the attribute name (as it will appear in The "Name" column reflects the attribute name (as it will appear in
the SDP). The "Usage Level" column MUST indicate one or more of the the SDP). The "Usage Level" column MUST indicate one or more of the
following: session, media, source. The "Dependent on charset?" following: session, media, source, dcsa and dcsa(subprotocol). The
column MUST indicate "Yes" or "No" depending on whether the attribute "Dependent on Charset?" column MUST indicate "Yes" or "No" depending
value is subject to the charset attribute. Finally, the "Reference" on whether the attribute value is subject to the charset attribute.
The "Mux Category" column MUST indicate one of the following
categories: NORMAL, NOT RECOMMENDED, IDENTICAL, SUM, TRANSPORT,
INHERIT, IDENTICAL-PER-PT, SPECIAL or TBD as defined by
[I-D.ietf-mmusic-sdp-mux-attributes]. Finally, the "Reference"
column indicates the specification(s) where the attribute is defined. column indicates the specification(s) where the attribute is defined.
Editor's note: Will IANA reorganize this table based on what is in For example, the attribute "setup" which is defined for both session
the registry now or should we provide the updated table in this and media level, will be listed in the new registry as follows:
document?
Editor's note: [I-D.ietf-mmusic-sdp-mux-attributes] adds another Name | Usage Level | Dependent on Charset? | Mux Category | Reference
column (muxing category) to this table. Should we add it here? setup | session,media, | No | IDENTICAL | [RFC4145],[RFC6135], |
| dcsa,dcsa(msrp)| | | [I-D.mmusic-msrp-usage-data-channel] |
9. SDP Grammar 9. SDP Grammar
This section provides an Augmented BNF grammar for SDP. ABNF is This section provides an Augmented BNF grammar for SDP. ABNF is
defined in [RFC5234] and [RFC7405]. defined in [RFC5234] and [RFC7405].
; SDP Syntax ; SDP Syntax
session-description = proto-version session-description = proto-version
origin-field origin-field
session-name-field session-name-field
skipping to change at page 56, line 9 skipping to change at page 57, line 18
<http://www.rfc-editor.org/info/rfc5890>. <http://www.rfc-editor.org/info/rfc5890>.
[RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
<http://www.rfc-editor.org/info/rfc4648>. <http://www.rfc-editor.org/info/rfc4648>.
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
Description Protocol", RFC 4566, DOI 10.17487/RFC4566, Description Protocol", RFC 4566, DOI 10.17487/RFC4566,
July 2006, <http://www.rfc-editor.org/info/rfc4566>. July 2006, <http://www.rfc-editor.org/info/rfc4566>.
[I-D.ietf-avtext-rtp-grouping-taxonomy] [RFC7656] Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and
Lennox, J., Gross, K., Nandakumar, S., Salgueiro, G., and B. Burman, Ed., "A Taxonomy of Semantics and Mechanisms
B. Burman, "A Taxonomy of Semantics and Mechanisms for for Real-Time Transport Protocol (RTP) Sources", RFC 7656,
Real-Time Transport Protocol (RTP) Sources", draft-ietf- DOI 10.17487/RFC7656, November 2015,
avtext-rtp-grouping-taxonomy-08 (work in progress), July <http://www.rfc-editor.org/info/rfc7656>.
2015.
[RFC5576] Lennox, J., Ott, J., and T. Schierl, "Source-Specific
Media Attributes in the Session Description Protocol
(SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009,
<http://www.rfc-editor.org/info/rfc5576>.
[I-D.iana-charset-reg-procedure] [I-D.iana-charset-reg-procedure]
McFadden, M. and A. Melnikov, "IANA Charset Registration McFadden, M. and A. Melnikov, "IANA Charset Registration
Procedures", draft-iana-charset-reg-procedure-01 (work in Procedures", draft-iana-charset-reg-procedure-01 (work in
progress), April 2015. progress), April 2015.
[I-D.ietf-mmusic-sdp-mux-attributes] [I-D.ietf-mmusic-sdp-mux-attributes]
Nandakumar, S., "A Framework for SDP Attributes when Nandakumar, S., "A Framework for SDP Attributes when
Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-10 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12
(work in progress), July 2015. (work in progress), January 2016.
[I-D.ietf-mmusic-data-channel-sdpneg]
Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R.,
and J. Marcon, "SDP-based Data Channel Negotiation",
draft-ietf-mmusic-data-channel-sdpneg-08 (work in
progress), February 2016.
12.2. Informative References 12.2. Informative References
[RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, DOI 10.17487/RFC2327, April 1998, Protocol", RFC 2327, DOI 10.17487/RFC2327, April 1998,
<http://www.rfc-editor.org/info/rfc2327>. <http://www.rfc-editor.org/info/rfc2327>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms "Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010, Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
skipping to change at page 59, line 31 skipping to change at page 61, line 4
EMail: van@parc.com EMail: van@parc.com
Colin Perkins Colin Perkins
University of Glasgow University of Glasgow
School of Computing Science School of Computing Science
University of Glasgow University of Glasgow
Glasgow G12 8QQ Glasgow G12 8QQ
UK UK
EMail: csp@csperkins.org EMail: csp@csperkins.org
Ali Begen Ali Begen
Unaffiliated Networked Media
Konya
Turkey
EMail: acbegen@gmail.com EMail: ali.begen@networked.media
 End of changes. 31 change blocks. 
65 lines changed or deleted 138 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/