[MMUSIC] Review of unified-plan-00

[Harald Alvestrand <[e-mail]>]

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