draft-ietf-mmusic-msid-16.txt   draft-ietf-mmusic-msid-17.txt 
Network Working Group H. Alvestrand Network Working Group H. Alvestrand
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track February 7, 2017 Intended status: Standards Track December 13, 2018
Expires: August 11, 2017 Expires: June 16, 2019
WebRTC MediaStream Identification in the Session Description Protocol WebRTC MediaStream Identification in the Session Description Protocol
draft-ietf-mmusic-msid-16 draft-ietf-mmusic-msid-17
Abstract Abstract
This document specifies a Session Description Protocol (SDP) Grouping This document specifies a Session Description Protocol (SDP) Grouping
mechanism for RTP media streams that can be used to specify relations mechanism for RTP media streams that can be used to specify relations
between media streams. between media streams.
This mechanism is used to signal the association between the SDP This mechanism is used to signal the association between the SDP
concept of "media description" and the WebRTC concept of concept of "media description" and the WebRTC concept of
"MediaStream" / "MediaStreamTrack" using SDP signaling. "MediaStream" / "MediaStreamTrack" using SDP signaling.
skipping to change at page 1, line 45 skipping to change at page 1, line 45
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 11, 2017. This Internet-Draft will expire on June 16, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 30 skipping to change at page 2, line 30
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Structure Of This Document . . . . . . . . . . . . . . . 3 1.2. Structure Of This Document . . . . . . . . . . . . . . . 3
1.3. Why A New Mechanism Is Needed . . . . . . . . . . . . . . 4 1.3. Why A New Mechanism Is Needed . . . . . . . . . . . . . . 4
1.4. The WEBRTC MediaStream . . . . . . . . . . . . . . . . . 4 1.4. The WEBRTC MediaStream . . . . . . . . . . . . . . . . . 4
2. The Msid Mechanism . . . . . . . . . . . . . . . . . . . . . 5 2. The Msid Mechanism . . . . . . . . . . . . . . . . . . . . . 5
3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Procedures . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Handling of non-signalled tracks . . . . . . . . . . . . 7 3.1. Handling of non-signalled tracks . . . . . . . . . . . . 7
3.2. Detailed Offer/Answer Procedures . . . . . . . . . . . . 8 3.2. Detailed Offer/Answer Procedures . . . . . . . . . . . . 9
3.2.1. Generating the initial offer . . . . . . . . . . . . 9 3.2.1. Generating the initial offer . . . . . . . . . . . . 9
3.2.2. Answerer processing of the Offer . . . . . . . . . . 9 3.2.2. Answerer processing of the Offer . . . . . . . . . . 9
3.2.3. Generating the answer . . . . . . . . . . . . . . . . 9 3.2.3. Generating the answer . . . . . . . . . . . . . . . . 10
3.2.4. Offerer processing of the answer . . . . . . . . . . 9 3.2.4. Offerer processing of the answer . . . . . . . . . . 10
3.2.5. Modifying the session . . . . . . . . . . . . . . . . 9 3.2.5. Modifying the session . . . . . . . . . . . . . . . . 10
3.3. Example SDP description . . . . . . . . . . . . . . . . . 10 3.3. Example SDP description . . . . . . . . . . . . . . . . . 10
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
4.1. Attribute registration in existing registries . . . . . . 10 4.1. Attribute registration in existing registries . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12 7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 13 7.2. Informative References . . . . . . . . . . . . . . . . . 13
Appendix A. Design considerations, rejected alternatives . . . . 13 Appendix A. Design considerations, rejected alternatives . . . . 14
Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 14 Appendix B. Change log . . . . . . . . . . . . . . . . . . . . . 14
B.1. Changes from alvestrand-rtcweb-msid-00 to -01 . . . . . . 14 B.1. Changes from alvestrand-rtcweb-msid-00 to -01 . . . . . . 14
B.2. Changes from alvestrand-rtcweb-msid-01 to -02 . . . . . . 14 B.2. Changes from alvestrand-rtcweb-msid-01 to -02 . . . . . . 15
B.3. Changes from alvestrand-rtcweb-msid-02 to mmusic-msid-00 14 B.3. Changes from alvestrand-rtcweb-msid-02 to mmusic-msid-00 15
B.4. Changes from alvestrand-mmusic-msid-00 to -01 . . . . . . 14 B.4. Changes from alvestrand-mmusic-msid-00 to -01 . . . . . . 15
B.5. Changes from alvestrand-mmusic-msid-01 to -02 . . . . . . 14 B.5. Changes from alvestrand-mmusic-msid-01 to -02 . . . . . . 15
B.6. Changes from alvestrand-mmusic-msid-02 to ietf-mmusic-00 15 B.6. Changes from alvestrand-mmusic-msid-02 to ietf-mmusic-00 15
B.7. Changes from mmusic-msid-00 to -01 . . . . . . . . . . . 15 B.7. Changes from mmusic-msid-00 to -01 . . . . . . . . . . . 16
B.8. Changes from mmusic-msid-01 to -02 . . . . . . . . . . . 15 B.8. Changes from mmusic-msid-01 to -02 . . . . . . . . . . . 16
B.9. Changes from mmusic-msid-02 to -03 . . . . . . . . . . . 15 B.9. Changes from mmusic-msid-02 to -03 . . . . . . . . . . . 16
B.10. Changes from mmusic-msid-03 to -04 . . . . . . . . . . . 16 B.10. Changes from mmusic-msid-03 to -04 . . . . . . . . . . . 16
B.11. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 16 B.11. Changes from -04 to -05 . . . . . . . . . . . . . . . . . 16
B.12. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 16 B.12. Changes from -05 to -06 . . . . . . . . . . . . . . . . . 16
B.13. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 16 B.13. Changes from -06 to -07 . . . . . . . . . . . . . . . . . 17
B.14. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 16 B.14. Changes from -07 to -08 . . . . . . . . . . . . . . . . . 17
B.15. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 17 B.15. Changes from -08 to -09 . . . . . . . . . . . . . . . . . 17
B.16. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 17 B.16. Changes from -09 to -10 . . . . . . . . . . . . . . . . . 18
B.17. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 17 B.17. Changes from -10 to -11 . . . . . . . . . . . . . . . . . 18
B.18. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 17 B.18. Changes from -11 to -12 . . . . . . . . . . . . . . . . . 18
B.19. Changes from -12 to -13 . . . . . . . . . . . . . . . . . 17 B.19. Changes from -12 to -13 . . . . . . . . . . . . . . . . . 18
B.20. Changes from -13 to -14 . . . . . . . . . . . . . . . . . 17 B.20. Changes from -13 to -14 . . . . . . . . . . . . . . . . . 18
B.21. Changes from -14 to -15 . . . . . . . . . . . . . . . . . 18 B.21. Changes from -14 to -15 . . . . . . . . . . . . . . . . . 18
B.22. Changes from -15 to -16 . . . . . . . . . . . . . . . . . 18 B.22. Changes from -15 to -16 . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 B.23. Changes from -16 to -17 . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
1.1. Terminology 1.1. Terminology
This document uses terminology from [I-D.ietf-rtcweb-overview]. In This document uses terminology from [I-D.ietf-rtcweb-overview]. In
addition, the following terms are used as described below: addition, the following terms are used as described below:
RTP stream Defined in [RFC7656] as a stream of RTP packets RTP stream Defined in [RFC7656] as a stream of RTP packets
containing media data. containing media data.
skipping to change at page 6, line 40 skipping to change at page 6, line 40
defined in [W3C.WD-webrtc-20160531]. defined in [W3C.WD-webrtc-20160531].
In the Javascript API described in that specification, each In the Javascript API described in that specification, each
MediaStream and MediaStreamTrack has an "id" attribute, which is a MediaStream and MediaStreamTrack has an "id" attribute, which is a
DOMString. DOMString.
The value of the "msid-id" field in the msid consists of the "id" The value of the "msid-id" field in the msid consists of the "id"
attribute of a MediaStream, as defined in the MediaStream's WebIDL attribute of a MediaStream, as defined in the MediaStream's WebIDL
specification. The special value "-" indicates "no MediaStream". specification. The special value "-" indicates "no MediaStream".
The value of the "msid-appdata" field in the msid consists of the The value of the "msid-appdata" field in the msid, if present,
"id" attribute of a MediaStreamTrack, as defined in the consists of the "id" attribute of a MediaStreamTrack, as defined in
MediaStreamTrack's WebIDL specification. the MediaStreamTrack's WebIDL specification.
When an SDP session description is updated, a specific "msid-id" When an SDP session description is updated, a specific "msid-id"
value continues to refer to the same MediaStream, and a specific value continues to refer to the same MediaStream, and a specific
"msid-appdata" to the same MediaStreamTrack. There is no memory "msid-appdata" to the same MediaStreamTrack. There is no memory
apart from the currently valid SDP descriptions; if an msid apart from the currently valid SDP descriptions; if an msid
"identifier" value disappears from the SDP and appears in a later "identifier" value disappears from the SDP and appears in a later
negotiation, it will be taken to refer to a new MediaStream. negotiation, it will be taken to refer to a new MediaStream.
If the MSID attribute does not conform to the ABNF given here, it If the MSID attribute does not conform to the ABNF given here, it
SHOULD be ignored. SHOULD be ignored.
skipping to change at page 7, line 21 skipping to change at page 7, line 21
o When a session description is updated to have media descriptions o When a session description is updated to have media descriptions
with an msid "identifier" value, with one or more different with an msid "identifier" value, with one or more different
"appdata" values, the recipient can signal to its application that "appdata" values, the recipient can signal to its application that
new MediaStreamTracks have been added, and which MediaStream it new MediaStreamTracks have been added, and which MediaStream it
has been added to. This is done for each different msid has been added to. This is done for each different msid
"identifier" value, including the special value "-", which "identifier" value, including the special value "-", which
indicates that a MediaStreamTrack has been added with no indicates that a MediaStreamTrack has been added with no
corresponding MediaStream. corresponding MediaStream.
o If an msid "identifier" value with no "appdata" value appears, it
means that the sender did not inform the recipient of the desired
identifier of the MediaStreamTrack, and the recipient will assign
the "id" value of the created MediaStreamTrack on its own. All
msid in a media section that do not have an "appdata" value are
assumed to refer to the same MediaStreamTrack.
o When a session description is updated to no longer list any msid o When a session description is updated to no longer list any msid
attribute on a specific media description, the recipient can attribute on a specific media description, the recipient can
signal to its application that the corresponding MediaStreamTrack signal to its application that the corresponding MediaStreamTrack
has ended. has ended.
In addition to signaling that the track is ended when its msid In addition to signaling that the track is ended when its msid
attribute disappears from the SDP, the track will also be signaled as attribute disappears from the SDP, the track will also be signaled as
being ended when all associated SSRCs have disappeared by the rules being ended when all associated SSRCs have disappeared by the rules
of [RFC3550] section 6.3.4 (BYE packet received) and 6.3.5 (timeout), of [RFC3550] section 6.3.4 (BYE packet received) and 6.3.5 (timeout),
or when the corresponding media description is disabled by setting or when the corresponding media description is disabled by setting
skipping to change at page 9, line 11 skipping to change at page 9, line 18
They describe the actions to be taken in terms of MediaStreams and They describe the actions to be taken in terms of MediaStreams and
MediaStreamTracks; they do not include event signalling inside the MediaStreamTracks; they do not include event signalling inside the
application, which is described in JSEP. application, which is described in JSEP.
3.2.1. Generating the initial offer 3.2.1. Generating the initial offer
For each media description in the offer, if there is an associated For each media description in the offer, if there is an associated
outgoing MediaStreamTrack, the offerer adds one "a=msid" attribute to outgoing MediaStreamTrack, the offerer adds one "a=msid" attribute to
the section for each MediaStream with which the MediaStreamTrack is the section for each MediaStream with which the MediaStreamTrack is
associated. The "identifier" field of the attribute is set to the associated. The "identifier" field of the attribute is set to the
WebIDL "id" attribute of the MediaStream, and the "appdata" field is WebIDL "id" attribute of the MediaStream. If the sender wishes to
set to the WebIDL "id" attribute of the MediaStreamTrack. signal identifiers for the MediaStreamTracks, the "appdata" field is
set to the WebIDL "id" attribute of the MediaStreamTrack; otherwise
it is omitted.
3.2.2. Answerer processing of the Offer 3.2.2. Answerer processing of the Offer
For each media description in the offer, and for each "a=msid" For each media description in the offer, and for each "a=msid"
attribute in the media description, the receiver of the offer will attribute in the media description, the receiver of the offer will
perform the following steps: perform the following steps:
o Extract the "appdata" field of the "a=msid" attribute o Extract the "appdata" field of the "a=msid" attribute, if present.
o Check if a MediaStreamTrack with the same WebIDL "id" attribute as o If the "appdata" field exists: Check if a MediaStreamTrack with
the "appdata" field already exists, and is not in the "ended" the same WebIDL "id" attribute as the "appdata" field already
state. If it is not found, create it. exists, and is not in the "ended" state. If it is not found,
create it.
o If the "appdata" field does not exist, and a MediaStreamTrack is
not associated with this media section, create one and associate
it with this media section for future use.
o Extract the "identifier" field of the "a=msid" attribte. o Extract the "identifier" field of the "a=msid" attribte.
o Check if a MediaStream with the same WebIDL "id" attribute already o Check if a MediaStream with the same WebIDL "id" attribute already
exists. If not, create it. exists. If not, create it.
o Add the MediaStreamTrack to the MediaStream o Add the MediaStreamTrack to the MediaStream
o Signal to the user that a new MediaStreamTrack is available. o Signal to the user that a new MediaStreamTrack is available.
skipping to change at page 18, line 28 skipping to change at page 19, line 12
Various small changes based on review feedback during IESG Various small changes based on review feedback during IESG
processing. processing.
B.22. Changes from -15 to -16 B.22. Changes from -15 to -16
Added the special "-" value that means "no MediaStream". Added the special "-" value that means "no MediaStream".
Changed instances of a MediaStreamTrack being "closed" to saying it's Changed instances of a MediaStreamTrack being "closed" to saying it's
"ended", in accordance with WebRTC terminology. "ended", in accordance with WebRTC terminology.
B.23. Changes from -16 to -17
Added text to allow omitting track identifiers, per JSEP PR #850
Author's Address Author's Address
Harald Alvestrand Harald Alvestrand
Google Google
Kungsbron 2 Kungsbron 2
Stockholm 11122 Stockholm 11122
Sweden Sweden
Email: harald@alvestrand.no Email: harald@alvestrand.no
 End of changes. 19 change blocks. 
39 lines changed or deleted 58 lines changed or added

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