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

[Harald Alvestrand <[e-mail]>]

On 07/18/2013 07:06 PM, Martin Thomson wrote:
> 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.

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.

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

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

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

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