draft-ietf-mmusic-rfc4566bis-25.txt   draft-ietf-mmusic-rfc4566bis-26.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: August 23, 2018 C. Perkins Expires: November 1, 2018 C. Perkins
University of Glasgow University of Glasgow
M. Handley M. Handley
UCL UCL
February 19, 2018 April 30, 2018
SDP: Session Description Protocol SDP: Session Description Protocol
draft-ietf-mmusic-rfc4566bis-25 draft-ietf-mmusic-rfc4566bis-26
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 August 23, 2018. This Internet-Draft will expire on November 1, 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 8, line 17 skipping to change at page 8, line 17
4.3. Obtaining Further Information about a Session 4.3. Obtaining Further Information about a Session
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 SAP, or any When many session descriptions are being distributed by an
other 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 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
skipping to change at page 18, line 5 skipping to change at page 18, line 5
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 <bwtype> names
SHOULD be registered with IANA in the standard namespace. SDP SHOULD be registered with IANA in the standard namespace. SDP
parsers MUST ignore bandwidth fields with unknown <bwtype> names. parsers MUST ignore bandwidth fields with unknown <bwtype> names.
The <bwtype> names MUST be alphanumeric and, although no length limit The <bwtype> names MUST be alphanumeric and, although no length limit
is given, it is recommended that they be short. 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
The definition of a new <bwtype> modifier MAY specify that the (including the transport and network-layer but not the link-layer
bandwidth is to be interpreted in some alternative unit (the "CT" and overhead). The definition of a new <bwtype> modifier MAY specify
"AS" modifiers defined in this memo use the default units). that the bandwidth is to be interpreted in some alternative unit (the
"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. The "t=" lines specify the start and stop times for a session.
Multiple "t=" lines MAY be used if a session is active at multiple Multiple "t=" lines MAY be used if a session is active at multiple
irregularly spaced times; each additional "t=" line specifies an irregularly spaced times; each additional "t=" line specifies an
additional period of time for which the session will be active. If additional period of time for which the session will be active. If
the session is active at regular repeat times, an "r=" line (see the session is active at regular repeat times, an "r=" line (see
below) should be used in addition to, and following, a "t=" line -- below) should be used in addition to, and following, a "t=" line --
in which case the "t=" line specifies the start and stop times of the in which case the "t=" line 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 give the start and stop times,
respectively, for the session. These values are the decimal respectively, for the session. These values are the decimal
representation of Network Time Protocol (NTP) time values in seconds representation of Network Time Protocol (NTP) time values in seconds
since 1900 [RFC5905]. To convert these values to UNIX time, subtract since 1900 [RFC5905]. To convert these values to UNIX time (UTC),
decimal 2208988800. 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 50 skipping to change at page 19, line 50
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 "t=" lines should be used to
explicitly list the session times. explicitly list the session times.
5.11. Time Zones ("z=") 5.11. Time Zones ("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.
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
time zone a session is scheduled. To simplify this task for time zone a session is scheduled. To simplify this task for
skipping to change at page 23, line 30 skipping to change at page 23, line 30
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 field in the relevant
"c=" line. Thus a "c=" field of IP4 indicates that the transport "c=" line. Thus a "c=" field of IP4 indicates that the transport
protocol runs over IP4. The following transport protocols are protocol runs over IP4. The following transport protocols are
defined, but may be extended through registration of new protocols defined, but may be extended through registration of new protocols
with IANA (see Section 8): with IANA (see Section 8):
* udp: denotes an unspecified protocol running over UDP. * udp: denotes that the data is transported directly in UDP with
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.
The main reason to specify the transport protocol in addition to The main reason to specify the transport protocol in addition to
the media format is that the same standard media formats may be the media format is that the same standard media formats may be
skipping to change at page 37, line 12 skipping to change at page 37, line 12
; - The format parameters are media type parameters and ; - The format parameters are media type parameters and
need to reflect their syntax. need to reflect their syntax.
Example: Example:
a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600 a=fmtp:96 profile-level-id=42e016;max-mbps=108000;max-fs=3600
This attribute allows parameters that are specific to a particular This attribute allows parameters that are specific to a particular
format to be conveyed in a way that SDP does not have to understand format to be conveyed in a way that SDP does not have to understand
them. The format must be one of the formats specified for the media. them. The format must be one of the formats specified for the media.
Format-specific parameters may be any set of parameters required to Format-specific parameters, semicolon separated, may be any set of
be conveyed by SDP and given unchanged to the media tool that will parameters required to be conveyed by SDP and given unchanged to the
use this format. At most one instance of this attribute is allowed media tool that will use this format. At most one instance of this
for each format. attribute is allowed for each format.
The fmtp attribute may be used to specify parameters for any protocol
and format that defines use of such parameters.
7. Security Considerations 7. Security Considerations
SDP is frequently used with the Session Initiation Protocol [RFC3261] SDP is frequently used with the Session Initiation Protocol [RFC3261]
using the offer/answer model [RFC3264] to agree on parameters for using the offer/answer model [RFC3264] to agree on parameters for
unicast sessions. When used in this manner, the security unicast sessions. When used in this manner, the security
considerations of those protocols apply. considerations of those protocols apply.
SDP is a session description format that describes multimedia SDP is a session description format that describes multimedia
sessions. Entities receiving and acting upon an SDP message SHOULD sessions. Entities receiving and acting upon an SDP message SHOULD
skipping to change at page 37, line 42 skipping to change at page 37, line 45
are often not deployed. In case a session description has not been are often not deployed. In case a session description has not been
obtained in a trusted manner, the endpoint SHOULD exercise care obtained in a trusted manner, the endpoint SHOULD exercise care
because, among other attacks, the media sessions received may not be because, among other attacks, the media sessions received may not be
the intended ones, the destination where media is sent to may not be the intended ones, the destination where media is sent to may not be
the expected one, any of the parameters of the session may be the expected one, any of the parameters of the session may be
incorrect, or the media security may be compromised. It is up to the incorrect, or the media security may be compromised. It is up to the
endpoint to make a sensible decision taking into account the security endpoint to make a sensible decision taking into account the security
risks of the application and the user preferences - the endpoint may risks of the application and the user preferences - the endpoint may
decide to ask the user whether or not to accept the session. decide to ask the user whether or not to accept the session.
One transport that can be used to distribute session descriptions is
the SAP. SAP provides both encryption and authentication mechanisms,
but due to the nature of session announcements it is likely that
there are many occasions where the originator of a session
announcement cannot be authenticated because the originator is
previously unknown to the receiver of the announcement and because no
common public key infrastructure is available.
On receiving a session description over an unauthenticated transport On receiving a session description over an unauthenticated transport
mechanism or from an untrusted party, software parsing the session mechanism or from an untrusted party, software parsing the session
should take a few precautions. Similar concerns apply if integrity should take a few precautions. Similar concerns apply if integrity
protection is not in place. Session descriptions contain information protection is not in place. Session descriptions contain information
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
skipping to change at page 41, line 11 skipping to change at page 41, line 7
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. This SHOULD The "proto" field describes the transport protocol used. The
reference a standards-track protocol RFC. This memo registers three registration procedure for this field is "RFC Required".
values: "RTP/AVP" is a reference to [RFC3550] used under the RTP
Profile for Audio and Video Conferences with Minimal Control
[RFC3551] running over UDP/IP, "RTP/SAVP" is a reference to the
Secure Real-time Transport Protocol [RFC3711], and "udp" indicates an
unspecified protocol over UDP.
If other RTP profiles are defined in the future, their "proto" name This document registers two values: "RTP/AVP" is a reference to
SHOULD be specified in the same manner. For example, an RTP profile [RFC3550] used under the RTP Profile for Audio and Video Conferences
whose short name is "XYZ" would be denoted by a "proto" field of with Minimal Control [RFC3551] running over UDP/IP, and "udp"
"RTP/XYZ". indicates direct use of the UDP protocol.
New transport protocols SHOULD be registered with IANA. New transport protocols MAY be defined, and SHOULD be registered with
Registrations MUST reference an RFC describing the protocol. Such an IANA. Registrations MUST reference an RFC describing the protocol.
RFC MAY be Experimental or Informational, although it is preferable Such an RFC MAY be Experimental or Informational, although it is
that it be Standards Track. Registrations MUST also define the rules preferable that it be Standards Track. The RFC defining a new
by which their "fmt" namespace is managed (see below). protocol MUST define the rules by which the "fmt" (see below)
namespace is managed.
"proto" names starting with "RTP/" MUST only be used for defining
transport protocols that are profiles of the RTP protocol. For
example, a profile whose short name is "XYZ" would be denoted by a
"proto" 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" 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 "RTP/SAVP" profiles MUST RTP payload formats under the "RTP/AVP" and other "RTP/*" profiles
use the payload type number as their "fmt" value. If the payload MUST use the payload type number as their "fmt" value. If the
type number is dynamically assigned by this session description, an payload type number is dynamically assigned by this session
additional "rtpmap" attribute MUST be included to specify the format description, an additional "rtpmap" attribute MUST be included to
name and parameters as defined by the media type registration for the specify the format name and parameters as defined by the media type
payload format. It is RECOMMENDED that other RTP profiles that are registration for the payload format. It is RECOMMENDED that other
registered (in combination with RTP) as SDP transport protocols RTP profiles that are registered (in combination with RTP) as SDP
specify the same rules for the "fmt" namespace. transport protocols specify the same rules for the "fmt" namespace.
For the "udp" protocol, new formats SHOULD be registered. Use of an For the "udp" protocol, allowed "fmt" values are media subtypes from
existing media subtype for the format is encouraged. If no media the IANA Media Types registry. The media type and subtype
subtype exists, it is RECOMMENDED that a suitable one be registered combination <media>/<fmt> specifies the format of the body of UDP
through the IETF process [RFC6838] by production of, or reference to, packets. Use of an existing media subtype for the format is
a standards-track RFC that defines the transport protocol for the encouraged. If no suitable media subtype exists, it is RECOMMENDED
format. that a new one be registered through the IETF process [RFC6838] by
production of, or reference to, a standards-track RFC that defines
the format.
For other protocols, formats MAY be registered according to the rules For other protocols, formats MAY be registered according to the rules
of the associated "proto" specification. of the associated "proto" specification.
Registrations of new formats MUST specify which transport protocols Registrations of new formats MUST specify which transport protocols
they apply to. they apply to.
8.2.4. Attribute Names ("att-field") 8.2.4. Attribute Names ("att-field")
8.2.4.1. New Attributes 8.2.4.1. New Attributes
skipping to change at page 53, line 42 skipping to change at page 53, line 42
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-16 Negotiation", draft-ietf-mmusic-data-channel-sdpneg-17
(work in progress), December 2017. (work in progress), April 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-16 Multiplexing", draft-ietf-mmusic-sdp-mux-attributes-17
(work in progress), December 2016. (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>.
[RFC1035] Mockapetris, P., "Domain names - implementation and [RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>. November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
skipping to change at page 55, line 20 skipping to change at page 55, line 20
[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-48 (work in progress), January 2018. negotiation-50 (work in progress), April 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. 19 change blocks. 
60 lines changed or deleted 63 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/