draft-ietf-mmusic-msid-09.txt   draft-ietf-mmusic-msid-10.txt 
Network Working Group H. Alvestrand Network Working Group H. Alvestrand
Internet-Draft Google Internet-Draft Google
Intended status: Standards Track April 21, 2015 Intended status: Standards Track April 28, 2015
Expires: October 23, 2015 Expires: October 30, 2015
WebRTC MediaStream Identification in the Session Description Protocol WebRTC MediaStream Identification in the Session Description Protocol
draft-ietf-mmusic-msid-09 draft-ietf-mmusic-msid-10
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 October 23, 2015. This Internet-Draft will expire on October 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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
skipping to change at page 4, line 39 skipping to change at page 4, line 39
specify the ID of a MediaStreamTrack and its associated MediaStream specify the ID of a MediaStreamTrack and its associated MediaStream
for each media description, which can be accomplished with a media- for each media description, which can be accomplished with a media-
level SDP attribute. level SDP attribute.
This usage is described in Section 3. This usage is described in Section 3.
2. The Msid Mechanism 2. The Msid Mechanism
This document defines a new SDP [RFC4566] media-level "msid" This document defines a new SDP [RFC4566] media-level "msid"
attribute. This new attribute allows endpoints to associate RTP attribute. This new attribute allows endpoints to associate RTP
media streams that are carried in the same or different media media streams that are described in different media descriptions.
descriptions. The attribute also allows application-specific The attribute also allows application-specific information to the
information to the association. association.
The value of the "msid" attribute consists of an identifier and The value of the "msid" attribute consists of an identifier and
optional application-specific data. optional application-specific data.
The name of the attribute is "msid". The name of the attribute is "msid".
The value of the attribute is specified by the following ABNF The value of the attribute is specified by the following ABNF
[RFC5234] grammar: [RFC5234] grammar:
msid-value = msid-id [ SP msid-appdata ] msid-value = msid-id [ SP msid-appdata ]
skipping to change at page 5, line 41 skipping to change at page 5, line 41
3. Procedures 3. Procedures
This section describes how to use the msid-semantic attribute for This section describes how to use the msid-semantic attribute for
associating media descriptions representing MediaStreamTracks within associating media descriptions representing MediaStreamTracks within
MediaStreams as defined in [W3C.WD-webrtc-20150210]. MediaStreams as defined in [W3C.WD-webrtc-20150210].
In the Javascript API, each MediaStream and MediaStreamTrack has an In the Javascript API, each MediaStream and MediaStreamTrack has an
"id" attribute, which is a DOMString. "id" attribute, which is a DOMString.
The semantic token for this semantic is "WMS" (short for WebRTC Media
Stream).
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 its WebIDL specification. attribute of a MediaStream, as defined in its WebIDL specification.
The value of the "msid-appdata" field in the msid consists of the The value of the "msid-appdata" field in the msid consists of the
"id" attribute of a MediaStreamTrack, as defined in its WebIDL "id" attribute of a MediaStreamTrack, as defined in its WebIDL
specification. specification.
If two different media descriptions have MSID attributes with the If two different media descriptions have MSID attributes with the
same values for "msid-id" and "msid-appdata", it means that these two same values for "msid-id" and "msid-appdata", it means that these two
media descriptions are both intended for the same MediaStreamTrack. media descriptions are both intended for the same MediaStreamTrack.
skipping to change at page 6, line 8 skipping to change at page 6, line 4
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 its WebIDL specification. attribute of a MediaStream, as defined in its WebIDL specification.
The value of the "msid-appdata" field in the msid consists of the The value of the "msid-appdata" field in the msid consists of the
"id" attribute of a MediaStreamTrack, as defined in its WebIDL "id" attribute of a MediaStreamTrack, as defined in its WebIDL
specification. specification.
If two different media descriptions have MSID attributes with the If two different media descriptions have MSID attributes with the
same values for "msid-id" and "msid-appdata", it means that these two same values for "msid-id" and "msid-appdata", it means that these two
media descriptions are both intended for the same MediaStreamTrack. media descriptions are both intended for the same MediaStreamTrack.
So far, no semantic for such a mixture have been defined, but this So far, no semantic for such a mixture have been defined, but this
specification does not forbid the practice. specification does not forbid the practice.
When an SDP description is updated, a specific "msid-id" continues to When an SDP session description is updated, a specific "msid-id"
refer to the same MediaStream, and a specific "msid-appdata" to the continues to refer to the same MediaStream, and a specific "msid-
same MediaStreamTrack. There is no memory apart from the currently appdata" to the same MediaStreamTrack. There is no memory apart from
valid SDP descriptions; if an msid "identifier" value disappears from the currently valid SDP descriptions; if an msid "identifier" value
the SDP and appears in a later negotiation, it will be taken to refer disappears from the SDP and appears in a later negotiation, it will
to a new MediaStream. be taken to refer to a new MediaStream.
The following are the rules for handling updates of the list of media The following is a high level description of the rules for handling
descriptions and their msid values. SDP updates. Detailed procedures are in Section 3.2.
o When a new msid "identifier" value occurs in the description, the o When a new msid "identifier" value occurs in a session
recipient can signal to its application that a new MediaStream has description, the recipient can signal to its application that a
been added. new MediaStream has been added.
o When a description is updated to have more media descriptions with o When a session description is updated to have media descriptions
the same msid "identifier" value, but different "appdata" values, with an msid "identifier" value, with one or more different
the recipient can signal to its application that new "appdata" values, the recipient can signal to its application that
MediaStreamTracks have been added to the MediaStream. new MediaStreamTracks have been added to the MediaStream. This is
done for each different msid "identifier" value.
o When a description is updated to no longer list any msid attribute o When a session description is updated to no longer list any msid
on a specific media description, the recipient can signal to its attribute on a specific media description, the recipient can
application that the corresponding MediaStreamTrack has ended. signal to its application that the corresponding MediaStreamTrack
has ended.
In addition to signaling that the track is closed when its msid In addition to signaling that the track is closed 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 closed when all associated SSRCs have disappeared by the rules being closed 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),
and when the corresponding media description is disabled by setting and when the corresponding media description is disabled by setting
the port number to zero. Changing the direction of the media the port number to zero. Changing the direction of the media
description (by setting "sendonly", "recvonly" or "inactive" description (by setting "sendonly", "recvonly" or "inactive"
attributes) will not close the MediaStreamTrack. (This mechanism may attributes) will not close the MediaStreamTrack. (This mechanism may
be used to signal that a particular MediaStreamTrack should be put on be used to signal that a particular MediaStreamTrack should be put on
skipping to change at page 8, line 24 skipping to change at page 8, line 24
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, and the "appdata" field is
set to the WebIDL "id" attribute of the MediaStreamTrack. set to the WebIDL "id" attribute of the MediaStreamTrack.
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 where the "msid-id" is associated attribute in the media description, the receiver of the offer will
with the "WMS" semantic, the receiver of the offer will perform the perform the following steps:
following steps:
o Extract the "appdata" field of the "a=msid" attribute o Extract the "appdata" field of the "a=msid" attribute
o Check if a MediaStreamTrack with the same WebIDL "id" attribute as o Check if a MediaStreamTrack with the same WebIDL "id" attribute as
the "appdata" field already exists, and is not in the "ended" the "appdata" field already exists, and is not in the "ended"
state. If it is not found, create it. state. If it is not found, create it.
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
 End of changes. 12 change blocks. 
31 lines changed or deleted 30 lines changed or added

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