draft-ietf-mmusic-msid-02.txt   draft-ietf-mmusic-msid-03.txt 
Network Working Group H. Alvestrand Network Working Group H. Alvestrand
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track November 5, 2013 Intended status: Standards Track January 6, 2014
Expires: May 9, 2014 Expires: July 10, 2014
Cross Session Stream Identification in the Session Description Protocol Cross Session Stream Identification in the Session Description Protocol
draft-ietf-mmusic-msid-02 draft-ietf-mmusic-msid-03
Abstract Abstract
This document specifies a grouping mechanism for RTP media streams This document specifies a grouping mechanism for RTP media streams
that can be used to specify relations between media streams. that can be used to specify relations 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 "m-line" and the WebRTC concept of "MediaStream" / concept of "m-line" and the WebRTC concept of "MediaStream" /
"MediaStreamTrack" using SDP signaling. "MediaStreamTrack" using SDP signaling.
skipping to change at page 1, line 44 skipping to change at page 1, line 44
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 May 9, 2014. This Internet-Draft will expire on July 10, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2014 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 27 skipping to change at page 2, line 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Structure Of This Document . . . . . . . . . . . . . . . . 3 1.1. Structure Of This Document . . . . . . . . . . . . . . . . 3
1.2. Why A New Mechanism Is Needed . . . . . . . . . . . . . . 3 1.2. Why A New Mechanism Is Needed . . . . . . . . . . . . . . 3
1.3. Application to the WEBRTC MediaStream . . . . . . . . . . 4 1.3. Application to the WEBRTC MediaStream . . . . . . . . . . 4
2. The Msid Mechanism . . . . . . . . . . . . . . . . . . . . . . 4 2. The Msid Mechanism . . . . . . . . . . . . . . . . . . . . . . 4
3. The Msid-Semantic Attribute . . . . . . . . . . . . . . . . . 5 3. The Msid-Semantic Attribute . . . . . . . . . . . . . . . . . 5
4. Applying Msid to WebRTC MediaStreams . . . . . . . . . . . . . 6 4. Applying Msid to WebRTC MediaStreams . . . . . . . . . . . . . 6
4.1. Handling of non-signalled tracks . . . . . . . . . . . . . 7 4.1. Handling of non-signalled tracks . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8.1. Normative References . . . . . . . . . . . . . . . . . . . 10 8.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8.2. Informative References . . . . . . . . . . . . . . . . . . 10 8.2. Informative References . . . . . . . . . . . . . . . . . . 10
Appendix A. Design considerations, open questions and and Appendix A. Design considerations, open questions and and
alternatives . . . . . . . . . . . . . . . . . . . . 11 alternatives . . . . . . . . . . . . . . . . . . . . 11
Appendix B. Usage with multiple MediaStreams per M-line . . . . . 11 Appendix B. Usage with multiple MediaStreams per M-line . . . . . 12
B.1. Mechanism design with multiple SSRCs . . . . . . . . . . . 12 B.1. Mechanism design with multiple SSRCs . . . . . . . . . . . 12
B.2. Usage with the SSRC attribute . . . . . . . . . . . . . . 13 B.2. Usage with the SSRC attribute . . . . . . . . . . . . . . 13
Appendix C. Change log . . . . . . . . . . . . . . . . . . . . . 13 Appendix C. Change log . . . . . . . . . . . . . . . . . . . . . 13
C.1. Changes from alvestrand-rtcweb-msid-00 to -01 . . . . . . 13 C.1. Changes from alvestrand-rtcweb-msid-00 to -01 . . . . . . 13
C.2. Changes from alvestrand-rtcweb-msid-01 to -02 . . . . . . 13 C.2. Changes from alvestrand-rtcweb-msid-01 to -02 . . . . . . 13
C.3. Changes from alvestrand-rtcweb-msid-02 to C.3. Changes from alvestrand-rtcweb-msid-02 to
mmusic-msid-00 . . . . . . . . . . . . . . . . . . . . . . 13 mmusic-msid-00 . . . . . . . . . . . . . . . . . . . . . . 13
C.4. Changes from alvestrand-mmusic-msid-00 to -01 . . . . . . 14 C.4. Changes from alvestrand-mmusic-msid-00 to -01 . . . . . . 14
C.5. Changes from alvestrand-mmusic-msid-01 to -02 . . . . . . 14 C.5. Changes from alvestrand-mmusic-msid-01 to -02 . . . . . . 14
C.6. Changes from alvestrand-mmusic-msid-02 to C.6. Changes from alvestrand-mmusic-msid-02 to
ietf-mmusic-00 . . . . . . . . . . . . . . . . . . . . . . 14 ietf-mmusic-00 . . . . . . . . . . . . . . . . . . . . . . 14
C.7. Changes from mmusic-msid-00 to -01 . . . . . . . . . . . . 14 C.7. Changes from mmusic-msid-00 to -01 . . . . . . . . . . . . 14
C.8. Changes from mmusic-msid-01 to -02 . . . . . . . . . . . . 14 C.8. Changes from mmusic-msid-01 to -02 . . . . . . . . . . . . 14
C.9. Changes from mmusic-msid-02 to -03 . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
1.1. Structure Of This Document 1.1. Structure Of This Document
This document adds a new grouping relation between M-lines that can This document adds a new grouping relation between M-lines that can
associate application layer identifiers with the binding between associate application layer identifiers with the binding between
media streams, attaching identifiers to the media streams and media streams, attaching identifiers to the media streams and
attaching identifiers to the groupings they form. attaching identifiers to the groupings they form.
skipping to change at page 3, line 49 skipping to change at page 3, line 49
signal some relationship between RTP media streams that may be signal some relationship between RTP media streams that may be
carried in either the same RTP session or different RTP sessions. carried in either the same RTP session or different RTP sessions.
For instance, there may be a need to signal a relationship between a For instance, there may be a need to signal a relationship between a
video track and an audio track, and where the generator of the SDP video track and an audio track, and where the generator of the SDP
does not yet know if they will be carried in the same RTP session or does not yet know if they will be carried in the same RTP session or
different RTP sessions. different RTP sessions.
The SDP grouping framework [RFC5888] can be used to group m-lines. The SDP grouping framework [RFC5888] can be used to group m-lines.
However, there is sometimes the need for an application to specify However, there is sometimes the need for an application to specify
some application-level information about the association between the some application-level information about the association between the
SSRC and the group. This is not possible using the SDP grouping m-line and the group. This is not possible using the SDP grouping
framework. framework.
1.3. Application to the WEBRTC MediaStream 1.3. Application to the WEBRTC MediaStream
The W3C WebRTC API specification [W3C.WD-webrtc-20120209] specifies The W3C WebRTC API specification [W3C.WD-webrtc-20120209] specifies
that communication between WebRTC entities is done via MediaStreams, that communication between WebRTC entities is done via MediaStreams,
which contain MediaStreamTracks. A MediaStreamTrack is generally which contain MediaStreamTracks. A MediaStreamTrack is generally
carried using a single SSRC in an RTP session (forming an RTP media carried using a single SSRC in an RTP session (forming an RTP media
stream. The collision of terminology is unfortunate.) There might stream. The collision of terminology is unfortunate.) There might
possibly be additional SSRCs, possibly within additional RTP possibly be additional SSRCs, possibly within additional RTP
skipping to change at page 5, line 25 skipping to change at page 5, line 26
Application data is carried on the same line as the identifier, Application data is carried on the same line as the identifier,
separated from the identifier by a space. separated from the identifier by a space.
The identifier uniquely identifies a group within the scope of an SDP The identifier uniquely identifies a group within the scope of an SDP
description. description.
There may be multiple msid attributes on a single m-line. There may There may be multiple msid attributes on a single m-line. There may
also be multiple m-lines that have the same value for identifier and also be multiple m-lines that have the same value for identifier and
application data. application data.
Endpoints can update the associations between SSRCs as expressed by Endpoints can update the associations between RTP media streams as
msid attributes at any time; the semantics and restrictions of such expressed by msid attributes at any time; the semantics and
grouping and ungrouping are application dependent. restrictions of such grouping and ungrouping are application
dependent.
3. The Msid-Semantic Attribute 3. The Msid-Semantic Attribute
A session-level attribute is defined for signaling the semantics A session-level attribute is defined for signaling the semantics
associated with an msid grouping. This allows msid groupings with associated with an msid grouping. This allows msid groupings with
different semantics to coexist. different semantics to coexist.
This OPTIONAL attribute gives the group identifier and its group This OPTIONAL attribute gives the group identifier and its group
semantic; it carries the same meaning as the ssrc-group-attr of RFC semantic; it carries the same meaning as the ssrc-group-attr of RFC
5576 section 4.2, but uses the identifier of the group rather than a 5576 section 4.2, but uses the identifier of the group rather than a
list of SSRC values. list of SSRC values.
This attribute MUST be present if "a=msid" is used. This attribute MUST be present if "a=msid" is used.
An empty list of identifiers is an indication that the sender An empty list of identifiers is an indication that the sender
understands the indicated semantic, but has no msid groupings of the understands the indicated semantic, but has no msid groupings of the
given type in the present SDP. given type in the present SDP.
An identifier of "*" is an indication that all "a=msid" lines in the
SDP have this specific semantic.
The ABNF of msid-semantic is: The ABNF of msid-semantic is:
attribute =/ msid-semantic-attr attribute =/ msid-semantic-attr
msid-semantic-attr = "msid-semantic:" token (" " identifier)* msid-semantic-attr = "msid-semantic:" token identifier-list
identifier-list = (" " identifier)* / " *"
token = <as defined in RFC 4566> token = <as defined in RFC 4566>
The semantic field may hold values from the IANA registriy "Semantics The semantic field may hold values from the IANA registriy "Semantics
for the msid-semantic SDP attribute" (which is defined by this memo). for the msid-semantic SDP attribute" (which is defined by this memo).
An example msid-semantic might look like this, if a semantic LS was An example msid-semantic might look like this, if a semantic LS was
registered by IANA for the same purpose as the existing LS grouping registered by IANA for the same purpose as the existing LS grouping
semantic: semantic:
a=msid-semantic:LS xyzzy forolow a=msid-semantic:LS xyzzy forolow
This means that the SDP description has two lip sync groups, with the This means that the SDP description has two lip sync groups, with the
group identifiers xyzzy and forolow, respectively. group identifiers xyzzy and forolow, respectively.
4. Applying Msid to WebRTC MediaStreams 4. Applying Msid to WebRTC MediaStreams
This section creates a new semantic for use with the framework This section creates a new semantic for use with the framework
defined in Section 2, to be used for associating SSRCs representing defined in Section 2, to be used for associating m-lines representing
MediaStreamTracks within MediaStreams as defined in MediaStreamTracks within MediaStreams as defined in
[W3C.WD-webrtc-20120209]. [W3C.WD-webrtc-20120209].
The semantic token for this semantic is "WMS" (short for WebRTC Media The semantic token for this semantic is "WMS" (short for WebRTC Media
Stream). Stream).
The value of the msid corresponds to the "id" attribute of a The value of the msid corresponds to the "id" attribute of a
MediaStream. MediaStream.
In a WebRTC-compatible SDP description, all SSRCs intending to be
sent from one peer will be identified in the SDP generated by that
entity.
The appdata for a WebRTC MediaStreamTrack consists of the "id" The appdata for a WebRTC MediaStreamTrack consists of the "id"
attribute of a MediaStreamTrack. attribute of a MediaStreamTrack.
If two different m-lines have MSID attributes with the same value for If two different m-lines have MSID attributes with the same value for
identifier and appdata, it means that these two m-lines are both identifier and appdata, it means that these two m-lines are both
intended for the same MediaStreamTrack. So far, no semantic for such intended for the same MediaStreamTrack. So far, no semantic for such
a mixture have been defined, but this specification does not forbid a mixture have been defined, but this specification does not forbid
the practice. the practice.
When an SDP description is updated, a specific msid continues to When an SDP description is updated, a specific msid continues to
skipping to change at page 9, line 4 skipping to change at page 9, line 6
This document requests IANA to register the "msid" attribute in the This document requests IANA to register the "msid" attribute in the
"att-field (media level only)" registry within the SDP parameters "att-field (media level only)" registry within the SDP parameters
registry, according to the procedures of [RFC4566] registry, according to the procedures of [RFC4566]
The required information is: The required information is:
o Contact name, email: IETF, contacted via mmusic@ietf.org, or a o Contact name, email: IETF, contacted via mmusic@ietf.org, or a
successor address designated by IESG successor address designated by IESG
o Attribute name: msid o Attribute name: msid
o Long-form attribute name: Media stream group Identifier o Long-form attribute name: Media stream group Identifier
o The attribute value contains only ASCII characters, and is o The attribute value contains only ASCII characters, and is
therefore not subject to the charset attribute. therefore not subject to the charset attribute.
o The attribute gives an association over a set of m-lines. It can o The attribute gives an association over a set of m-lines. It can
be used to signal the relationship between a WebRTC MediaStream be used to signal the relationship between a WebRTC MediaStream
and a set of SSRCs. and a set of m-lines.
o The details of appropriate values are given in RFC XXXX. o The details of appropriate values are given in RFC XXXX.
This document requests IANA to create a new registry called This document requests IANA to create a new registry called
"Semantics for the msid-semantic SDP attribute", which should have "Semantics for the msid-semantic SDP attribute", which should have
exactly the same rules as for the "Semantics for the ssrc-group SDP exactly the same rules as for the "Semantics for the ssrc-group SDP
attribute" registry (Expert Review), and to register the "WMS" attribute" registry (Expert Review), and to register the "WMS"
semantic within this new registry. semantic within this new registry.
The required information is: The required information is:
skipping to change at page 15, line 5 skipping to change at page 15, line 9
Corrected several missed cases where the word "ssrc" was not changed Corrected several missed cases where the word "ssrc" was not changed
to "M-line". to "M-line".
Added pointer to unified-plan (which should be moved to point to Added pointer to unified-plan (which should be moved to point to
-jsep) -jsep)
Removed suggestion that ssrc-group attributes can be used with "msid- Removed suggestion that ssrc-group attributes can be used with "msid-
semantic", it is now only the msid-semantic registry. semantic", it is now only the msid-semantic registry.
C.9. Changes from mmusic-msid-02 to -03
Corrected even more cases where the word "ssrc" was not changed to
"M-line".
Added the functionality of using an asterisk (*) in the msid-semantic
line, in order to remove the need for listing all msids in the msid-
semantic line whne only one msid-semantic is in use.
Removed some now-unnecessary text.
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. 17 change blocks. 
18 lines changed or deleted 33 lines changed or added

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