draft-ietf-mmusic-rfc4566bis-29.txt   draft-ietf-mmusic-rfc4566bis-30.txt 
Network Working Group A. Begen Network Working Group A. Begen
Internet-Draft Networked Media Internet-Draft Networked Media
Obsoletes: 4566 (if approved) P. Kyzivat Obsoletes: 4566 (if approved) P. Kyzivat
Intended status: Standards Track Intended status: Standards Track
Expires: December 7, 2018 C. Perkins Expires: January 2, 2019 C. Perkins
University of Glasgow University of Glasgow
M. Handley M. Handley
UCL UCL
June 5, 2018 July 1, 2018
SDP: Session Description Protocol SDP: Session Description Protocol
draft-ietf-mmusic-rfc4566bis-29 draft-ietf-mmusic-rfc4566bis-30
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 December 7, 2018. This Internet-Draft will expire on January 2, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
skipping to change at page 2, line 48 skipping to change at page 2, line 48
5.2. Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 12 5.2. Origin ("o=") . . . . . . . . . . . . . . . . . . . . . . 12
5.3. Session Name ("s=") . . . . . . . . . . . . . . . . . . . 13 5.3. Session Name ("s=") . . . . . . . . . . . . . . . . . . . 13
5.4. Session Information ("i=") . . . . . . . . . . . . . . . 13 5.4. Session Information ("i=") . . . . . . . . . . . . . . . 13
5.5. URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . 14 5.5. URI ("u=") . . . . . . . . . . . . . . . . . . . . . . . 14
5.6. Email Address and Phone Number ("e=" and "p=") . . . . . 14 5.6. Email Address and Phone Number ("e=" and "p=") . . . . . 14
5.7. Connection Information ("c=") . . . . . . . . . . . . . . 15 5.7. Connection Information ("c=") . . . . . . . . . . . . . . 15
5.8. Bandwidth Information ("b=") . . . . . . . . . . . . . . 17 5.8. Bandwidth Information ("b=") . . . . . . . . . . . . . . 17
5.9. Time Active ("t=") . . . . . . . . . . . . . . . . . . . 18 5.9. Time Active ("t=") . . . . . . . . . . . . . . . . . . . 18
5.10. Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . 19 5.10. Repeat Times ("r=") . . . . . . . . . . . . . . . . . . . 19
5.11. Time Zone Adjustment ("z=") . . . . . . . . . . . . . . . 20 5.11. Time Zone Adjustment ("z=") . . . . . . . . . . . . . . . 20
5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 20 5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 21
5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 21 5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 21
5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 22 5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 22
6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 24 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 25
6.1. cat (category) . . . . . . . . . . . . . . . . . . . . . 25 6.1. cat (category) . . . . . . . . . . . . . . . . . . . . . 25
6.2. keywds (keywords) . . . . . . . . . . . . . . . . . . . . 25 6.2. keywds (keywords) . . . . . . . . . . . . . . . . . . . . 25
6.3. tool . . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.3. tool . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.4. ptime (packet time) . . . . . . . . . . . . . . . . . . . 26 6.4. ptime (packet time) . . . . . . . . . . . . . . . . . . . 26
6.5. maxptime (maximum packet time) . . . . . . . . . . . . . 27 6.5. maxptime (maximum packet time) . . . . . . . . . . . . . 27
6.6. rtpmap . . . . . . . . . . . . . . . . . . . . . . . . . 27 6.6. rtpmap . . . . . . . . . . . . . . . . . . . . . . . . . 27
6.7. Media Direction Attributes . . . . . . . . . . . . . . . 29 6.7. Media Direction Attributes . . . . . . . . . . . . . . . 29
6.7.1. recvonly (receive-only) . . . . . . . . . . . . . . . 30 6.7.1. recvonly (receive-only) . . . . . . . . . . . . . . . 30
6.7.2. sendrecv (send-receive) . . . . . . . . . . . . . . . 30 6.7.2. sendrecv (send-receive) . . . . . . . . . . . . . . . 30
6.7.3. sendonly (send-only) . . . . . . . . . . . . . . . . 30 6.7.3. sendonly (send-only) . . . . . . . . . . . . . . . . 31
6.7.4. inactive . . . . . . . . . . . . . . . . . . . . . . 31 6.7.4. inactive . . . . . . . . . . . . . . . . . . . . . . 31
6.8. orient (orientation) . . . . . . . . . . . . . . . . . . 31 6.8. orient (orientation) . . . . . . . . . . . . . . . . . . 32
6.9. type (conference type) . . . . . . . . . . . . . . . . . 32 6.9. type (conference type) . . . . . . . . . . . . . . . . . 32
6.10. charset (character set) . . . . . . . . . . . . . . . . . 33 6.10. charset (character set) . . . . . . . . . . . . . . . . . 33
6.11. sdplang (SDP language) . . . . . . . . . . . . . . . . . 34 6.11. sdplang (SDP language) . . . . . . . . . . . . . . . . . 34
6.12. lang (language) . . . . . . . . . . . . . . . . . . . . . 34 6.12. lang (language) . . . . . . . . . . . . . . . . . . . . . 35
6.13. framerate (frame rate) . . . . . . . . . . . . . . . . . 36 6.13. framerate (frame rate) . . . . . . . . . . . . . . . . . 36
6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 36 6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 37 6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 37
7. Security Considerations . . . . . . . . . . . . . . . . . . . 37 7. Security Considerations . . . . . . . . . . . . . . . . . . . 38
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
8.1. The "application/sdp" Media Type . . . . . . . . . . . . 39 8.1. The "application/sdp" Media Type . . . . . . . . . . . . 39
8.2. Registration of Parameters . . . . . . . . . . . . . . . 40 8.2. Registration of Parameters . . . . . . . . . . . . . . . 41
8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 41 8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 41
8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 41 8.2.2. Transport Protocols ("proto") . . . . . . . . . . . . 41
8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 42 8.2.3. Media Formats ("fmt") . . . . . . . . . . . . . . . . 42
8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 42 8.2.4. Attribute Names ("att-field") . . . . . . . . . . . . 42
8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 45 8.2.5. Bandwidth Specifiers ("bwtype") . . . . . . . . . . . 45
8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 45 8.2.6. Network Types ("nettype") . . . . . . . . . . . . . . 45
8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 46 8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 46
8.2.8. Registration Procedure . . . . . . . . . . . . . . . 46 8.2.8. Registration Procedure . . . . . . . . . . . . . . . 46
8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 47 8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 47
8.4. Reorganization of the nettype Registry . . . . . . . . . 47 8.4. Reorganization of the nettype Registry . . . . . . . . . 47
8.5. Reorganization of the att-field Registries . . . . . . . 47 8.5. Reorganization of the att-field Registries . . . . . . . 47
9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 48 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 48
10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 53 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 54
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
12.1. Normative References . . . . . . . . . . . . . . . . . . 54 12.1. Normative References . . . . . . . . . . . . . . . . . . 54
12.2. Informative References . . . . . . . . . . . . . . . . . 55 12.2. Informative References . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 59
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 5, line 37 skipping to change at page 5, line 37
those parameters. those parameters.
3.3. Email and the World Wide Web 3.3. Email and the World Wide Web
Alternative means of conveying session descriptions include Alternative means of conveying session descriptions include
electronic mail and the World Wide Web (WWW). For both email and WWW electronic mail and the World Wide Web (WWW). For both email and WWW
distribution, the media type "application/sdp" is used. This enables distribution, the media type "application/sdp" is used. This enables
the automatic launching of applications for participation in the the automatic launching of applications for participation in the
session from the WWW client or mail reader in a standard manner. session from the WWW client or mail reader in a standard manner.
Note that announcements of multicast sessions made only via email or Note that descriptions of multicast sessions made only via email or
the WWW do not have the property that the receiver of a session the WWW do not have the property that the receiver of a session
announcement can necessarily receive the session because the description can necessarily receive the session because the multicast
multicast sessions may be restricted in scope, and access to the WWW sessions may be restricted in scope, and access to the WWW server or
server or reception of email is possible outside this scope. reception of email is possible outside this scope.
3.4. Multicast Session Announcement 3.4. Multicast Session Announcement
In order to assist the advertisement of multicast multimedia In order to assist the advertisement of multicast multimedia
conferences and other multicast sessions, and to communicate the conferences and other multicast sessions, and to communicate the
relevant session setup information to prospective participants, a relevant session setup information to prospective participants, a
distributed session directory may be used. An instance of such a distributed session directory may be used. An instance of such a
session directory periodically sends packets containing a description session directory periodically sends packets containing a description
of the session to a well-known multicast group. These advertisements of the session to a well-known multicast group. These advertisements
are received by other session directories such that potential remote are received by other session directories such that potential remote
skipping to change at page 7, line 36 skipping to change at page 7, line 36
of the multicast stream, whether being sent, received, or both. of the multicast stream, whether being sent, received, or both.
For unicast IP sessions, the following are conveyed: For unicast IP sessions, the following are conveyed:
o The remote address for media o The remote address for media
o The remote transport port for media o The remote transport port for media
The semantics of this address and port depend on the media and The semantics of this address and port depend on the media and
transport protocol defined. By default, this SHOULD be the remote transport protocol defined. By default, this SHOULD be the remote
address and remote port to which data is sent. Some media types may address and remote port to which media is sent. Some media types may
redefine this behaviour, but this is NOT RECOMMENDED since it redefine this behavior, but this is NOT RECOMMENDED since it
complicates implementations (including middleboxes that must parse complicates implementations (including middleboxes that must parse
the addresses to open Network Address Translation (NAT) or firewall the addresses to open Network Address Translation (NAT) or firewall
pinholes). pinholes).
4.2. Timing Information 4.2. Timing Information
Sessions may be either bounded or unbounded in time. Whether or not Sessions may be either bounded or unbounded in time. Whether or not
they are bounded, they may be only active at specific times. SDP can they are bounded, they may be only active at specific times. SDP can
convey: convey:
skipping to change at page 8, line 19 skipping to change at page 8, line 19
A session description could convey enough information to decide A session description could convey enough information to decide
whether or not to participate in a session. SDP may include whether or not to participate in a session. SDP may include
additional pointers in the form of Uniform Resource Identifiers additional pointers in the form of Uniform Resource Identifiers
(URIs) for more information about the session. (URIs) for more information about the session.
4.4. Categorization 4.4. Categorization
When many session descriptions are being distributed by an When many session descriptions are being distributed by an
advertisement mechanism, it may be desirable to filter session advertisement mechanism, it may be desirable to filter session
announcements that are of interest from those that are not. SDP descriptions that are of interest from those that are not. SDP
supports a categorization mechanism for sessions that is capable of supports a categorization mechanism for sessions that is capable of
being automated (the "a=cat:" attribute; see Section 6). being automated (the "a=cat:" attribute; see Section 6).
4.5. Internationalization 4.5. Internationalization
The SDP specification recommends the use of the ISO 10646 character The SDP specification recommends the use of the ISO 10646 character
set in the UTF-8 encoding [RFC3629] to allow many different languages set in the UTF-8 encoding [RFC3629] to allow many different languages
to be represented. However, to assist in compact representations, to be represented. However, to assist in compact representations,
SDP also allows other character sets such as ISO 8859-1 to be used SDP also allows other character sets such as ISO 8859-1 to be used
when desired. Internationalization only applies to free-text sub- when desired. Internationalization only applies to free-text sub-
skipping to change at page 8, line 51 skipping to change at page 8, line 51
in UTF-8 encoding, or some other character set defined by the in UTF-8 encoding, or some other character set defined by the
"a=charset:" attribute. Field and attribute values that use the full "a=charset:" attribute. Field and attribute values that use the full
UTF-8 character set are never directly compared, hence there is no UTF-8 character set are never directly compared, hence there is no
requirement for UTF-8 normalization. The textual form, as opposed to requirement for UTF-8 normalization. The textual form, as opposed to
a binary encoding such as ASN.1 or XDR, was chosen to enhance a binary encoding such as ASN.1 or XDR, was chosen to enhance
portability, to enable a variety of transports to be used, and to portability, to enable a variety of transports to be used, and to
allow flexible, text-based toolkits to be used to generate and allow flexible, text-based toolkits to be used to generate and
process session descriptions. However, since SDP may be used in process session descriptions. However, since SDP may be used in
environments where the maximum permissible size of a session environments where the maximum permissible size of a session
description is limited, the encoding is deliberately compact. Also, description is limited, the encoding is deliberately compact. Also,
since announcements may be transported via very unreliable means or since descriptions may be transported via very unreliable means or
damaged by an intermediate caching server, the encoding was designed damaged by an intermediate caching server, the encoding was designed
with strict order and formatting rules so that most errors would with strict order and formatting rules so that most errors would
result in malformed session announcements that could be detected result in malformed session descriptions that could be detected
easily and discarded. This also allows rapid discarding of encrypted easily and discarded. This also allows rapid discarding of encrypted
session announcements for which a receiver does not have the correct session descriptions for which a receiver does not have the correct
key. key.
An SDP description consists of a number of lines of text of the form: An SDP description consists of a number of lines of text of the form:
<type>=<value> <type>=<value>
where <type> MUST be exactly one case-significant character and where <type> MUST be exactly one case-significant character and
<value> is structured text whose format depends on <type>. In <value> is structured text whose format depends on <type>. In
general, <value> is either a number of sub-fields delimited by a general, <value> is either a number of sub-fields delimited by a
single space character or a free format string, and is case- single space character or a free format string, and is case-
skipping to change at page 11, line 27 skipping to change at page 11, line 27
a=recvonly a=recvonly
m=audio 49170 RTP/AVP 0 m=audio 49170 RTP/AVP 0
m=audio 49180 RTP/AVP 0 m=audio 49180 RTP/AVP 0
m=video 51372 RTP/AVP 99 m=video 51372 RTP/AVP 99
c=IN IP4 233.252.0.1/127 c=IN IP4 233.252.0.1/127
a=rtpmap:99 h263-1998/90000 a=rtpmap:99 h263-1998/90000
Text containing fields such as the session-name-field and Text containing fields such as the session-name-field and
information-field are octet strings that may contain any octet with information-field are octet strings that may contain any octet with
the exceptions of 0x00 (Nul), 0x0a (ASCII newline), and 0x0d (ASCII the exceptions of 0x00 (Nul), 0x0a (ASCII newline), and 0x0d (ASCII
carriage return). The sequence CRLF (0x0d0a) is used to end a carriage return). The sequence CRLF (0x0d0a) is used to end a line,
record, although parsers SHOULD be tolerant and also accept records although parsers SHOULD be tolerant and also accept lines terminated
terminated with a single newline character. If the "a=charset" with a single newline character. If the "a=charset" attribute is not
attribute is not present, these octet strings MUST be interpreted as present, these octet strings MUST be interpreted as containing
containing ISO-10646 characters in UTF-8 encoding (the presence of ISO-10646 characters in UTF-8 encoding (the presence of the
the "a=charset" attribute may force some fields to be interpreted "a=charset" attribute may force some fields to be interpreted
differently). differently).
A session description can contain domain names in the "o=", "u=", A session description can contain domain names in the "o=", "u=",
"e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply "e=", "c=", and "a=" lines. Any domain name used in SDP MUST comply
with [RFC1034], [RFC1035]. Internationalized domain names (IDNs) with [RFC1034], [RFC1035]. Internationalized domain names (IDNs)
MUST be represented using the ASCII Compatible Encoding (ACE) form MUST be represented using the ASCII Compatible Encoding (ACE) form
defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or defined in [RFC5890] and MUST NOT be directly represented in UTF-8 or
any other encoding (this requirement is for compatibility with any other encoding (this requirement is for compatibility with
[RFC2327] and other early SDP-related standards, which predate the [RFC2327] and other early SDP-related standards, which predate the
development of internationalized domain names). development of internationalized domain names).
skipping to change at page 12, line 27 skipping to change at page 12, line 27
<sess-id> is a numeric string such that the tuple of <username>, <sess-id> is a numeric string such that the tuple of <username>,
<sess-id>, <nettype>, <addrtype>, and <unicast-address> forms a <sess-id>, <nettype>, <addrtype>, and <unicast-address> forms a
globally unique identifier for the session. The method of <sess- globally unique identifier for the session. The method of <sess-
id> allocation is up to the creating tool, but it has been id> allocation is up to the creating tool, but it has been
suggested that a Network Time Protocol (NTP) format timestamp be suggested that a Network Time Protocol (NTP) format timestamp be
used to ensure uniqueness [RFC5905]. used to ensure uniqueness [RFC5905].
<sess-version> is a version number for this session description. <sess-version> is a version number for this session description.
Its usage is up to the creating tool, so long as <sess-version> is Its usage is up to the creating tool, so long as <sess-version> is
increased when a modification is made to the session data. Again, increased when a modification is made to the session description.
it is RECOMMENDED that an NTP format timestamp is used. Again, it is RECOMMENDED that an NTP format timestamp is used.
<nettype> is a text string giving the type of network. Initially <nettype> is a text string giving the type of network. Initially
"IN" is defined to have the meaning "Internet", but other values "IN" is defined to have the meaning "Internet", but other values
MAY be registered in the future (see Section 8). MAY be registered in the future (see Section 8).
<addrtype> is a text string giving the type of the address that <addrtype> is a text string giving the type of the address that
follows. Initially "IP4" and "IP6" are defined, but other values follows. Initially "IP4" and "IP6" are defined, but other values
MAY be registered in the future (see Section 8). MAY be registered in the future (see Section 8).
<unicast-address> is an address of the machine from which the <unicast-address> is an address of the machine from which the
skipping to change at page 15, line 31 skipping to change at page 15, line 31
The second sub-field ("<addrtype>") is the address type. This allows The second sub-field ("<addrtype>") is the address type. This allows
SDP to be used for sessions that are not IP based. This memo only SDP to be used for sessions that are not IP based. This memo only
defines IP4 and IP6, but other values MAY be registered in the future defines IP4 and IP6, but other values MAY be registered in the future
(see Section 8). (see Section 8).
The third sub-field ("<connection-address>") is the connection The third sub-field ("<connection-address>") is the connection
address. Additional sub-fields MAY be added after the connection address. Additional sub-fields MAY be added after the connection
address depending on the value of the <addrtype> sub-field. address depending on the value of the <addrtype> sub-field.
When the <addrtype> is IP4 and IP6, the connection address is defined When the <addrtype> is IP4 or IP6, the connection address is defined
as follows: as follows:
o If the session is multicast, the connection address will be an IP o If the session is multicast, the connection address will be an IP
multicast group address. If the session is not multicast, then multicast group address. If the session is not multicast, then
the connection address contains the unicast IP address of the the connection address contains the unicast IP address of the
expected data source, data relay or data sink as determined by expected data source, data relay or data sink as determined by
additional attribute-fields. It is not expected that unicast additional attribute-fields. It is not expected that unicast
addresses will be given in a session description that is addresses will be given in a session description that is
communicated by a multicast announcement, though this is not communicated by a multicast announcement, though this is not
prohibited. prohibited.
skipping to change at page 18, line 27 skipping to change at page 18, line 27
A "t=" line (time-field) initiates a time description that specifies A "t=" line (time-field) initiates a time description that specifies
the start and stop times for a session. Multiple time descriptions the start and stop times for a session. Multiple time descriptions
MAY be used if a session is active at multiple irregularly spaced MAY be used if a session is active at multiple irregularly spaced
times; each additional time description specifies additional periods times; each additional time description specifies additional periods
of time for which the session will be active. If the session is of time for which the session will be active. If the session is
active at regular repeat times, a repeat description, initiated by an active at regular repeat times, a repeat description, initiated by an
"r=" line (see below) can be included following the time-field -- in "r=" line (see below) can be included following the time-field -- in
which case the time-field specifies the start and stop times of the which case the time-field specifies the start and stop times of the
entire repeat sequence. entire repeat sequence.
The following example specifies two active intervals:
t=3724394400 3724398000 ; Mon 8-Jan-2018 10:00-11:00 UTC
t=3724484400 3724488000 ; Tue 9-Jan-2018 11:00-12:00 UTC
The first and second sub-fields of the time-field give the start and The first and second sub-fields of the time-field give the start and
stop times, respectively, for the session. These values are the stop times, respectively, for the session. These values are the
decimal representation of Network Time Protocol (NTP) time values in decimal representation of Network Time Protocol (NTP) time values in
seconds since 1900 [RFC5905]. To convert these values to UNIX time seconds since 1900 [RFC5905]. To convert these values to UNIX time
(UTC), subtract decimal 2208988800. (UTC), subtract decimal 2208988800.
NTP timestamps are elsewhere represented by 64-bit values, which wrap NTP timestamps are elsewhere represented by 64-bit values, which wrap
sometime in the year 2036. Since SDP uses an arbitrary length sometime in the year 2036. Since SDP uses an arbitrary length
decimal representation, this should not cause an issue (SDP decimal representation, this should not cause an issue (SDP
timestamps MUST continue counting seconds since 1900 - NTP will use timestamps MUST continue counting seconds since 1900 - NTP will use
skipping to change at page 18, line 51 skipping to change at page 19, line 8
the <start-time> is also zero, the session is regarded as permanent. the <start-time> is also zero, the session is regarded as permanent.
User interfaces SHOULD strongly discourage the creation of unbounded User interfaces SHOULD strongly discourage the creation of unbounded
and permanent sessions as they give no information about when the and permanent sessions as they give no information about when the
session is actually going to terminate, and so make scheduling session is actually going to terminate, and so make scheduling
difficult. difficult.
The general assumption may be made, when displaying unbounded The general assumption may be made, when displaying unbounded
sessions that have not timed out to the user, that an unbounded sessions that have not timed out to the user, that an unbounded
session will only be active until half an hour from the current time session will only be active until half an hour from the current time
or the session start time, whichever is the later. If behaviour or the session start time, whichever is the later. If behavior other
other than this is required, an end-time SHOULD be given and modified than this is required, an end-time SHOULD be given and modified as
as appropriate when new information becomes available about when the appropriate when new information becomes available about when the
session should really end. session should really end.
Permanent sessions may be shown to the user as never being active Permanent sessions may be shown to the user as never being active
unless there are associated repeat times that state precisely when unless there are associated repeat times that state precisely when
the session will be active. the session will be active.
5.10. Repeat Times ("r=") 5.10. Repeat Times ("r=")
r=<repeat interval> <active duration> <offsets from start-time> r=<repeat interval> <active duration> <offsets from start-time>
skipping to change at page 19, line 28 skipping to change at page 19, line 33
included. For example, if a session is active at 10am on Monday and included. For example, if a session is active at 10am on Monday and
11am on Tuesday for one hour each week for three months, then the 11am on Tuesday for one hour each week for three months, then the
<start-time> in the corresponding "t=" line would be the NTP <start-time> in the corresponding "t=" line would be the NTP
representation of 10am on the first Monday, the <repeat interval> representation of 10am on the first Monday, the <repeat interval>
would be 1 week, the <active duration> would be 1 hour, and the would be 1 week, the <active duration> would be 1 hour, and the
offsets would be zero and 25 hours. The corresponding "t=" line stop offsets would be zero and 25 hours. The corresponding "t=" line stop
time would be the NTP representation of the end of the last session time would be the NTP representation of the end of the last session
three months later. By default, all sub-fields are in seconds, so three months later. By default, all sub-fields are in seconds, so
the "r=" and "t=" lines might be the following: the "r=" and "t=" lines might be the following:
t=3034423619 3042462419 t=3724394400 3730536000 ; Mon 8-Jan-2018 10:00-11:00 UTC
r=604800 3600 0 90000 ; Tues 20-Mar-2018 12:00 UTC
r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours
To make the description more compact, times may also be given in To make the description more compact, times may also be given in
units of days, hours, or minutes. The syntax for these is a number units of days, hours, or minutes. The syntax for these is a number
immediately followed by a single case-sensitive character. immediately followed by a single case-sensitive character.
Fractional units are not allowed -- a smaller unit should be used Fractional units are not allowed -- a smaller unit should be used
instead. The following unit specification characters are allowed: instead. The following unit specification characters are allowed:
d - days (86400 seconds) d - days (86400 seconds)
h - hours (3600 seconds) h - hours (3600 seconds)
m - minutes (60 seconds) m - minutes (60 seconds)
s - seconds (allowed for completeness) s - seconds (allowed for completeness)
Thus, the above session announcement could also have been written: Thus, the above repeat-field could also have been written:
r=7d 1h 0 25h r=7d 1h 0 25h
Monthly and yearly repeats cannot be directly specified with a single Monthly and yearly repeats cannot be directly specified with a single
SDP repeat time; instead, separate time-descriptions should be used SDP repeat time; instead, separate time-descriptions should be used
to explicitly list the session times. to explicitly list the session times.
5.11. Time Zone Adjustment ("z=") 5.11. Time Zone Adjustment ("z=")
z=<adjustment time> <offset> <adjustment time> <offset> .... z=<adjustment time> <offset> <adjustment time> <offset> ....
skipping to change at page 20, line 29 skipping to change at page 20, line 33
Thus, in order to schedule a session that is at the same time winter Thus, in order to schedule a session that is at the same time winter
and summer, it must be possible to specify unambiguously by whose and summer, it must be possible to specify unambiguously by whose
time zone a session is scheduled. To simplify this task for time zone a session is scheduled. To simplify this task for
receivers, we allow the sender to specify the NTP time that a time receivers, we allow the sender to specify the NTP time that a time
zone adjustment happens and the offset from the time when the session zone adjustment happens and the offset from the time when the session
was first scheduled. The "z=" line allows the sender to specify a was first scheduled. The "z=" line allows the sender to specify a
list of these adjustment times and offsets from the base time. list of these adjustment times and offsets from the base time.
An example might be the following: An example might be the following:
z=2882844526 -1h 2898848070 0 t=3724394400 3754123200 ; Mon 8-Jan-2018 10:00 UTC
; Tues 18-Dec-2018 12:00 UTC
r=604800 3600 0 90000 ; 1 week, 1 hour, zero, 25 hours
z=3730928400 -1h 3749680800 0 ; Sun 25-Mar-2018 1:00 UTC,
; offset 1 hour,
; Sun 28-Oct-2018 2:00 UTC, no offset
This specifies that at time 2882844526, the time base by which the This specifies that at time 3730928400 (Sun 25-Mar-2018 1:00 UTC, the
session's repeat times are calculated is shifted back by 1 hour, and onset of British Summer Time) the time base by which the session's
that at time 2898848070, the session's original time base is repeat times are calculated is shifted back by 1 hour, and that at
restored. Adjustments are always relative to the specified start time 3749680800 (Sun 28-Oct-2018 2:00 UTC, the end of British Summer
time -- they are not cumulative. Adjustments apply to all "t=" and Time) the session's original time base is restored. Adjustments are
"r=" lines in a session description. always relative to the specified start time -- they are not
cumulative.
If a session is likely to last several years, it is expected that the If a session is likely to last several years, it is expected that the
session description will be modified periodically rather than session description will be modified periodically rather than
transmit several years' worth of adjustments in one session transmit several years' worth of adjustments in one session
description. description.
5.12. Encryption Keys ("k=") 5.12. Encryption Keys ("k=")
k=<method> k=<method>
k=<method>:<encryption key> k=<method>:<encryption key>
skipping to change at page 23, line 8 skipping to change at page 23, line 18
For RTP, the default is that only the even-numbered ports are used For RTP, the default is that only the even-numbered ports are used
for data with the corresponding one-higher odd ports used for the for data with the corresponding one-higher odd ports used for the
RTCP belonging to the RTP session, and the <number of ports> RTCP belonging to the RTP session, and the <number of ports>
denoting the number of RTP sessions. For example: denoting the number of RTP sessions. For example:
m=video 49170/2 RTP/AVP 31 m=video 49170/2 RTP/AVP 31
would specify that ports 49170 and 49171 form one RTP/RTCP pair would specify that ports 49170 and 49171 form one RTP/RTCP pair
and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the and 49172 and 49173 form the second RTP/RTCP pair. RTP/AVP is the
transport protocol and 31 is the format (see below). If non- transport protocol and 31 is the format (see below). If non-
contiguous ports are required, they must be signalled using a contiguous ports are required, they must be signaled using a
separate attribute (for example, "a=rtcp:" as defined in separate attribute. (There is currently no attribute defined that
[RFC3605]). can accomplish this. The "a=rtcp:" defined in [RFC3605] does not
handle hierarchical encoding.)
If multiple addresses are specified in the "c=" line and multiple If multiple addresses are specified in the "c=" line and multiple
ports are specified in the "m=" line, a one-to-one mapping from ports are specified in the "m=" line, a one-to-one mapping from
port to the corresponding address is implied. For example: port to the corresponding address is implied. For example:
c=IN IP4 233.252.0.1/127/2 c=IN IP4 233.252.0.1/127/2
m=video 49170/2 RTP/AVP 31 m=video 49170/2 RTP/AVP 31
would imply that address 233.252.0.1 is used with ports 49170 and would imply that address 233.252.0.1 is used with ports 49170 and
49171, and address 233.252.0.2 is used with ports 49172 and 49173. 49171, and address 233.252.0.2 is used with ports 49172 and 49173.
skipping to change at page 37, line 7 skipping to change at page 37, line 13
a=quality:10 a=quality:10
This gives a suggestion for the quality of the encoding as an integer This gives a suggestion for the quality of the encoding as an integer
value. The intention of the quality attribute for video is to value. The intention of the quality attribute for video is to
specify a non-default trade-off between frame-rate and still-image specify a non-default trade-off between frame-rate and still-image
quality. For video, the value is in the range 0 to 10, with the quality. For video, the value is in the range 0 to 10, with the
following suggested meaning: following suggested meaning:
10 - the best still-image quality the compression scheme 10 - the best still-image quality the compression scheme
can give. can give.
5 - the default behaviour given no quality suggestion. 5 - the default behavior given no quality suggestion.
0 - the worst still-image quality the codec designer 0 - the worst still-image quality the codec designer
thinks is still usable. thinks is still usable.
6.15. fmtp (format parameters) 6.15. fmtp (format parameters)
Name: fmtp Name: fmtp
Value: fmtp-value Value: fmtp-value
Usage Level: media Usage Level: media
skipping to change at page 38, line 34 skipping to change at page 38, line 44
required to start software on the receiver's system. Software that required to start software on the receiver's system. Software that
parses a session description MUST NOT be able to start other software parses a session description MUST NOT be able to start other software
except that which is specifically configured as appropriate software except that which is specifically configured as appropriate software
to participate in multimedia sessions. It is normally considered to participate in multimedia sessions. It is normally considered
inappropriate for software parsing a session description to start, on inappropriate for software parsing a session description to start, on
a user's system, software that is appropriate to participate in a user's system, software that is appropriate to participate in
multimedia sessions, without the user first being informed that such multimedia sessions, without the user first being informed that such
software will be started and giving the user's consent. Thus, a software will be started and giving the user's consent. Thus, a
session description arriving by session announcement, email, session session description arriving by session announcement, email, session
invitation, or WWW page MUST NOT deliver the user into an interactive invitation, or WWW page MUST NOT deliver the user into an interactive
multimedia session unless the user has explicitly pre-authorised such multimedia session unless the user has explicitly pre-authorized such
action. As it is not always simple to tell whether or not a session action. As it is not always simple to tell whether or not a session
is interactive, applications that are unsure should assume sessions is interactive, applications that are unsure should assume sessions
are interactive. are interactive.
In this specification, there are no attributes that would allow the In this specification, there are no attributes that would allow the
recipient of a session description to be informed to start multimedia recipient of a session description to be informed to start multimedia
tools in a mode where they default to transmitting. Under some tools in a mode where they default to transmitting. Under some
circumstances it might be appropriate to define such attributes. If circumstances it might be appropriate to define such attributes. If
this is done, an application parsing a session description containing this is done, an application parsing a session description containing
such attributes SHOULD either ignore them or inform the user that such attributes SHOULD either ignore them or inform the user that
joining this session will result in the automatic transmission of joining this session will result in the automatic transmission of
multimedia data. The default behaviour for an unknown attribute is multimedia data. The default behavior for an unknown attribute is to
to ignore it. ignore it.
In certain environments, it has become common for intermediary In certain environments, it has become common for intermediary
systems to intercept and analyse session descriptions contained systems to intercept and analyze session descriptions contained
within other signalling protocols. This is done for a range of within other signaling protocols. This is done for a range of
purposes, including but not limited to opening holes in firewalls to purposes, including but not limited to opening holes in firewalls to
allow media streams to pass, or to mark, prioritize, or block traffic allow media streams to pass, or to mark, prioritize, or block traffic
selectively. In some cases, such intermediary systems may modify the selectively. In some cases, such intermediary systems may modify the
session description, for example, to have the contents of the session session description, for example, to have the contents of the session
description match NAT bindings dynamically created. These behaviours description match NAT bindings dynamically created. These behaviors
are NOT RECOMMENDED unless the session description is conveyed in are NOT RECOMMENDED unless the session description is conveyed in
such a manner that allows the intermediary system to conduct proper such a manner that allows the intermediary system to conduct proper
checks to establish the authenticity of the session description, and checks to establish the authenticity of the session description, and
the authority of its source to establish such communication sessions. the authority of its source to establish such communication sessions.
SDP by itself does not include sufficient information to enable these SDP by itself does not include sufficient information to enable these
checks: they depend on the encapsulating protocol (e.g., SIP or checks: they depend on the encapsulating protocol (e.g., SIP or
RTSP). RTSP). Use of some procedures and SDP extensions (e.g., ICE
[RFC5245] and ICE-SIP-SDP [I-D.ietf-mmusic-ice-sip-sdp]) may avoid
the need for intermediaries to modify SDP.
Use of the "k=" line poses a significant security risk, since it Use of the "k=" line poses a significant security risk, since it
conveys session encryption keys in the clear. SDP MUST NOT be used conveys session encryption keys in the clear. SDP MUST NOT be used
to convey keying material, unless it can be guaranteed that the to convey keying material, unless it can be guaranteed that the
channel over which the SDP is delivered is both private and channel over which the SDP is delivered is both private and
authenticated. Moreover, the "k=" line provides no way to indicate authenticated. Moreover, the "k=" line provides no way to indicate
or negotiate cryptographic key algorithms. As it provides for only a or negotiate cryptographic key algorithms. As it provides for only a
single symmetric key, rather than separate keys for confidentiality single symmetric key, rather than separate keys for confidentiality
and integrity, its utility is severely limited. The "k=" line MUST and integrity, its utility is severely limited. The "k=" line MUST
NOT be used, as discussed in Section 5.12. NOT be used, as discussed in Section 5.12.
skipping to change at page 40, line 43 skipping to change at page 41, line 10
Author/Change controller: Author/Change controller:
Authors of RFC XXXX Authors of RFC XXXX
IETF MMUSIC working group delegated from the IESG IETF MMUSIC working group delegated from the IESG
8.2. Registration of Parameters 8.2. Registration of Parameters
This specification establishes and initializes IANA parameter This specification establishes and initializes IANA parameter
registries for seven named SDP sub-fields. Using the terminology in registries for seven named SDP sub-fields. Using the terminology in
the SDP specification Augmented Backus-Naur Form (ABNF), they are the SDP specification Augmented Backus-Naur Form (ABNF), they are
"media", "proto", "fmt", "att-field", "bwtype", "nettype", and "media", "proto", "att-field", "bwtype", "nettype", and "addrtype".
"addrtype".
The contact address for all parameters registered below is: The contact address for all parameters registered below is:
IETF MMUSIC working group <mmusic@ietf.org> IETF MMUSIC working group <mmusic@ietf.org>
8.2.1. Media Types ("media") 8.2.1. Media Types ("media")
The set of media types is intended to be small and SHOULD NOT be The set of media types is intended to be small and SHOULD NOT be
extended except under rare circumstances. The same rules should extended except under rare circumstances. The same rules should
apply for media names as for top-level media types, and where apply for media names as for top-level media types, and where
skipping to change at page 43, line 9 skipping to change at page 43, line 24
specification includes the following information: specification includes the following information:
o Contact Name. o Contact Name.
o Contact Email Address. o Contact Email Address.
o Attribute Name: The name of the attribute that will appear in o Attribute Name: The name of the attribute that will appear in
SDP). This MUST conform to the definition of <att-field>. SDP). This MUST conform to the definition of <att-field>.
o Attribute Syntax: For a value attribute (see clause 5.13), an ABNF o Attribute Syntax: For a value attribute (see clause 5.13), an ABNF
definition of the attribute value <att-value> syntax (See definition of the attribute value <att-value> syntax (see
Section 9) MUST be provided. The syntax MUST follow the rule form Section 9) MUST be provided. The syntax MUST follow the rule form
as per Section 2.2 of [RFC5234] and [RFC7405]. This SHALL define as per Section 2.2 of [RFC5234] and [RFC7405]. This SHALL define
the allowable values that the attribute might take. It MAY also the allowable values that the attribute might take. It MAY also
define an extension method for the addition of future values. For define an extension method for the addition of future values. For
a property attribute, the ABNF definition is omitted as the a property attribute, the ABNF definition is omitted as the
property attribute takes no values. property attribute takes no values.
o Attribute Semantics: For a value attribute, a semantic description o Attribute Semantics: For a value attribute, a semantic description
of the values that the attribute might take MUST be provided. The of the values that the attribute might take MUST be provided. The
usage of a property attribute is described under purpose below. usage of a property attribute is described under purpose below.
skipping to change at page 44, line 43 skipping to change at page 45, line 11
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. Otherwise it is a new attribute.
o Attribute Syntax: The existing rule syntax with the syntax o Attribute Syntax: The existing rule syntax with the syntax
extensions MUST be provided if there is a change to the syntax. A extensions MUST be provided if there is a change to the syntax. A
revision to an existing attribute usage MAY extend the syntax of revision to an existing attribute usage MAY extend the syntax of
an attribute, but MUST be backward compatible. an attribute, but MUST be backward compatible.
o Attribute Semantics: A semantic description of new additional o Attribute Semantics: A semantic description of new additional
attributes values or a semantic extension of existing values. attribute values or a semantic extension of existing values.
Existing attribute values semantics MUST only be extended in a Existing attribute values semantics MUST only be extended in a
backward compatible manner. backward compatible manner.
o Usage Level: Updates MAY only add additional levels. 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 Purpose: MAY be extended according to the updated usage.
o O/A Procedures: MAY be updated in a backward compatible manner o O/A Procedures: MAY be updated in a backward compatible manner
skipping to change at page 54, line 28 skipping to change at page 54, line 43
12.1. Normative References 12.1. Normative References
[E164] International Telecommunication Union, "E.164 : The [E164] International Telecommunication Union, "E.164 : The
international public telecommunication numbering plan", international public telecommunication numbering plan",
ITU Recommendation E.164, November 2010. ITU Recommendation E.164, November 2010.
[I-D.ietf-mmusic-data-channel-sdpneg] [I-D.ietf-mmusic-data-channel-sdpneg]
Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R., Drage, K., Makaraju, M., Stoetzer-Bradler, J., Ejzak, R.,
Marcon, J., and R. Even, "SDP-based Data Channel Marcon, J., and R. Even, "SDP-based Data Channel
Negotiation", draft-ietf-mmusic-data-channel-sdpneg-19 Negotiation", draft-ietf-mmusic-data-channel-sdpneg-20
(work in progress), May 2018. (work in progress), June 2018.
[I-D.ietf-mmusic-ice-sip-sdp]
Petit-Huguenin, M., Nandakumar, S., and A. Keranen,
"Session Description Protocol (SDP) Offer/Answer
procedures for Interactive Connectivity Establishment
(ICE)", draft-ietf-mmusic-ice-sip-sdp-21 (work in
progress), June 2018.
[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-17 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17
(work in progress), February 2018. (work in progress), February 2018.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", [RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
<https://www.rfc-editor.org/info/rfc1034>. <https://www.rfc-editor.org/info/rfc1034>.
 End of changes. 40 change blocks. 
63 lines changed or deleted 84 lines changed or added

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