--- 1/draft-ietf-mmusic-rfc4566bis-17.txt 2017-02-04 04:14:23.688363442 -0800 +++ 2/draft-ietf-mmusic-rfc4566bis-18.txt 2017-02-04 04:14:23.796365991 -0800 @@ -1,23 +1,23 @@ Network Working Group M. Handley Internet-Draft UCL Obsoletes: 4566 (if approved) V. Jacobson Intended status: Standards Track PARC -Expires: December 24, 2016 C. Perkins +Expires: August 8, 2017 C. Perkins University of Glasgow A. Begen Networked Media - June 22, 2016 + February 4, 2017 SDP: Session Description Protocol - draft-ietf-mmusic-rfc4566bis-17 + draft-ietf-mmusic-rfc4566bis-18 Abstract This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. This document obsoletes RFC 4566. Status of This Memo @@ -27,25 +27,25 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on December 24, 2016. + This Internet-Draft will expire on August 8, 2017. Copyright Notice - Copyright (c) 2016 IETF Trust and the persons identified as the + Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -104,24 +104,24 @@ 6.7.1. recvonly (receive-only) . . . . . . . . . . . . . . . 31 6.7.2. sendrecv (send-receive) . . . . . . . . . . . . . . . 31 6.7.3. sendonly (send-only) . . . . . . . . . . . . . . . . 32 6.7.4. inactive . . . . . . . . . . . . . . . . . . . . . . 32 6.8. orient (orientation) . . . . . . . . . . . . . . . . . . 33 6.9. type (conference type) . . . . . . . . . . . . . . . . . 33 6.10. charset (character set) . . . . . . . . . . . . . . . . . 34 6.11. sdplang (SDP language) . . . . . . . . . . . . . . . . . 35 6.12. lang (language) . . . . . . . . . . . . . . . . . . . . . 36 6.13. framerate (frame rate) . . . . . . . . . . . . . . . . . 37 - 6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 37 + 6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 38 6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 38 7. Security Considerations . . . . . . . . . . . . . . . . . . . 39 - 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 + 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 8.1. The "application/sdp" Media Type . . . . . . . . . . . . 41 8.2. Registration of Parameters . . . . . . . . . . . . . . . 43 8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 43 8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 43 8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 44 8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 44 8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 47 8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 47 8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 48 8.2.8. Registration Procedure . . . . . . . . . . . . . . . 48 @@ -1027,23 +1027,24 @@ 5.14. Media Descriptions ("m=") m= ... A session description may contain a number of media descriptions. Each media description starts with an "m=" line and is terminated by either the next "m=" line or by the end of the session description. A media field has several sub-fields: - is the media type. Currently defined media are "audio", - "video", "text", "application", and "message", although this list - may be extended in the future (see Section 8). + is the media type. This document defines the values + "audio", "video", "text", "application", and "message". This list + is extended and may be further extended by other memos registering + media types in the future (see Section 8). is the transport port to which the media stream is sent. The meaning of the transport port depends on the network being used as specified in the relevant "c=" line, and on the transport protocol defined in the sub-field of the media field. Other ports used by the media application (such as the RTP Control Protocol (RTCP) port [RFC3550]) MAY be derived algorithmically from the base media port or MAY be specified in a separate attribute (for example, "a=rtcp:" as defined in [RFC3605]). @@ -1643,39 +1644,51 @@ Syntax: lang-value = Language-Tag ; Language-Tag defined in RFC5646 Example: a=lang:de Multiple lang attributes can be provided either at session or media - level if the session or media has capabilities to use multiple - languages, in which case the order of the attributes indicates the + level if the session or media has capabilities in more than one + language, in which case the order of the attributes indicates the order of preference of the various languages in the session or media, from most preferred to least preferred. As a session-level attribute, lang specifies a language capability for the session being described. As a media-level attribute, it specifies a language capability for that media, overriding any session-level language(s) specified. The "lang" attribute value must be a single [RFC5646] language tag in US-ASCII. A "lang" attribute SHOULD be specified when a session is of sufficient scope to cross geographic boundaries where the language - of recipients cannot be assumed, or where the session has + of participants cannot be assumed, or where the session has capabilities in languages different from the locally assumed norm. - Events during the session can influence which language(s) are used, - and the participants are not strictly bound to only use the declared - languages. + The "lang" attribute is supposed to be used for settling the initial + language(s) used in the session. Events during the session may + influence which language(s) are used, and the participants are not + strictly bound to only use the declared languages. + + Most real-time use cases start with just one language used, while + other cases involve a range of languages, e.g. an interpreted or + subtitled session. When more than one 'lang' attribute is specified, + the "lang" attribute itself does not provide any information about if + multiple languages are intended to be used during the session, or if + the intention is to only select one language. Other attributes or + the semantics in which the "lang" attributes are used might indicate + such conditions. Without such indications of usage intent, it is + assumed that for a negotiated session one of the declared languages + will be selected and used. 6.13. framerate (frame rate) Name: framerate Value: framerate-value Usage Level: media Charset Dependent: no @@ -2072,36 +2085,36 @@ 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. + 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 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. @@ -2387,22 +2400,22 @@ ; sub-rules of 'a=' attribute = (att-field ":" att-value) / att-field att-field = token att-value = byte-string ; sub-rules of 'm=' media = token - ;typically "audio", "video", "text", or - ;"application" + ;typically "audio", "video", "text", "image" + ;or "application" fmt = token ;typically an RTP payload type for audio ;and video media proto = token *("/" token) ;typically "RTP/AVP" or "udp" port = 1*DIGIT @@ -2589,28 +2602,28 @@ (SDP)", RFC 5576, DOI 10.17487/RFC5576, June 2009, . [I-D.iana-charset-reg-procedure] McFadden, M. and A. Melnikov, "IANA Charset Registration Procedures", draft-iana-charset-reg-procedure-01 (work in progress), April 2015. [I-D.ietf-mmusic-sdp-mux-attributes] Nandakumar, S., "A Framework for SDP Attributes when - Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-12 - (work in progress), January 2016. + Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-16 + (work in progress), December 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. + draft-ietf-mmusic-data-channel-sdpneg-11 (work in + progress), January 2017. 12.2. Informative References [RFC2327] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, DOI 10.17487/RFC2327, April 1998, . [RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch, "Network Time Protocol Version 4: Protocol and Algorithms Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,