Subject: [MMUSIC] Fwd: New Version Notification for draft-ietf-mmusic-msid-01.txt

From: Harald Alvestrand <[email-masked]>
Date: Tue, 13 Aug 2013 14:24:04 +0200

The auto-poster doesn't seem to want to tell mmusic about this....

this is updated according to Unified-plan. Since it was only 1 day 
before the old version had expired, the proofreading might be a little 
light - please point out places where I had missed changing "SSRC" to 
"m-line"!

I retained some description of the old mechanism (using a=ssrc) in an 
appendix. Please state opinions on whether this should be retained as 
informative, promoted to normative, or removed entirely in the next version.

Hope this informs!

        Harald

-------- Original Message --------
Subject: 	New Version Notification for draft-ietf-mmusic-msid-01.txt
Date: 	Tue, 13 Aug 2013 05:13:42 -0700
From: 	[email-masked]
To: 	Harald T. Alvestrand <[email-masked]>, Harald Alvestrand 
<[email-masked]>

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

Filename:	 draft-ietf-mmusic-msid
Revision:	 01
Title:		 Cross Session Stream Identification in the Session Description Protocol
Creation date:	 2013-08-13
Group:		 mmusic
Number of pages: 14
URL:             http://www.ietf.org/internet-drafts/draft-ietf-mmusic-msid-01.txt
Status:          http://datatracker.ietf.org/doc/draft-ietf-mmusic-msid
Htmlized:        http://tools.ietf.org/html/draft-ietf-mmusic-msid-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msid-01

Abstract:
    This document specifies a 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 "m-line" 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: Wed, 14 Aug 2013 19:28:13 +0200

I have a fundamental question about this draft:

With Unified Plan we have a unique m-line for every MediaStreamTrack.
Given that, why do we need the msid attribute? Isn't it sufficient to 
define a new semantic ("mediastream"?) for the grouping framework? 
(RFC3388).

There would still be need for a way to convey the application data, but 
that can be done via another attribute ("mediastream-data"?) associated 
with the m-line.

	Thanks,
	Paul

On 8/13/13 2:24 PM, Harald Alvestrand wrote:
> URL:http://www.ietf.org/internet-drafts/draft-ietf-mmusic-msid-01.txt
> Status:http://datatracker.ietf.org/doc/draft-ietf-mmusic-msid
> Htmlized:http://tools.ietf.org/html/draft-ietf-mmusic-msid-01
> Diff:http://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-msid-01
>
> Abstract:
>     [email-masked].
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 15 Aug 2013 16:58:39 +0200

On 08/14/2013 07:28 PM, Paul Kyzivat wrote:
> There would still be need for a way to convey the application data,
> but that can be done via another attribute ("mediastream-data"?)
> associated with the m-line.

I wondered about that too.
We have two IDs to convey:

- The ID of the MediaStream. The grouping can be a new semantic for the
grouping framework, but the actual ID value has to be carried somewhere
- it has to be associated with the group, so it can't be a session-level
attribute.

- The ID of the MediaStreamTrack. Now that MediaStreamTracks correspond
to m-lines, it makes sense to carry this in a media-level attribute.

I'm sure we can design another scheme for carrying those IDs around.
But I do wonder what the positive value of restructuring this is.

---

From: Martin Thomson <[email-masked]>
Date: Thu, 15 Aug 2013 16:32:31 +0100

> But I do wonder what the positive value of restructuring this is.

The MediaStream identifier gets lost if the grouping framework is
used.  Unless you define some sort of new mapping attribute, which
could end up looking like a=msid if you aren't careful.

The MediaStreamTrack identifier could be doubled onto the a=mid value.

I've always been lukewarm on transmitting identifiers in this fashion,
but I find it hard to find a better (i.e., cleaner, more obvious, less
redundant) solution than msid, except perhaps this one:

a=appgroup:MediaStreamId Track1 Track2
a=group:LS Track1 Track2
m=...
a=mid:Track1
m=...
a=mid:Track2

--Martin

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 15 Aug 2013 13:15:59 -0400

I went through this version, with an eye to alignment with the Unified 
Plan. I have a number of comments, some nits, some not:

General:

The Unified Plan says a single m-line describes one media source. It 
allows this source to consist of multiple RTP Streams (identified by 
SSRC). And it allows associating RTP Streams with m-lines multiple ways, 
not just by SSRC.

This msid draft hasn't fully incorporated those concepts. It still seems 
to assume that a media source corresponds to a single SSRC. It would be 
helpful to have a section discussion the process of associating SSRCs to 
MedisStreamTracks. (And I think this needs to include the possibility 
that an SSRC might be moved from one MediaStreamTrack to another.)

Section 2:

    The identifier is a string of ASCII characters chosen from 0-9, a-z,
    A-Z and - (hyphen), consisting of between 1 and 64 characters.  It
    MUST be unique among the identifier values used in the same SDP
    session.  It is RECOMMENDED that is generated using a random-number
    generator.
...
    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
    application data.

What does uniqueness mean in this context, since it can be used multiple 
times, with the same or different m-lines? I *think* you mean that a 
given identifier value is associated with a single MediaStream for the 
duration of the SDP session.

Also, msid attributes aren't "on" an m-line. I think it would be clearer 
to say "Multiple msid attributes may be associated with a single 
m-line." But with the Unified Plan this isn't true.

Also, I find the use of "identifier" and "token" very confusing. It is 
hard to keep track of the semantics intended for those things. It would 
be easier to follow if some more specific terms were used. For example, 
"mediastream-id" instead of "identifier" in the msid and msid-semantics 
attributes, and "semantics" instead of "token" in msid-semantics 
attribute. ("semantics" is what is used in 3388 and 5576.)

Section 4:

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

Is SSRC relevant any longer? s/SSRCs/m-lines/ ???

Also in Section 4:

    In addition to signaling that the track is closed when it disappears
    from the SDP, the track will also be signaled as 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).

Here we can't avoid talking about SSRCs. But maybe more is needed about 
what SSRCs are associated with a particular m-line & msid value?

Section 4.1:

    Pre-WebRTC entities will not send msid.  This means that there will
    be some incoming RTP packets with SSRCs where the recipient does not
    know about a corresponding MediaStream id.

In the context of the Unified Plan I think this could be stated better:

    There may be some incoming RTP packets that the recipient cannot
    associate with a MediaStreamTrack.

Also:

    o  An msid-semantic:WMS attribute is present.  In this case, the
       session is WebRTC compatible, and the newly arrived SSRCs are
       either caused by a bug or by timing skew between the arrival of
       ...

I suggest:

    o  An msid-semantic:WMS attribute is present.  In this case, the
       session is WebRTC compatible, and the unassociated packets are
       either caused by a bug or by timing skew between the arrival of
       ...

	Thanks,
	Paul

---

From: Harald Alvestrand <[email-masked]>
Date: Mon, 19 Aug 2013 16:57:35 +0200

> Plan. I have a number of comments, some nits, some not:

Thanks for doing this quickly!

I've incorporated these changes (with some rewording, as always). I'll 
give this a few more days to stew, and then emit a new version.

> SSRC). And it allows associating RTP Streams with m-lines multiple 
> ways, not just by SSRC.
>
> This msid draft hasn't fully incorporated those concepts. It still 
> seems to assume that a media source corresponds to a single SSRC. It 
> would be helpful to have a section discussion the process of 
> associating SSRCs to MedisStreamTracks. (And I think this needs to 
> include the possibility that an SSRC might be moved from one 
> MediaStreamTrack to another.)

I tried replacing every occurence of SSRC with m-line, except where that 
didn't make sense (and in Appendix B, of course). Please point at the 
text where I missed, if it's not covered below!

> What does uniqueness mean in this context, since it can be used 
> multiple times, with the same or different m-lines? I *think* you mean 
> that a given identifier value is associated with a single MediaStream 
> for the duration of the SDP session.

Yes, but I can't write that in section 2, since MediaStreams aren't 
introduced until section 4. The meaning of "uniqueness" has to be 
defined by the msid-semantic, I think - should I add a sentence saying 
that this is so?

(It's tempting to declare that msid is useless for anything except 
WebRTC. But the Paris (?) IETF meeting told me to write a generic 
mechanism with a WebRTC specialization, so that's how it's written.)

>
> Also, msid attributes aren't "on" an m-line. I think it would be 
> clearer to say "Multiple msid attributes may be associated with a 
> single m-line." But with the Unified Plan this isn't true.

Sorry?

I think it's legal to say

m=video
a=msid: 1234 567
a=msid: ABCD EFG

This would mean (for the WMS context) that the same media content is 
present in both MediaStream 1234 and MediaStream ABCD, with 
MediaStreamTrack ids 567 and EFG, respectively.
> hard to keep track of the semantics intended for those things. It 
> would be easier to follow if some more specific terms were used. For 
> example, "mediastream-id" instead of "identifier" in the msid and 
> msid-semantics attributes, and "semantics" instead of "token" in 
> msid-semantics attribute. ("semantics" is what is used in 3388 and 5576.)

You're talking about the ABNF in sections 2 and 3 now, right?
We could use more meaningful names for the tokens, but it's just another 
level of indirection - generally, I don't find that specs become much 
more readable by repeated productions of the form

    name1 = name2

unless we have to refer to the tokens by name from surrounding text.
But your mileage may vary.
> Is SSRC relevant any longer? s/SSRCs/m-lines/ ???

Yep, I missed that (multiple misses in that section). Will update.

> Here we can't avoid talking about SSRCs. But maybe more is needed 
> about what SSRCs are associated with a particular m-line & msid value?

Since this is in section 4 (WebRTC), I can happily point that problem 
off to unified-plan or its successors.
>    associate with a MediaStreamTrack.

Rephrased, not quite like this.

>       either caused by a bug or by timing skew between the arrival of

Done.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Aug 2013 15:28:29 -0400

inline

> text where I missed, if it's not covered below!

I didn't have anything specific in mind other than what is below.
But I just got the feeling when reading it that it was still oriented 
towards the old model.

> defined by the msid-semantic, I think - should I add a sentence saying

In part it is just nit picking by me.
It might be that you can just not say this at all, at least here.
In the context in which the statement is made it is hard to see what 
sort of uniqueness is being required.

> mechanism with a WebRTC specialization, so that's how it's written.)

IIUC, MediaStreamTrack ought to be synonymous with a CLUE 
capture-encoding. But I don't think we have anything in CLUE that 
corresponds to a MediaStream. I don't understand MediaStream very well, 
but perhaps it is indeed unique to WebRTC.

The taxonomy draft is perhaps the right reference here.

>> single m-line." But with the Unified Plan this isn't true.

I'm picking at the meaning of words. To me "on" an m-line means that it 
is present within the characters that comprise the m-line itself. No 
"attribute" works that way.

I presume you are using "on" as synonymous with "attached to", or 
"associated with". So I was simply suggesting being more explicit.

> MediaStreamTrack ids 567 and EFG, respectively.

I wasn't talking about any of that.

Its a WebRTC issue whether the same logical stream of packets can be 
part of multiple MediaStreams or MediaStreamTracks. So I'll take your 
word for it.

> You're talking about the ABNF in sections 2 and 3 now, right?

Yes.

> unless we have to refer to the tokens by name from surrounding text.

It words two ways:
- the text referring back to the elements from the ABNF
- when I look at the ABNF, understanding what concept in the text
   this element refers to.

When reading, I encountered both of those problems.
Eventually I can figure it out by going through an exercise of "what 
could this possibly mean". But it would be nice if it was clearer

	Thanks,
	Paul

> But your mileage may vary.

I realize this is to some extent a matter of taste.

Personally, I find that ABNF non-terminals are cheap, so I am happy to 
use more of them to increase clarity. In particular I'm inclined to 
ensure that there is a well-named non-terminal for every element that 
needs to be referenced from the text.

	Thanks,
	Paul