Re: [MMUSIC] Semantics of an "m=" line

[Paul Kyzivat <[e-mail]>]

Emil,

This is a useful draft. It makes some good point. I have some 
comments/questions:

Section 1:

    o  the addition or removal of simulcast or layered streams must be
       possible without the need for Offer/Answer exchanges beyond the
       initial declaration of such capabilities for either direction.

ISTM that simulcast needs more discussion - it is nuanced. E.g. the 
following are all things one might like to say about simulcast:
- I am sending the same thing in multiple formats. You can pick
   the one(s) you want to receive. (Especially for broadcast/multicast)

- I am preparted to send the same thing in multiple formats.
   You can pick the one(s) you want me to send.

- I want to receive a single source in multiple formats.

Certainly there is need for the simulcast indication in SDP for the 
multicast case. And probably in some of the others. But I am not 
convinced it is always necessary for simulcast to be indicated in SDP. 
In some cases, there may be no need for the receiver to know that two 
streams it is receiving happen to be simulcasts on one another. And in 
other cases it will already know by some means. (Which is your point.)

Also Section 1:

    o  application specific signalling should be used to cover most
       semantics following call establishment, such as adding, removing
       or identifying SSRCs;

I think this is the controversial point. In *some* cases, where the 
semantics are complex and dynamic, this makes sense. But there are no 
doubt many cases that are relatively simple, where its much more 
convenient to do something in SDP than it is to define a new application 
channel to negotiate this.

Section 4: Demuxing and Identifying Streams

The demux based solely on PT is fine if bundling is only used to combine 
m-lines with different media types. In that case there will be at most 
one bundled m-line per top level mime type. And this satisfies my 
requirement that it always be possible to map a packet to an m-line.

But if bundling is used for any other reason, then the number of likely 
m-lines goes up, and the acceptability of unique PTs goes down. Then the 
discussion changes.

I don't think the description of what must be done is quite right. You 
don't quite say what a depacketizing/decoding/processing chain *is*. Do 
you intend this as a *type* of chain, or an *instance* of a chain? I 
think it has to be *instance*. E.g. there may be two VP8 chains, with 
all the same settings, but processing different flows. Simplistically, 
you might say that the *type* of chain can be determined by the PT, and 
the *instance* of that chain can be determined by the SSRC.

But typically such chains would be assigned based on where they are 
intended to be rendered. (Equal number of chains and renderers.) So when 
a new SSRC is received, and there is no matching chain, then either it 
must be dropped, or else some existing chain must be reconfigured to 
process this SSRC. This may need to happen without any additional out of 
band info to help. How do you imagine this being done? (In simple cases 
this might be done by *policy*. But I don't know if that is enough.) Is 
it your position that if this can't be done by policy then there must be 
some application-specific signaling mechanism to do it?

	Thanks,
	Paul

On 7/15/13 2:44 PM, Emil Ivov wrote:
> Hey all,
>
> Just submitted a new draft that should server as a basis for discussion
> on "m=" line semantics in offer answer:
>
> http://tools.ietf.org/html/draft-ivov-mmusic-multiple-sources-00
>
> The goal of the draft is to discuss the use of "m=" lines by
> Offer/Answer according to their original design in SDP: as envelopes for
> RTP sessions with any number of SSRCs.
>
> In many ways, this new document describes the basis of "No Plan" but in
> a generic way, not related to WebRTC.
>
> Feedback is welcome and hopefully we will be able to also discuss this
> in Berlin.
>
> Cheers,
> Emil