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

[Martin Thomson <[e-mail]>]

On 18 July 2013 02:40, Harald Alvestrand <[e-mail]> wrote:
>    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.

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.

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

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.

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

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
:)

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

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.