Subject: [MMUSIC] Review of unified-plan-00

From: Harald Alvestrand <[email-masked]>
Date: Thu, 18 Jul 2013 11:40:40 +0200

First of all, let me say that I'm very happy to see a plan that the 
people who have been voicing the strongest opinions in this debate are 
willing to stand behind.
I believe, extremely strongly, that it is better to move forward on one 
path, no matter what it is (as long as it's not obviously broken), than 
to continue to debate. This topic has long been needing a decision.

Thus, I stand behind the technology proposed, and have no wish to change 
it. The purpose of this review is to help make sure it's fully 
described, and that all parties understand it the same way.

I have ignored language-only issues at this time.

Introduction, paragraph 2:

    The standard way of encoding this information in SDP is to have each
    RTP flow (i.e., SSRC) appear on its own m-line.

This is not strictly true, since the proposal continues to use each 
m-line for up to two flows, one in each direction, and some of the . 
Suggested rephrase:

   One common way of encoding this information uses each M-line to
   describe one media source in each direction.

"media source" is as defined in 
draft-westerlund-avtcore-multiplex-architecture-03 section 2.1. The term 
is used elsewhere in the document, and seems to have this meaning. "One 
common" is a reflection of my belief that practice has not been uniform 
in this area.

3.1, Bundle-only M-lines

This mechanism requires sending M-lines with port zero as part of a 
bundle in an SDP OFFER.
It needs to note that this specification modifies RFC 5888 section 9.2 
(the grouping framework) by allowing such M-lines to be part of a group 
in an offer (but I do not think it needs to be allowed in an answer).

4.1 Simple example

"It also shows unique payload across the audio and video m=lines for the 
Answerer that does not support BUNDLE semantics." - this doesn't make 
sense to me; unique payloads are needed for answerers that support 
BUNDLE semantics. Copy/paste error?

Would be consistent if it said "for the Answerer that supports BUNDLE 
semantics".

4.4 Multiple Video with Simulcast

If it's intended that draft-westerlund-avtcore-rtp-simulcast is used, 
the ssrc-group lines should probably say SCS rather than SIMULCAST.

And now for some stuff that isn't in the document, but might want to be:

More examples

There should probably be one example where the offer contains 1 audio 
and 2 video streams, and the answer contains 1 audio and 1 video stream 
(fewer streams in response than in request); I believe that this answer 
would then contain "a=recvonly" and no "a=msid" attribute on the 3rd 
m-line, but it's nice to be sure.

Interaction with a=content

Previously, we had discussed having a "content" attribute on 
MediaStreamTracks that would make a track link to an m-line with the 
same "a=content" attribute. If this is still expected to work, it might 
be worthy of inclusion here.

I think that's all for this round of review. Thanks for getting it out!

             Harald

---

From: Martin Thomson <[email-masked]>
Date: Thu, 18 Jul 2013 10:06:48 -0700

On 18 July 2013 02:40, Harald Alvestrand <[email-masked]> wrote:
> This is not strictly true, since the proposal continues to use each m-line
> for up to two flows, one in each direction, and some of the . Suggested
> rephrase:
>

That's fine with me.  It seems that there is some contention around
what an m-line actually is, and this has no substantive impact.  So
weasel away.

> It needs to note that this specification modifies RFC 5888 section 9.2

Yes.  We've talked about that lots, but we missed it somehow.

> Answerer that does not support BUNDLE semantics." - this doesn't make sense
> to me; unique payloads are needed for answerers that support BUNDLE
> semantics. Copy/paste error?
>

Actually, this has nothing to do with BUNDLE.  It assumes that you
support BUNDLE, but might not support the RTP header extension and
might want to have media play out at the offerer prior to receiving an
answer.

> If it's intended that draft-westerlund-avtcore-rtp-simulcast is used, the
> ssrc-group lines should probably say SCS rather than SIMULCAST.

Maybe this is a veiled comment along the lines of : "SCS" is a
strangely perverse choice of label, why don't you call a spade a spade
:)

> MediaStreamTracks that would make a track link to an m-line with the same
> "a=content" attribute. If this is still expected to work, it might be worthy
> of inclusion here.

The purpose to which a=content was put in plan B isn't really
necessary any more.  No actual feature would depend on this, so don't
see a particular reason to mention this in the plan.

Maybe this is one of the SDP mutations we've been looking for.
Perhaps you can take this to the W3C.

---

From: Harald Alvestrand <[email-masked]>
Date: Thu, 18 Jul 2013 23:04:27 +0200

> might want to have media play out at the offerer prior to receiving an

Since all the sentences talking about it have the word BUNDLE in them, I
have to assume it has *something* to do with BUNDLE. It's just that the
sign bit seemed wrong.

> strangely perverse choice of label, why don't you call a spade a spade

I'd be happy to argue for use of a more readable label :-)

> Perhaps you can take this to the W3C.

Cullen claimed at one point that a=content was necessary to make
interoperability with some class of devices happen - it may be totally
orthogonal to this specification, in which case I'm happy to discus that
on a different thread :-)

---

From: Martin Thomson <[email-masked]>
Date: Thu, 18 Jul 2013 14:14:26 -0700

> have to assume it has *something* to do with BUNDLE. It's just that the

There is an initial assumption given (one stream per m-line).

With that assumption stated, a unique payload type is a way to do the
correlation thing.  That only causes problems when BUNDLE is used.
Without BUNDLE, you have a 5-tuple, which is probably adequate.

I'll have to let Adam speak to why the draft says what it says here,
he was following the discussion closer than I.

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 18 Jul 2013 15:18:30 -0700

On Thu, Jul 18, 2013 at 2:40 AM, Harald Alvestrand <[email-masked]>wrote:

> First of all, let me say that I'm very happy to see a plan that the people
> who have been voicing the strongest opinions in this debate are willing to
> stand behind.
> path, no matter what it is (as long as it's not obviously broken), than to
> continue to debate. This topic has long been needing a decision.
>
> it. The purpose of this review is to help make sure it's fully described,
> and that all parties understand it the same way.
>
> "media source" is as defined in draft-westerlund-avtcore-**multiplex-architecture-03
> section 2.1. The term is used elsewhere in the document, and seems to have
> this meaning. "One common" is a reflection of my belief that practice has
> not been uniform in this area.
>
> 3.1, Bundle-only M-lines
>
> This mechanism requires sending M-lines with port zero as part of a bundle
> in an SDP OFFER.
> (the grouping framework) by allowing such M-lines to be part of a group in
> an offer (but I do not think it needs to be allowed in an answer).
>
> 4.1 Simple example
>
> If it's intended that draft-westerlund-avtcore-rtp-**simulcast is used,

Regarding the Simulcast ssrc-group based signaling, the following draft
explains its usage:
http://tools.ietf.org/html/draft-nandakumar-mmusic-rtcweb-grouping-00.

The idea is very similar to the Unified Plan in that , ssrc-group is used
to signal the ssrcs for a given MediaStreamTrack as part of Simulcast. It
also talks about using receiver selection of the Simulcast sources offered
by the Sender via
draft-lennox-mmusic-sdp-source-selection-05<http://tools.ietf.org/html/draft-lennox-mmusic-sdp-source-selection-05>
.

> There should probably be one example where the offer contains 1 audio and
> 2 video streams, and the answer contains 1 audio and 1 video stream (fewer
> streams in response than in request); I believe that this answer would then
> contain "a=recvonly" and no "a=msid" attribute on the 3rd m-line, but it's
> nice to be sure.
>
> "a=content" attribute. If this is still expected to work, it might be
> worthy of inclusion here.
>
> ______________________________**_________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/mmusic<https://www.ietf.org/mailman/listinfo/mmusic>
>