Subject: [MMUSIC] MSID draft -09 posted

From: Harald Alvestrand <[email-masked]>
Date: Tue, 21 Apr 2015 13:17:05 +0200

See below - this implements the decision from Dallas to turn MSID into a
single mechanism rather than a generic framework for creating new
mechanisms.

This saved ~2 pages; there are sure to be inconsistencies, but the core
job is done.
Happy reading!

         Harald

-------- Videresendt melding --------
Emne: New Version Notification for draft-ietf-mmusic-msid-09.txt
Dato: Tue, 21 Apr 2015 04:14:54 -0700
Fra: [email-masked]
Til: Harald T. Alvestrand <[email-masked]>, Harald Alvestrand
<[email-masked]>

A new version of I-D, draft-ietf-mmusic-msid-09.txt
has been successfully submitted by Harald Alvestrand and posted to the
IETF repository.

Name:		draft-ietf-mmusic-msid
Revision:	09
Title:		WebRTC MediaStream Identification in the Session Description
Protocol
Document date:	2015-04-21
Group:		mmusic
Pages:		15
URL:
http://www.ietf.org/internet-drafts/draft-ietf-mmusic-msid-09.txt
Status:         https://datatracker.ietf.org/doc/draft-ietf-mmusic-msid/
Htmlized:       http://tools.ietf.org/html/draft-ietf-mmusic-msid-09
Diff:           http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msid-09

Abstract:
   This document specifies a Session Description Protocol (SDP) Grouping
   mechanism for RTP media streams that can be used to specify relations
   between media streams.

   This mechanism is used to signal the association between the SDP
   concept of "media description" and the WebRTC concept of
   "MediaStream" / "MediaStreamTrack" using SDP signaling.

   This document is a work item of the MMUSIC WG, whose discussion list
   is [email-masked].

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 21 Apr 2015 12:25:55 -0400

This draft is a lot simpler to review with its reduced scope!

I have a few comments:

* Section 2:

    ... This new attribute allows endpoints to associate RTP
    media streams that are carried in *the same or* different media
    descriptions. ...

How do you associate distinct MSIDs to media streams in *the same* media 
description??? AFAIK that isn't possible - each media description is a 
distinct media stream.

* Section 3:

    The semantic token for this semantic is "WMS" (short for WebRTC Media
    Stream).

The above seems to be a leftover that should be removed.

IMO the following is very confusing in its use of "description". I've 
highlighted the points at issue with *s:

    The following are the rules for handling updates of the list of
    *media descriptions* and their msid values.

    o  When a new msid "identifier" value occurs in *the* description the
       recipient can signal to its application that a new MediaStream has
       been added.

    o  When *a description* is updated to have more media descriptions
       with the same msid "identifier" value, but different "appdata"
       values, the recipient can signal to its application that new
       MediaStreamTracks have been added to the MediaStream.

    o  When *a description* is updated to no longer list any msid
       values, on a specific media description, the recipient can signal
       to its application that the corresponding MediaStreamTrack has
       ended.

I *think* that in some cases you mean *session description* (the whole 
SDP), and in other cases you mean *media description* (m-line and the 
associated following non-m-lines.) Perhaps:

    The following are the rules for handling updates of the list of media
    descriptions and their msid values.

    o  When a new msid "identifier" value occurs in a media description,
       the recipient can signal to its application that a new
       MediaStream has been added.

    o  When a session description is updated to have more media
       descriptions with the same msid "identifier" value, but different
       "appdata" values, the recipient can signal to its application
       that new MediaStreamTracks have been added to the MediaStream.

    o  When a session description is updated to no longer list any msid
       attribute on a specific media description, the recipient can
       signal to its application that the corresponding MediaStreamTrack
       has ended.

* Section 3.2.2:

    For each media description in the offer, and for each "a=msid"
    attribute in the media description where the "msid-id" is associated
    with the "WMS" semantic, the receiver of the offer will perform the
    following steps:

In the above, there is still reference to WMS semantic that should be 
removed.

Also, this again implies that there might be multiple a=msid lines in a 
single media description. How about:

    For each media description in the offer that contains an "a=msid"
    attribute, the receiver of the offer will perform the following
    steps:

	Thanks,
	Paul

On 4/21/15 7:17 AM, Harald Alvestrand wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 23 Apr 2015 14:49:51 +0200

> This draft is a lot simpler to review with its reduced scope!

Thanks for the quick review!
> description??? AFAIK that isn't possible - each media description is a

Yes, this is a leftover from "plan b". Deleting.
Also, it should be "described", not "carried" - they're carried in RTP
sessions, and described in media descriptions.

> The above seems to be a leftover that should be removed.

Yep.

> highlighted the points at issue with *s:

This is a result of the wholesale replacement of "m-line" with "media
description" - the meanings are unchanged, but it's a bit more obvious
where the grammar is convoluted.

>       signal to its application that the corresponding MediaStreamTrack

Seems much better, I adapted some more - the use of standalone
"description" was a bad idea, and I think I've fixed that.

> In the above, there is still reference to WMS semantic that should be

Removed!

>    attribute, the receiver of the offer will perform the following

Actually this is intended to allow for one track being part of multiple
MediaStreams. If we have:

m=video
a=msid stream1 track1
a=msid stream2 track1

this would say "track1 is only sent once, but it appears as part of two
MediaStreams".

The API for PeerConnection still allows that. So I need to allow it here
too.

I put up the changes I made here:

https://github.com/alvestrand/rtcweb-msid/pull/4

Will leave them up there for a day or two, and submit a -10 if there
aren't further comments.

Thanks again!

   Harald

---

From: Harald Alvestrand <[email-masked]>
Date: Tue, 28 Apr 2015 14:46:32 +0200

I have now posted -10 with the changes to address Paul's review.
Thanks again!

Harald