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

[Adam Roach <[e-mail]>]

On 7/16/13 16:48, Roni Even 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?

No, simulcast is signaled explicitly (I will point out and emphasize the 
phrase "absent any other signaled extension"). This is "default 
behavior" is intended to accommodate MCUs that perform packet switching 
for RTP (and similar architectures that require different timing and/or 
sequence number spaces on a single stream).

> 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 intention is that these changes to the session be explicitly 
described via SDP.

> 2. In the examples using the ssrc attribute note that according to RFC 5576
> section 4.1 you must provide for each SSRC the CNAME attribute

I think we had that in some early examples, but they were later removed. 
I agree that the text in 5576 requires its presence, and see no reason 
not to add it to the examples.

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

The intention is definitely that sending multiple resolutions in 
parallel would be facilitated. Do you see any specific text prohibiting 
doing so, or is this fallout from your misunderstanding of section 2 
bullet 2?

> 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

Do you have some rationale for your assertion?

The goal here is to limit expansion of the RTP packets as much as 
possible. Given that there is a natural limit of 65536 streams in a 
single RTP session, 16 bits for a correlator seems sufficient.

/a