Re: [MMUSIC] ISSUE1: SDP Attributes Multiplexing - Payload Type Analysis

[Harald Alvestrand <[e-mail]>]

On 07/01/2014 05:07 PM, Jonathan Lennox wrote:
>
> On Jun 30, 2014, at 7:26 AM, Harald Alvestrand <[e-mail] 
> <mailto:[e-mail]>> wrote:
>
>> I agree with Bo's analysis concluding that IDENTICAL-PER-SSRC is 
>> likely not needed, and that situations where one has one SSRC in 
>> multiple media descriptions are probably a Bad Thing (I can't think 
>> of a case where it would represent anything but a bug).
>
> The use case for it, I think, would be a scenario where a single RTP 
> packet stream can satisfy the intended semantics of more than one 
> media description.
>
> My usual example is when I am in a conference, viewing both the 
> current loudest speaker and also a specific person (say, my boss, or 
> the customer).  I send two separate media descriptions requesting both 
> those items.
>
> During those times when that specific person is the loudest speaker, 
> the server can save bandwidth by sending the single RTP packet stream 
> carrying that person’s video only once.  It sends the same SSRC in 
> both media descriptions to indicate that that packet stream is 
> intended to be consumed by both of them.
>
> Now, maybe we don’t want to support this use case, or maybe we want to 
> support it in some way other than SDP-based signaling (as being too 
> heavyweight for moving SSRCs around on the timescale of 
> loudest-speaker timescale switching).  But we should make that 
> decision explicitly.

If we want to support that scenario, we also need to make the app-id 
token used for association between an RTP packet and an m-line 
multivalued. It seems to me that we've so far just assumed that it's 
single-valued.

I can see the logic in wanting to support such a scenario, but I am 
afraid of finding that there are more places than I can think of where 
we've implicitly made the opposite assumption (app-id was only the first 
one I could think of).