Re: [MMUSIC] Unified Plan for SDP Handling - multiple media sources

[Martin Thomson <[e-mail]>]

Hi Roni,

On 16 July 2013 14:48, Roni Even <[e-mail]> wrote:
> Hi,
> Some comments.
> In section 2 bullet 2 is changing RFC 5576 semantics and not for good. Why
> do you want more than one SSRC for m-line but allow only one at a time, is
> this for the simulcast case?

The text includes "Absent any other signaled extension, [...]" for
exactly that reason.  The plan is to include a specific extension for
simulcast, layering and FEC that would avoid this specific problem.

> Others which are not on section 2
>
> 1. The document talks about the case when there are multiple participants
> each sending multiple streams as mentioned in section 1.1.1 and the receiver
> may want to select among all these sources as discussed in section 1.1.2.
> The document focus on the point to point case and does not address the issue
> of how all the m-lines from all participants are distributes and how a late
> joiner gets all this information.

The assumption is that there is always a point-to-point leg that is
being negotiated.  That doesn't remove the need to combine information
from a multi-party session into a single description.

> 3. The simulcast example and description allows the case of sending one of
> the resolutions at a time but in simulcast the source may be able to send
> multiple resolutions at the same time. To further complicate this case the
> offer can support three resolutions but can only send any two at a time
> which the receiver can select. How do you signal this, my view is with the
> maxsendssrc attribute.

(Full disclosure, I didn't keep track of the changes in this area
effectively, my views may differ from Adam and Justin on this point.)

The combination of FID grouping and the newly defined SIMULCAST
grouping might provide enough information.  In that way, I can suggest
that I don't want to see both A and C at the same time, even though
A+B or B+C might be OK.

I'd rather not rely on maxsendssrc, which is based on a very different
set assumption on the meaning of an m-line to what this document
describes.

> 4. in section 3.2.1.1 "as well as a 16-bit identifier (expressed as an
> integer) used for correlation;" I think that it must be a byte string or
> token not integer

There have been serious concerns raised regarding size of packets,
even though the header extension is not sent on many packets.  While
it's true that a 16-bit identifier is restrictive, but you'll need to
motivate a size increase a little better than that.