Re: [rtcweb] Plan A, respun

[Cullen Jennings <[e-mail]>]

On May 8, 2013, at 12:37 PM, Dale R. Worley <[e-mail]> wrote:

>> From: Adam Roach <[e-mail]>
>> 
>> I want to re-iterate the most important part of my answer to Paul, since 
>> it allows anyone who can apply apply critical thinking skills to arrive 
>> at the correct conclusion about what we are proposing. Here is the crux 
>> of my answer again, from which the remainder of my answer was derived:
>> 
>>   Looking at basic principles, the intention here is that the
>>   semantics would be identical to non-webrtc, non-bundle clients
>>   receiving multiple SSRCs on the same port.
> 
> Echoing Jonathan, I don't think that there is a consistent rule for
> those semantics now.  Some devices consider multiple SSRCs to be data
> from multiple captures, and others consider multiple SSRCs to be
> alternative representations of the same capture (either simultaneous
> in time or alternating in time).

> 
> Or perhaps there is a consistent rule, but there are inconsistent
> implementations.  In which case we should document the correct
> behavior -- and worry about interoperability.
> 
> Or perhaps we should define an SDP extension (or tighten the semantics
> of an existing syntax) to remove the ambiguities.

I realize that opinions differ on this topic, but for the O/A SDP cases (not the declarative SDP in RTSP), the meaning seemed to be clear and long ago it was put in some RFC, lots of products where build. Later it was suggested it could mean something different.  

But let's get to the high level point, regardless of what people think the existing RFCs say, it is a confusing topic and it needs to have  clear signaling with clear semantics or there will be interop problems.  I think that devices that want to multiple SRC on same m-line to represent different captures need to define new SDP signaling that clearly indicates this is the case.