draft-ietf-mmusic-rfc4566bis-26.txt   draft-ietf-mmusic-rfc4566bis-27.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: November 1, 2018 C. Perkins Expires: November 22, 2018 C. Perkins
University of Glasgow University of Glasgow
M. Handley M. Handley
UCL UCL
April 30, 2018 May 21, 2018
SDP: Session Description Protocol SDP: Session Description Protocol
draft-ietf-mmusic-rfc4566bis-26 draft-ietf-mmusic-rfc4566bis-27
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 November 1, 2018. This Internet-Draft will expire on November 22, 2018.
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 47 skipping to change at page 2, line 47
5.1. Protocol Version ("v=") . . . . . . . . . . . . . . . . . 11 5.1. Protocol Version ("v=") . . . . . . . . . . . . . . . . . 11
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 Zones ("z=") . . . . . . . . . . . . . . . . . . . . 19 5.11. Time Zone Adjustment ("z=") . . . . . . . . . . . . . . . 20
5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 20 5.12. Encryption Keys ("k=") . . . . . . . . . . . . . . . . . 20
5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 20 5.13. Attributes ("a=") . . . . . . . . . . . . . . . . . . . . 21
5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 21 5.14. Media Descriptions ("m=") . . . . . . . . . . . . . . . . 22
6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 24 6. SDP Attributes . . . . . . . . . . . . . . . . . . . . . . . 24
6.1. cat (category) . . . . . . . . . . . . . . . . . . . . . 24 6.1. cat (category) . . . . . . . . . . . . . . . . . . . . . 25
6.2. keywds (keywords) . . . . . . . . . . . . . . . . . . . . 25 6.2. keywds (keywords) . . . . . . . . . . . . . . . . . . . . 25
6.3. tool . . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.3. tool . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.4. ptime (packet time) . . . . . . . . . . . . . . . . . . . 26 6.4. ptime (packet time) . . . . . . . . . . . . . . . . . . . 26
6.5. maxptime (maximum packet time) . . . . . . . . . . . . . 26 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) . . . . . . . . . . . . . . . 29 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) . . . . . . . . . . . . . . . . 30
6.7.4. inactive . . . . . . . . . . . . . . . . . . . . . . 30 6.7.4. inactive . . . . . . . . . . . . . . . . . . . . . . 31
6.8. orient (orientation) . . . . . . . . . . . . . . . . . . 31 6.8. orient (orientation) . . . . . . . . . . . . . . . . . . 31
6.9. type (conference type) . . . . . . . . . . . . . . . . . 31 6.9. type (conference type) . . . . . . . . . . . . . . . . . 32
6.10. charset (character set) . . . . . . . . . . . . . . . . . 32 6.10. charset (character set) . . . . . . . . . . . . . . . . . 33
6.11. sdplang (SDP language) . . . . . . . . . . . . . . . . . 33 6.11. sdplang (SDP language) . . . . . . . . . . . . . . . . . 34
6.12. lang (language) . . . . . . . . . . . . . . . . . . . . . 34 6.12. lang (language) . . . . . . . . . . . . . . . . . . . . . 34
6.13. framerate (frame rate) . . . . . . . . . . . . . . . . . 35 6.13. framerate (frame rate) . . . . . . . . . . . . . . . . . 36
6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 36 6.14. quality . . . . . . . . . . . . . . . . . . . . . . . . . 36
6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 36 6.15. fmtp (format parameters) . . . . . . . . . . . . . . . . 37
7. Security Considerations . . . . . . . . . . . . . . . . . . . 37 7. Security Considerations . . . . . . . . . . . . . . . . . . . 37
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 . . . . . . . . . . . . . . . 40
8.2.1. Media Types ("media") . . . . . . . . . . . . . . . . 40 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") . . . . . . . . . . . . . . . . 41 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") . . . . . . . . . . . 44 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") . . . . . . . . . . . . . 45 8.2.7. Address Types ("addrtype") . . . . . . . . . . . . . 46
8.2.8. Registration Procedure . . . . . . . . . . . . . . . 45 8.2.8. Registration Procedure . . . . . . . . . . . . . . . 46
8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 46 8.3. Encryption Key Access Methods . . . . . . . . . . . . . . 47
8.4. Reorganization of the nettype Registry . . . . . . . . . 46 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 . . . . . . . . . . . . . . . . . . . . . . . . . 47 9. SDP Grammar . . . . . . . . . . . . . . . . . . . . . . . . . 48
10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 53 10. Summary of Changes from RFC 4566 . . . . . . . . . . . . . . 53
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 53 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 54
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
12.1. Normative References . . . . . . . . . . . . . . . . . . 53 12.1. Normative References . . . . . . . . . . . . . . . . . . 54
12.2. Informative References . . . . . . . . . . . . . . . . . 55 12.2. Informative References . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 57 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 58
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 8, line 29 skipping to change at page 8, line 29
announcements that are of interest from those that are not. SDP announcements 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 fields when desired. Internationalization only applies to free-text sub-
(session name and background information), and not to SDP as a whole. fields (session name and background information), and not to SDP as a
whole.
5. SDP Specification 5. SDP Specification
An SDP description is denoted by the media type "application/sdp" An SDP description is denoted by the media type "application/sdp"
(See Section 8). (See Section 8).
An SDP description is entirely textual. SDP field names and An SDP description is entirely textual. SDP field names and
attribute names use only the US-ASCII subset of UTF-8, but textual attribute names use only the US-ASCII subset of UTF-8, but textual
fields and attribute values MAY use the full ISO 10646 character set fields and attribute values MAY use the full ISO 10646 character set
in UTF-8 encoding, or some other character set defined by the in UTF-8 encoding, or some other character set defined by the
skipping to change at page 9, line 15 skipping to change at page 9, line 16
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 announcements 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 fields delimited by a single general, <value> is either a number of sub-fields delimited by a
space character or a free format string, and is case-significant single space character or a free format string, and is case-
unless a specific field defines otherwise. Whitespace separators significant unless a specific field defines otherwise. Whitespace
MUST NOT be used on either side of the "=" sign, however, the value separators MUST NOT be used on either side of the "=" sign, however,
can contain a leading whitespace as part of its syntax, i.e., that the value can contain a leading whitespace as part of its syntax,
whitespace is part of the value. i.e., that whitespace is part of the value.
An SDP description consists of a session-level section followed by An SDP description consists of a session-level section followed by
zero or more media descriptions. The session-level section starts zero or more media descriptions. The session-level section starts
with a "v=" line and continues to the first media description (or the with a "v=" line and continues to the first media description (or the
end of the whole description, whichever comes first). Each media end of the whole description, whichever comes first). Each media
description starts with an "m=" line and continues to the next media description starts with an "m=" line and continues to the next media
description or the end of the whole session description - whichever description or the end of the whole session description - whichever
comes first. In general, session-level values are the default for comes first. In general, session-level values are the default for
all media unless overridden by an equivalent media-level value. all media unless overridden by an equivalent media-level value.
skipping to change at page 10, line 16 skipping to change at page 10, line 16
v= (protocol version) v= (protocol version)
o= (originator and session identifier) o= (originator and session identifier)
s= (session name) s= (session name)
i=* (session information) i=* (session information)
u=* (URI of description) u=* (URI of description)
e=* (email address) e=* (email address)
p=* (phone number) p=* (phone number)
c=* (connection information -- not required if included in c=* (connection information -- not required if included in
all media descriptions) all media descriptions)
b=* (zero or more bandwidth information lines) b=* (zero or more bandwidth information lines)
One or more time descriptions ("t=" and "r=" lines; see below) One or more time descriptions:
z=* (time zone adjustments) ("t=", "r=" and "z=" lines; see below)
k=* (encryption key) k=* (encryption key)
a=* (zero or more session attribute lines) a=* (zero or more session attribute lines)
Zero or more media descriptions Zero or more media descriptions
Time description Time description
t= (time the session is active) t= (time the session is active)
r=* (zero or more repeat times) r=* (zero or more repeat times)
z= (optional time zone offset line)
Media description, if present Media description, if present
m= (media name and transport address) m= (media name and transport address)
i=* (media title) i=* (media title)
c=* (connection information -- optional if included at c=* (connection information -- optional if included at
session level) session level)
b=* (zero or more bandwidth information lines) b=* (zero or more bandwidth information lines)
k=* (encryption key) k=* (encryption key)
a=* (zero or more media attribute lines) a=* (zero or more media attribute lines)
skipping to change at page 11, line 24 skipping to change at page 11, line 24
e=j.doe@example.com (Jane Doe) e=j.doe@example.com (Jane Doe)
c=IN IP4 233.252.0.2 c=IN IP4 233.252.0.2
t=2873397496 2873404696 t=2873397496 2873404696
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 fields such as the session name and information are octet Text containing fields such as the session name and information are
strings that may contain any octet with the exceptions of 0x00 (Nul), octet strings that may contain any octet with the exceptions of 0x00
0x0a (ASCII newline), and 0x0d (ASCII carriage return). The sequence (Nul), 0x0a (ASCII newline), and 0x0d (ASCII carriage return). The
CRLF (0x0d0a) is used to end a record, although parsers SHOULD be sequence CRLF (0x0d0a) is used to end a record, although parsers
tolerant and also accept records terminated with a single newline SHOULD be tolerant and also accept records terminated with a single
character. If the "a=charset" attribute is not present, these octet newline character. If the "a=charset" attribute is not present,
strings MUST be interpreted as containing ISO-10646 characters in these octet strings MUST be interpreted as containing ISO-10646
UTF-8 encoding (the presence of the "a=charset" attribute may force characters in UTF-8 encoding (the presence of the "a=charset"
some fields to be interpreted differently). attribute may force some fields to be interpreted 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).
5.1. Protocol Version ("v=") 5.1. Protocol Version ("v=")
v=0 v=0
The "v=" line gives the version of the Session Description Protocol. The "v=" line (version-field) gives the version of the Session
This memo defines version 0. There is no minor version number. Description Protocol. This memo defines version 0. There is no
minor version number.
5.2. Origin ("o=") 5.2. Origin ("o=")
o=<username> <sess-id> <sess-version> <nettype> <addrtype> o=<username> <sess-id> <sess-version> <nettype> <addrtype>
<unicast-address> <unicast-address>
The "o=" line gives the originator of the session (her username and The "o=" line (origin-field) gives the originator of the session (her
the address of the user's host) plus a session identifier and version username and the address of the user's host) plus a session
number: identifier and version number:
<username> is the user's login on the originating host, or it is "-" <username> is the user's login on the originating host, or it is "-"
if the originating host does not support the concept of user IDs. if the originating host does not support the concept of user IDs.
The <username> MUST NOT contain spaces. The <username> MUST NOT contain spaces.
<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
skipping to change at page 13, line 20 skipping to change at page 13, line 20
For privacy reasons, it is sometimes desirable to obfuscate the For privacy reasons, it is sometimes desirable to obfuscate the
username and IP address of the session originator. If this is a username and IP address of the session originator. If this is a
concern, an arbitrary <username> and private <unicast-address> MAY be concern, an arbitrary <username> and private <unicast-address> MAY be
chosen to populate the "o=" line, provided that these are selected in chosen to populate the "o=" line, provided that these are selected in
a manner that does not affect the global uniqueness of the field. a manner that does not affect the global uniqueness of the field.
5.3. Session Name ("s=") 5.3. Session Name ("s=")
s=<session name> s=<session name>
The "s=" line is the textual session name. There MUST be one and The "s=" line (session-name-field) is the textual session name.
only one "s=" line per session description. The "s=" line MUST NOT There MUST be one and only one "s=" line per session description.
be empty and SHOULD contain ISO 10646 characters (but see also the The "s=" line MUST NOT be empty and SHOULD contain ISO 10646
"a=charset" attribute). If a session has no meaningful name, the "s= characters (but see also the "a=charset" attribute). If a session
" line SHOULD be used (i.e., a single space as the session name). has no meaningful name, the "s= " line SHOULD be used (i.e., a single
space as the session name).
5.4. Session Information ("i=") 5.4. Session Information ("i=")
i=<session information> i=<session information>
The "i=" line provides textual information about the session. There The "i=" line (information-field) provides textual information about
MUST be at most one session-level "i=" line per session description, the session. There MUST be at most one session-level "i=" line per
and at most one "i=" line in each media description. Unless a media session description, and at most one "i=" line in each media
level "i= line is provided, the session-level "i= line applies to description. Unless a media level "i=" line is provided, the
that media description. If the "a=charset" attribute is present, it session-level "i=" line applies to that media description. If the
specifies the character set used in the "i=" line. If the "a=charset" attribute is present, it specifies the character set used
"a=charset" attribute is not present, the "i=" line MUST contain ISO in the "i=" line. If the "a=charset" attribute is not present, the
10646 characters in UTF-8 encoding. "i=" line MUST contain ISO 10646 characters in UTF-8 encoding.
At most one "i=" line can be used for each media description. In At most one "i=" line can be used for each media description. In
media definitions, "i=" lines are primarily intended for labelling media definitions, "i=" lines are primarily intended for labelling
media streams. As such, they are most likely to be useful when a media streams. As such, they are most likely to be useful when a
single session has more than one distinct media stream of the same single session has more than one distinct media stream of the same
media type. An example would be two different whiteboards, one for media type. An example would be two different whiteboards, one for
slides and one for feedback and questions. slides and one for feedback and questions.
The "i=" line is intended to provide a free-form human-readable The "i=" line is intended to provide a free-form human-readable
description of the session or the purpose of a media stream. It is description of the session or the purpose of a media stream. It is
not suitable for parsing by automata. not suitable for parsing by automata.
5.5. URI ("u=") 5.5. URI ("u=")
u=<uri> u=<uri>
A URI is a Uniform Resource Identifier as used by WWW clients The "u=" line (uri-field) provides URI (Uniform Resource Identifier)
[RFC3986]. The URI should be a pointer to additional information as used by WWW clients [RFC3986]. The URI should be a pointer to
about the session. This line is OPTIONAL. No more than one URI line additional information about the session. This line is OPTIONAL. No
is allowed per session description. more than one "u=" line is allowed per session description.
5.6. Email Address and Phone Number ("e=" and "p=") 5.6. Email Address and Phone Number ("e=" and "p=")
e=<email-address> e=<email-address>
p=<phone-number> p=<phone-number>
The "e=" and "p=" lines specify contact information for the person The "e=" line (email-field) and "p=" line (phone-field) specify
responsible for the session. This is not necessarily the same person contact information for the person responsible for the session. This
that created the session description. is not necessarily the same person that created the session
description.
Inclusion of an email address or phone number is OPTIONAL. Inclusion of an email address or phone number is OPTIONAL.
If an email address or phone number is present, it MUST be specified If an email address or phone number is present, it MUST be specified
before the first media description. More than one email or phone before the first media description. More than one email or phone
line can be given for a session description. line can be given for a session description.
Phone numbers SHOULD be given in the form of an international public Phone numbers SHOULD be given in the form of an international public
telecommunication number (see ITU-T Recommendation E.164 [E164]) telecommunication number (see ITU-T Recommendation E.164 [E164])
preceded by a "+". Spaces and hyphens may be used to split up a preceded by a "+". Spaces and hyphens may be used to split up a
skipping to change at page 15, line 9 skipping to change at page 15, line 9
e=Jane Doe <j.doe@example.com> e=Jane Doe <j.doe@example.com>
The free text string SHOULD be in the ISO-10646 character set with The free text string SHOULD be in the ISO-10646 character set with
UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if UTF-8 encoding, or alternatively in ISO-8859-1 or other encodings if
the appropriate session-level "a=charset" attribute is set. the appropriate session-level "a=charset" attribute is set.
5.7. Connection Information ("c=") 5.7. Connection Information ("c=")
c=<nettype> <addrtype> <connection-address> c=<nettype> <addrtype> <connection-address>
The "c=" line contains connection data. The "c=" line (connection-field) contains connection data.
A session description MUST contain either at least one "c=" line in A session description MUST contain either at least one "c=" line in
each media description or a single "c=" line at the session level. each media description or a single "c=" line at the session level.
It MAY contain a single session-level "c=" line and additional "c=" It MAY contain a single session-level "c=" line and additional "c="
line(s) per media description, in which case the per-media values line(s) per media description, in which case the per-media values
override the session-level settings for the respective media. override the session-level settings for the respective media.
The first sub-field ("<nettype>") is the network type, which is a The first sub-field ("<nettype>") is the network type, which is a
text string giving the type of network. Initially, "IN" is defined text string giving the type of network. Initially, "IN" is defined
to have the meaning "Internet", but other values MAY be registered in to have the meaning "Internet", but other values MAY be registered in
the future (see Section 8). the future (see Section 8).
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> 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 and 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
skipping to change at page 16, line 50 skipping to change at page 16, line 50
Similarly, an IP6 example would be: Similarly, an IP6 example would be:
c=IN IP6 FF15::101/3 c=IN IP6 FF15::101/3
which is semantically equivalent to: which is semantically equivalent to:
c=IN IP6 FF15::101 c=IN IP6 FF15::101
c=IN IP6 FF15::102 c=IN IP6 FF15::102
c=IN IP6 FF15::103 c=IN IP6 FF15::103
(remembering that the TTL field is not present in IP6 multicast). (remembering that the TTL sub-field is not present in IP6 multicast).
Multiple addresses or "c=" lines MAY be specified on a per media Multiple addresses or "c=" lines MAY be specified on a per media
description basis only if they provide multicast addresses for description basis only if they provide multicast addresses for
different layers in a hierarchical or layered encoding scheme. They different layers in a hierarchical or layered encoding scheme. They
MUST NOT be specified for a session-level "c=" line. MUST NOT be specified for a session-level "c=" line.
The slash notation for multiple addresses described above MUST NOT be The slash notation for multiple addresses described above MUST NOT be
used for IP unicast addresses. used for IP unicast addresses.
5.8. Bandwidth Information ("b=") 5.8. Bandwidth Information ("b=")
b=<bwtype>:<bandwidth> b=<bwtype>:<bandwidth>
This OPTIONAL line denotes the proposed bandwidth to be used by the The OPTIONAL "b=" line (bandwidth-field) denotes the proposed
session or media description. The <bwtype> is an alphanumeric bandwidth to be used by the session or media description. The
modifier giving the meaning of the <bandwidth> figure. Two values <bwtype> is an alphanumeric modifier giving the meaning of the
are defined in this specification, but other values MAY be registered <bandwidth> figure. Two values are defined in this specification,
in the future (see Section 8 and [RFC3556], [RFC3890]): but other values MAY be registered in the future (see Section 8 and
[RFC3556], [RFC3890]):
CT If the bandwidth of a session is different from the bandwidth CT If the bandwidth of a session is different from the bandwidth
implicit from the scope, a "b=CT:..." line SHOULD be supplied for implicit from the scope, a "b=CT:..." line SHOULD be supplied for
the session giving the proposed upper limit to the bandwidth used the session giving the proposed upper limit to the bandwidth used
(the "conference total" bandwidth). Similarly, if the bandwidth (the "conference total" bandwidth). Similarly, if the bandwidth
of bundled media streams in an m line is different from the of bundled media streams in an m line is different from the
implicit value from the scope, a "b=CT:..." line SHOULD be implicit value from the scope, a "b=CT:..." line SHOULD be
supplied in the media level. The primary purpose of this is to supplied in the media level. The primary purpose of this is to
give an approximate idea as to whether two or more sessions (or give an approximate idea as to whether two or more sessions (or
bundled media streams) can coexist simultaneously. Note that CT bundled media streams) can coexist simultaneously. Note that CT
skipping to change at page 17, line 48 skipping to change at page 17, line 49
gives the RTP "session bandwidth" as defined in Section 6.2 of gives the RTP "session bandwidth" as defined in Section 6.2 of
[RFC3550]. Note that AS gives a bandwidth figure for a single [RFC3550]. Note that AS gives a bandwidth figure for a single
media at a single endpoint, although there may be many endpoints media at a single endpoint, although there may be many endpoints
sending simultaneously. sending simultaneously.
A prefix "X-" is defined for <bwtype> names. This is intended for A prefix "X-" is defined for <bwtype> names. This is intended for
experimental purposes only. For example: experimental purposes only. For example:
b=X-YZ:128 b=X-YZ:128
Use of the "X-" prefix is NOT RECOMMENDED: instead new <bwtype> names Use of the "X-" prefix is NOT RECOMMENDED: instead new (non "X-"
SHOULD be registered with IANA in the standard namespace. SDP prefix) <bwtype> names SHOULD be defined, and then MUST be registered
parsers MUST ignore bandwidth fields with unknown <bwtype> names. with IANA in the standard namespace. SDP parsers MUST ignore
The <bwtype> names MUST be alphanumeric and, although no length limit bandwidth fields with unknown <bwtype> names. The <bwtype> names
is given, it is recommended that they be short. MUST be alphanumeric and, although no length limit is given, it is
recommended that they be short.
The <bandwidth> is interpreted as kilobits per second by default The <bandwidth> is interpreted as kilobits per second by default
(including the transport and network-layer but not the link-layer (including the transport and network-layer but not the link-layer
overhead). The definition of a new <bwtype> modifier MAY specify overhead). The definition of a new <bwtype> modifier MAY specify
that the bandwidth is to be interpreted in some alternative unit (the that the bandwidth is to be interpreted in some alternative unit (the
"CT" and "AS" modifiers defined in this memo use the default units). "CT" and "AS" modifiers defined in this memo use the default units).
5.9. Time Active ("t=") 5.9. Time Active ("t=")
t=<start-time> <stop-time> t=<start-time> <stop-time>
The "t=" lines specify the start and stop times for a session. A "t=" line (time-field) initiates a time description that specifies
Multiple "t=" lines MAY be used if a session is active at multiple the start and stop times for a session. Multiple time descriptions
irregularly spaced times; each additional "t=" line specifies an MAY be used if a session is active at multiple irregularly spaced
additional period of time for which the session will be active. If times; each additional time description specifies additional periods
the session is active at regular repeat times, an "r=" line (see of time for which the session will be active. If the session is
below) should be used in addition to, and following, a "t=" line -- active at regular repeat times, a repeat description, initiated by an
in which case the "t=" line specifies the start and stop times of the "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
entire repeat sequence. entire repeat sequence.
The first and second sub-fields give the start and stop times, The first and second sub-fields of the time-field give the start and
respectively, for the session. These values are the decimal stop times, respectively, for the session. These values are the
representation of Network Time Protocol (NTP) time values in seconds decimal representation of Network Time Protocol (NTP) time values in
since 1900 [RFC5905]. To convert these values to UNIX time (UTC), seconds since 1900 [RFC5905]. To convert these values to UNIX time
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
the value modulo the 64-bit limit). the value modulo the 64-bit limit).
If the <stop-time> is set to zero, then the session is not bounded, If the <stop-time> is set to zero, then the session is not bounded,
though it will not become active until after the <start-time>. If though it will not become active until after the <start-time>. If
the <start-time> is also zero, the session is regarded as permanent. the <start-time> is also zero, the session is regarded as permanent.
skipping to change at page 19, line 13 skipping to change at page 19, line 16
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>
An "r=" line specifies repeat times for a session. For example, if a An"r=" line (repeat-field) specifies repeat times for a session. If
session is active at 10am on Monday and 11am on Tuesday for one hour needed to express complex schedules, multiple repeat-fields may be
each week for three months, then the <start-time> in the included. For example, if a session is active at 10am on Monday and
corresponding "t=" line would be the NTP representation of 10am on 11am on Tuesday for one hour each week for three months, then the
the first Monday, the <repeat interval> would be 1 week, the <active <start-time> in the corresponding "t=" line would be the NTP
duration> would be 1 hour, and the offsets would be zero and 25 representation of 10am on the first Monday, the <repeat interval>
hours. The corresponding "t=" line stop time would be the NTP would be 1 week, the <active duration> would be 1 hour, and the
representation of the end of the last session three months later. By offsets would be zero and 25 hours. The corresponding "t=" line stop
default, all fields are in seconds, so the "r=" and "t=" lines might time would be the NTP representation of the end of the last session
be the following: three months later. By default, all sub-fields are in seconds, so
the "r=" and "t=" lines might be the following:
t=3034423619 3042462419 t=3034423619 3042462419
r=604800 3600 0 90000 r=604800 3600 0 90000
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 session announcement 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 "t=" lines should be used to SDP repeat time; instead, separate time-descriptions should be used
explicitly list the session times. to explicitly list the session times.
5.11. Time Zones ("z=") 5.11. Time Zone Adjustment ("z=")
z=<adjustment time> <offset> <adjustment time> <offset> .... z=<adjustment time> <offset> <adjustment time> <offset> ....
This field is an optional modifier to the Repeat Times ("r=") field. A "z=" line (zone-field) is an optional modifier to the repeat-fields
It does not apply to any other fields. it immediately follows. It does not apply to any other fields.
To schedule a repeated session that spans a change from daylight To schedule a repeated session that spans a change from daylight
saving time to standard time or vice versa, it is necessary to saving time to standard time or vice versa, it is necessary to
specify offsets from the base time. This is required because specify offsets from the base time. This is required because
different time zones change time at different times of day, different different time zones change time at different times of day, different
countries change to or from daylight saving time on different dates, countries change to or from daylight saving time on different dates,
and some countries do not have daylight saving time at all. and some countries do not have daylight saving time at all.
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
skipping to change at page 20, line 41 skipping to change at page 20, line 48
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>
The "k=" line is obsolete and MUST NOT be used. It is included in The "k=" line (key-field) is obsolete and MUST NOT be used. It is
this document for legacy reasons. One MUST NOT include a "k=" line included in this document for legacy reasons. One MUST NOT include a
in an SDP, and MUST discard it if it is received in an SDP. "k=" line in an SDP, and MUST discard it if it is received in an SDP.
5.13. Attributes ("a=") 5.13. Attributes ("a=")
a=<attribute> a=<attribute>
a=<attribute>:<value> a=<attribute>:<value>
Attributes are the primary means for extending SDP. Attributes may Attributes are the primary means for extending SDP. Attributes may
be defined to be used as "session-level" attributes, "media-level" be defined to be used as "session-level" attributes, "media-level"
attributes, or both. attributes, or both.
A media description may have any number of attributes ("a=" lines) A media description may have any number of "a=" lines (attribute-
that are media description specific. These are referred to as fields) that are media description specific. These are referred to
"media-level" attributes and add information about the media as "media-level" attributes and add information about the media
description. Attribute lines can also be added before the first description. Attribute fields can also be added before the first
media description; these "session-level" attributes convey additional media description; these "session-level" attributes convey additional
information that applies to the session as a whole rather than to information that applies to the session as a whole rather than to
individual media descriptions. individual media descriptions.
Attribute lines may be of two forms: Attribute fields may be of two forms:
o A property attribute is simply of the form "a=<attribute>". These o A property attribute is simply of the form "a=<attribute>". These
are binary attributes, and the presence of the attribute conveys are binary attributes, and the presence of the attribute conveys
that the attribute is a property of the session. An example might that the attribute is a property of the session. An example might
be "a=recvonly". be "a=recvonly".
o A value attribute is of the form "a=<attribute>:<value>". For o A value attribute is of the form "a=<attribute>:<value>". For
example, a whiteboard could have the value attribute example, a whiteboard could have the value attribute
"a=orient:landscape" "a=orient:landscape"
skipping to change at page 21, line 50 skipping to change at page 22, line 10
Attributes MUST be registered with IANA (see Section 8). If an Attributes MUST be registered with IANA (see Section 8). If an
attribute is received that is not understood, it MUST be ignored by attribute is received that is not understood, it MUST be ignored by
the receiver. the receiver.
5.14. Media Descriptions ("m=") 5.14. Media Descriptions ("m=")
m=<media> <port> <proto> <fmt> ... m=<media> <port> <proto> <fmt> ...
A session description may contain a number of media descriptions. A session description may contain a number of media descriptions.
Each media description starts with an "m=" line (media field) and is Each media description starts with an "m=" line (media-field) and is
terminated by either the next "m=" line or by the end of the session terminated by either the next "m=" line or by the end of the session
description. A media field has several sub-fields: description. A media field has several sub-fields:
<media> is the media type. This document defines the values <media> is the media type. This document defines the values
"audio", "video", "text", "application", and "message". This list "audio", "video", "text", "application", and "message". This list
is extended by other memos and may be further extended by is extended by other memos and may be further extended by
additional memos registering media types in the future (see additional memos registering media types in the future (see
Section 8). For example, [RFC6466] defined the "image" media Section 8). For example, [RFC6466] defined the "image" media
type. type.
skipping to change at page 23, line 24 skipping to change at page 23, line 31
This document provides no semantics for using multiple "m=" lines This document provides no semantics for using multiple "m=" lines
using the same transport address. This implies that, unlike using the same transport address. This implies that, unlike
limited past practice, there is no implicit grouping defined by limited past practice, there is no implicit grouping defined by
such means and an explicit grouping framework (for example, such means and an explicit grouping framework (for example,
[RFC5888]) should instead be used to express the intended [RFC5888]) should instead be used to express the intended
semantics. Such semantics may alo be added as extensions. For semantics. Such semantics may alo be added as extensions. For
instance, see [I-D.ietf-mmusic-sdp-bundle-negotiation]. instance, see [I-D.ietf-mmusic-sdp-bundle-negotiation].
<proto> is the transport protocol. The meaning of the transport <proto> is the transport protocol. The meaning of the transport
protocol is dependent on the address type field in the relevant protocol is dependent on the address type sub-field in the
"c=" line. Thus a "c=" field of IP4 indicates that the transport relevant "c=" line. Thus a "c=" field of IP4 indicates that the
protocol runs over IP4. The following transport protocols are transport protocol runs over IP4. The following transport
defined, but may be extended through registration of new protocols protocols are defined, but may be extended through registration of
with IANA (see Section 8): new protocols with IANA (see Section 8):
* udp: denotes that the data is transported directly in UDP with * udp: denotes that the data is transported directly in UDP with
no additional framing. no additional framing.
* RTP/AVP: denotes RTP [RFC3550] used under the RTP Profile for * RTP/AVP: denotes RTP [RFC3550] used under the RTP Profile for
Audio and Video Conferences with Minimal Control [RFC3551] Audio and Video Conferences with Minimal Control [RFC3551]
running over UDP. running over UDP.
* RTP/SAVP: denotes the Secure Real-time Transport Protocol * RTP/SAVP: denotes the Secure Real-time Transport Protocol
[RFC3711] running over UDP. [RFC3711] running over UDP.
skipping to change at page 24, line 22 skipping to change at page 24, line 28
encoding name that identifies the payload format. The "a=fmtp:" encoding name that identifies the payload format. The "a=fmtp:"
attribute MAY be used to specify format parameters (see attribute MAY be used to specify format parameters (see
Section 6). Section 6).
If the <proto> sub-field is "udp" the <fmt> sub-fields MUST If the <proto> sub-field is "udp" the <fmt> sub-fields MUST
reference a media type describing the format under the "audio", reference a media type describing the format under the "audio",
"video", "text", "application", or "message" top-level media "video", "text", "application", or "message" top-level media
types. The media type registration SHOULD define the packet types. The media type registration SHOULD define the packet
format for use with UDP transport. format for use with UDP transport.
For media using other transport protocols, the <fmt> field is For media using other transport protocols, the <fmt> sub-field is
protocol specific. Rules for interpretation of the <fmt> sub- protocol specific. Rules for interpretation of the <fmt> sub-
field MUST be defined when registering new protocols (see field MUST be defined when registering new protocols (see
Section 8.2.2). Section 8.2.2).
Section 3 of [RFC4855] states that the payload format (encoding) Section 3 of [RFC4855] states that the payload format (encoding)
names defined in the RTP Profile are commonly shown in upper case, names defined in the RTP Profile are commonly shown in upper case,
while media subtype names are commonly shown in lower case. It while media subtype names are commonly shown in lower case. It
also states that both of these names are case-insensitive in both also states that both of these names are case-insensitive in both
places, similar to parameter names which are case-insensitive both places, similar to parameter names which are case-insensitive both
in media type strings and in the default mapping to the SDP a=fmtp in media type strings and in the default mapping to the SDP a=fmtp
skipping to change at page 40, line 17 skipping to change at page 40, line 40
Intended usage: COMMON Intended usage: COMMON
Restrictions on usage: None Restrictions on usage: None
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
There are seven field names that are registered with IANA. Using the This specification establishes and initializes IANA parameter
terminology in the SDP specification Augmented Backus-Naur Form registries for seven named SDP sub-fields. Using the terminology in
(ABNF), they are "media", "proto", "fmt", "att-field", "bwtype", the SDP specification Augmented Backus-Naur Form (ABNF), they are
"nettype", and "addrtype". "media", "proto", "fmt", "att-field", "bwtype", "nettype", and
"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 41, line 7 skipping to change at page 41, line 34
they still remain valid media type capabilities for a SIP user agent they still remain valid media type capabilities for a SIP user agent
as defined in [RFC3840]. If these media types are considered useful as defined in [RFC3840]. If these media types are considered useful
in the future, a Standards Track RFC MUST be produced to document in the future, a Standards Track RFC MUST be produced to document
their use. Until that is done, applications SHOULD NOT use these their use. Until that is done, applications SHOULD NOT use these
types and SHOULD NOT declare support for them in SIP capabilities types and SHOULD NOT declare support for them in SIP capabilities
declarations (even though they exist in the registry created by declarations (even though they exist in the registry created by
[RFC3840]). Also note that [RFC6466] defined the "image" media type. [RFC3840]). Also note that [RFC6466] defined the "image" media type.
8.2.2. Transport Protocols ("proto") 8.2.2. Transport Protocols ("proto")
The "proto" field describes the transport protocol used. The The "proto" sub-field describes the transport protocol used. The
registration procedure for this field is "RFC Required". registration procedure for this registry is "RFC Required".
This document registers two values: "RTP/AVP" is a reference to This document registers two values: "RTP/AVP" is a reference to
[RFC3550] used under the RTP Profile for Audio and Video Conferences [RFC3550] used under the RTP Profile for Audio and Video Conferences
with Minimal Control [RFC3551] running over UDP/IP, and "udp" with Minimal Control [RFC3551] running over UDP/IP, and "udp"
indicates direct use of the UDP protocol. indicates direct use of the UDP protocol.
New transport protocols MAY be defined, and SHOULD be registered with New transport protocols MAY be defined, and MUST be registered with
IANA. Registrations MUST reference an RFC describing the protocol. IANA. Registrations MUST reference an RFC describing the protocol.
Such an RFC MAY be Experimental or Informational, although it is Such an RFC MAY be Experimental or Informational, although it is
preferable that it be Standards Track. The RFC defining a new preferable that it be Standards Track. The RFC defining a new
protocol MUST define the rules by which the "fmt" (see below) protocol MUST define the rules by which the "fmt" (see below)
namespace is managed. namespace is managed.
"proto" names starting with "RTP/" MUST only be used for defining "proto" names starting with "RTP/" MUST only be used for defining
transport protocols that are profiles of the RTP protocol. For transport protocols that are profiles of the RTP protocol. For
example, a profile whose short name is "XYZ" would be denoted by a example, a profile whose short name is "XYZ" would be denoted by a
"proto" field of "RTP/XYZ". "proto" sub-field of "RTP/XYZ".
8.2.3. Media Formats ("fmt") 8.2.3. Media Formats ("fmt")
Each transport protocol, defined by the "proto" field, has an Each transport protocol, defined by the "proto" sub-field, has an
associated "fmt" namespace that describes the media formats that may associated "fmt" namespace that describes the media formats that may
be conveyed by that protocol. Formats cover all the possible be conveyed by that protocol. Formats cover all the possible
encodings that could be transported in a multimedia session. encodings that could be transported in a multimedia session.
RTP payload formats under the "RTP/AVP" and other "RTP/*" profiles RTP payload formats under the "RTP/AVP" and other "RTP/*" profiles
MUST use the payload type number as their "fmt" value. If the MUST use the payload type number as their "fmt" value. If the
payload type number is dynamically assigned by this session payload type number is dynamically assigned by this session
description, an additional "rtpmap" attribute MUST be included to description, an additional "rtpmap" attribute MUST be included to
specify the format name and parameters as defined by the media type specify the format name and parameters as defined by the media type
registration for the payload format. It is RECOMMENDED that other registration for the payload format. It is RECOMMENDED that other
skipping to change at page 45, line 11 skipping to change at page 45, line 34
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.
IANA has registered the bandwidth specifiers "CT" and "AS" with IANA has registered the bandwidth specifiers "CT" and "AS" with
definitions as in Section 5.8 of this memo (these definitions update definitions as in Section 5.8 of this memo (these definitions update
those in [RFC4566]). those in [RFC4566]).
8.2.6. Network Types ("nettype") 8.2.6. Network Types ("nettype")
New network types (the "nettype" field) MUST be registered with IANA New network types (the "nettype" sub-field) MUST be registered with
if SDP needs to be used in the context of non-Internet environments. IANA if SDP needs to be used in the context of non-Internet
The registration is subject to the "RFC Required" policy of environments. The registration is subject to the "RFC Required"
[RFC8126]. Although these are not normally the preserve of IANA, policy of [RFC8126]. Although these are not normally the preserve of
there may be circumstances when an Internet application needs to IANA, there may be circumstances when an Internet application needs
interoperate with a non-Internet application, such as when gatewaying to interoperate with a non-Internet application, such as when
an Internet telephone call into the Public Switched Telephone Network gatewaying an Internet telephone call into the Public Switched
(PSTN). The number of network types should be small and should be Telephone Network (PSTN). The number of network types should be
rarely extended. A new network type cannot be registered without small and should be rarely extended. A new network type cannot be
registering at least one address type to be used with that network registered without registering at least one address type to be used
type. A new network type registration MUST reference an RFC that with that network type. A new network type registration MUST
gives details of the network type and address type(s) and specifies reference an RFC that gives details of the network type and address
how and when they would be used. type(s) and specifies how and when they would be used.
IANA has registered the network type "IN" to represent the Internet, IANA has registered the network type "IN" to represent the Internet,
with definition as in Sections 5.2 and 5.7 of this memo (these with definition as in Sections 5.2 and 5.7 of this memo (these
definitions update those in [RFC4566]). definitions update those in [RFC4566]).
8.2.7. Address Types ("addrtype") 8.2.7. Address Types ("addrtype")
New address types ("addrtype") MUST be registered with IANA. The New address types ("addrtype") MUST be registered with IANA. The
registration is subject to the "RFC Required" policy of [RFC8126]. registration is subject to the "RFC Required" policy of [RFC8126].
An address type is only meaningful in the context of a network type, An address type is only meaningful in the context of a network type,
skipping to change at page 45, line 46 skipping to change at page 46, line 22
A new address type registration MUST reference an RFC giving details A new address type registration MUST reference an RFC giving details
of the syntax of the address type. Address types are not expected to of the syntax of the address type. Address types are not expected to
be registered frequently. be registered frequently.
IANA has registered the address types "IP4" and "IP6" with IANA has registered the address types "IP4" and "IP6" with
definitions as in Sections 5.2 and 5.7 of this memo (these definitions as in Sections 5.2 and 5.7 of this memo (these
definitions update those in [RFC4566]). definitions update those in [RFC4566]).
8.2.8. Registration Procedure 8.2.8. Registration Procedure
In the RFC documentation that registers SDP "media", "proto", "fmt", In the RFC specifications that register new values for SDP "media",
"bwtype", "nettype", and "addrtype" fields, the authors MUST include "proto", "fmt", "bwtype", "nettype", and "addrtype" parameters, the
the following information for IANA to place in the appropriate authors MUST include the following information for IANA to place in
registry: the appropriate registry:
o contact name, email address, and telephone number o contact name, email address, and telephone number
o name being registered (as it will appear in SDP) o name being registered (as it will appear in SDP)
o long-form name in English o long-form name in English
o type of name ("media", "proto", "fmt", "bwtype", "nettype", or o type of name ("media", "proto", "fmt", "bwtype", "nettype", or
"addrtype") "addrtype")
o a one-paragraph explanation of the purpose of the registered name o a one-paragraph explanation of the purpose of the registered name
o a reference to the specification for the registered name (this o a reference to the specification for the registered name (this
skipping to change at page 47, line 43 skipping to change at page 48, line 19
| | | |-msrp-usage- | | | |-msrp-usage-
| | | |data-channel | | | |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 = version-field
origin-field origin-field
session-name-field session-name-field
[information-field] [information-field]
[uri-field] [uri-field]
*email-field *email-field
*phone-field *phone-field
[connection-field] [connection-field]
*bandwidth-field *bandwidth-field
1*time-field 1*time-description
[key-field] [key-field]
*attribute-field *attribute-field
*media-description *media-description
proto-version = %s"v" "=" 1*DIGIT CRLF version-field = %s"v" "=" 1*DIGIT CRLF
;this memo describes version 0 ;this memo describes version 0
origin-field = %s"o" "=" username SP sess-id SP sess-version SP origin-field = %s"o" "=" username SP sess-id SP sess-version SP
nettype SP addrtype SP unicast-address CRLF nettype SP addrtype SP unicast-address CRLF
session-name-field = %s"s" "=" text CRLF session-name-field = %s"s" "=" text CRLF
information-field = %s"i" "=" text CRLF information-field = %s"i" "=" text CRLF
uri-field = %s"u" "=" uri CRLF uri-field = %s"u" "=" uri CRLF
skipping to change at page 48, line 33 skipping to change at page 49, line 8
phone-field = %s"p" "=" phone-number CRLF phone-field = %s"p" "=" phone-number CRLF
connection-field = %s"c" "=" nettype SP addrtype SP connection-field = %s"c" "=" nettype SP addrtype SP
connection-address CRLF connection-address CRLF
;a connection field must be present ;a connection field must be present
;in every media description or at the ;in every media description or at the
;session-level ;session-level
bandwidth-field = %s"b" "=" bwtype ":" bandwidth CRLF bandwidth-field = %s"b" "=" bwtype ":" bandwidth CRLF
time-field = %s"t" "=" start-time SP stop-time time-description = time-field
*(CRLF repeat-fields) CRLF [repeat-description]
[zone-adjustments CRLF]
repeat-fields = %s"r" "=" repeat-interval SP typed-time repeat-description = 1*repeat-field
1*(SP typed-time) [zone-field]
zone-adjustments = %s"z" "=" time SP ["-"] typed-time time-field = %s"t" "=" start-time SP stop-time CRLF
*(SP time SP ["-"] typed-time)
repeat-field = %s"r" "=" repeat-interval SP typed-time
1*(SP typed-time) CRLF
zone-field = %s"z" "=" time SP ["-"] typed-time
*(SP time SP ["-"] typed-time) CRLF
key-field = %s"k" "=" key-type CRLF key-field = %s"k" "=" key-type CRLF
attribute-field = %s"a" "=" attribute CRLF attribute-field = %s"a" "=" attribute CRLF
media-description = media-field media-description = media-field
[information-field] [information-field]
*connection-field *connection-field
*bandwidth-field *bandwidth-field
[key-field] [key-field]
skipping to change at page 49, line 32 skipping to change at page 50, line 13
;typically "IP4" or "IP6" ;typically "IP4" or "IP6"
; sub-rules of 'u=' ; sub-rules of 'u='
uri = URI-reference uri = URI-reference
; see RFC 3986 ; see RFC 3986
; sub-rules of 'e=', see RFC 5322 for definitions ; sub-rules of 'e=', see RFC 5322 for definitions
email-address = address-and-comment / dispname-and-address email-address = address-and-comment / dispname-and-address
/ addr-spec / addr-spec
address-and-comment = addr-spec 1*SP "(" 1*email-safe ")" address-and-comment = addr-spec 1*SP "(" 1*email-safe ")"
dispname-and-address = 1*email-safe 1*SP "<" addr-spec "&gt;" dispname-and-address = 1*email-safe 1*SP "<" addr-spec "&gt;"
; sub-rules of 'p=' ; sub-rules of 'p='
phone-number = phone *SP "(" 1*email-safe ")" / phone-number = phone *SP "(" 1*email-safe ")" /
1*email-safe "<" phone "&gt;" / 1*email-safe "<" phone "&gt;" /
phone phone
phone = ["+"] DIGIT 1*(SP / "-" / DIGIT) phone = ["+"] DIGIT 1*(SP / "-" / DIGIT)
; sub-rules of 'c=' ; sub-rules of 'c='
connection-address = multicast-address / unicast-address connection-address = multicast-address / unicast-address
; sub-rules of 'b=' ; sub-rules of 'b='
bwtype = token bwtype = token
skipping to change at page 52, line 16 skipping to change at page 52, line 48
;ISO 8859-1 requires "a=charset:ISO-8859-1" ;ISO 8859-1 requires "a=charset:ISO-8859-1"
;session-level attribute to be used ;session-level attribute to be used
byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF) byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF)
;any byte except NUL, CR, or LF ;any byte except NUL, CR, or LF
non-ws-string = 1*(VCHAR/%x80-FF) non-ws-string = 1*(VCHAR/%x80-FF)
;string of visible characters ;string of visible characters
token-char = ALPHA / DIGIT token-char = ALPHA / DIGIT
/ "!" / "#" / "$" / "%" / "&" / "!" / "#" / "$" / "%" / "&amp;"
/ "'" ; (single quote) / "'" ; (single quote)
/ "*" / "+" / "-" / "." / "^" / "_" / "*" / "+" / "-" / "." / "^" / "_"
/ "`" ; (Grave accent) / "`" ; (Grave accent)
/ "{" / "|" / "}" / "~" / "{" / "|" / "}" / "~"
token = 1*(token-char) token = 1*(token-char)
email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF
;any byte except NUL, CR, LF, or the quoting ;any byte except NUL, CR, LF, or the quoting
;characters ()<&gt; ;characters ()<&gt;
integer = POS-DIGIT *DIGIT integer = POS-DIGIT *DIGIT
zero-based-integer = "0" / integer zero-based-integer = "0" / integer
non-zero-int-or-real = integer / non-zero-real non-zero-int-or-real = integer / non-zero-real
non-zero-real = zero-based-integer "." *DIGIT POS-DIGIT non-zero-real = zero-based-integer "." *DIGIT POS-DIGIT
; generic sub-rules: primitives ; generic sub-rules: primitives
skipping to change at page 52, line 48 skipping to change at page 53, line 31
POS-DIGIT = %x31-39 ; 1 - 9 POS-DIGIT = %x31-39 ; 1 - 9
decimal-uchar = DIGIT decimal-uchar = DIGIT
/ POS-DIGIT DIGIT / POS-DIGIT DIGIT
/ ("1" 2*(DIGIT)) / ("1" 2*(DIGIT))
/ ("2" ("0"/"1"/"2"/"3"/"4") DIGIT) / ("2" ("0"/"1"/"2"/"3"/"4") DIGIT)
/ ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5")) / ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5"))
; external references: ; external references:
; ALPHA, DIGIT, CRLF, HEXDIG, SP, VCHAR: from RFC 5234 ALPHA = <ALPHA definition from RFC5234>
; URI-reference: from RFC 3986 DIGIT = <DIGIT definition from RFC5234>
; addr-spec: from RFC 5322 CRLF = <CRLF definition from RFC5234>
HEXDIG = <HEXDIG definition from RFC5234>
SP = <SP definition from RFC5234>
VCHAR = <VCHAR definition from RFC5234>
URI-reference = <URI-reference definition from RFC3986>
addr-spec = <addr-spec definition from RFC5322>
10. Summary of Changes from RFC 4566 10. Summary of Changes from RFC 4566
The ABNF rule for IP6-address has been corrected. As a result, the The ABNF rule for IP6-address has been corrected. As a result, the
ABNF rule for IP6-multicast has changed, and the (now unused) rules ABNF rule for IP6-multicast has changed, and the (now unused) rules
for hexpart, hexseq, and hex4 have been removed. for hexpart, hexseq, and hex4 have been removed.
IP4 unicast and multicast addresses in the example SDP descriptions IP4 unicast and multicast addresses in the example SDP descriptions
have been revised per RFCs 5735 and 5771. have been revised per RFCs 5735 and 5771.
skipping to change at page 53, line 42 skipping to change at page 54, line 28
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-17 Negotiation", draft-ietf-mmusic-data-channel-sdpneg-18
(work in progress), April 2018. (work in progress), May 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>.
skipping to change at page 55, line 20 skipping to change at page 55, line 52
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-mmusic-sdp-bundle-negotiation] [I-D.ietf-mmusic-sdp-bundle-negotiation]
Holmberg, C., Alvestrand, H., and C. Jennings, Holmberg, C., Alvestrand, H., and C. Jennings,
"Negotiating Media Multiplexing Using the Session "Negotiating Media Multiplexing Using the Session
Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle- Description Protocol (SDP)", draft-ietf-mmusic-sdp-bundle-
negotiation-50 (work in progress), April 2018. negotiation-51 (work in progress), May 2018.
[ITU.H332.1998] [ITU.H332.1998]
International Telecommunication Union, "H.323 extended for International Telecommunication Union, "H.323 extended for
loosely coupled conferences", ITU Recommendation H.332, loosely coupled conferences", ITU Recommendation H.332,
September 1998. September 1998.
[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,
<https://www.rfc-editor.org/info/rfc2327>. <https://www.rfc-editor.org/info/rfc2327>.
 End of changes. 70 change blocks. 
175 lines changed or deleted 194 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/