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

[Suhas Nandakumar <[e-mail]>]

On Thu, Jul 18, 2013 at 2:40 AM, Harald Alvestrand <[e-mail]>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.
> 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.
>
>

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>
.



>
> 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
>
>
>
>
> ______________________________**_________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/**listinfo/mmusic<https://www.ietf.org/mailman/listinfo/mmusic>
>