Re: [rtcweb] How to multiplex between peers

[Bernard Aboba <[e-mail]>]

> Timing is a real problem. If we want to do multiplexing in RTCWEB 1.0 we
> need to pick what is ready and available. We can't go around proposing
> new things that are complicated. Changing the SSRC field semantics in
> RTP/RTCP is a complicated thing.

[BA] We need to ask ourselves "Does this really need to be in the critical path for RTCWEB 1.0"?  
As I understand it, this would be a negotiated feature, and presumably all implementations
would be required to support RTP/RTCP as defined in RFC 3550 and suitable profiles. 
So from my perspective, I'd prefer to see this handled as an extension on its own path, not a 
mandatory-to-implement feature in 1.0.   


> Isn't that gateway going to be present anyway in most case. I think the
> ICE connectivity checks are one thing that will force a gateway in many
> cases. In the cases it isn't needed, then you can skip the multiplexing
> in that case to reach the legacy.

[BA] Just because we're likely to require a gateway doesn't mean we should
heap more and more things on the camel's back.  We're already talking about
ICE, shims, transcoding, changes to RFC 3550....  that's a lot of functionality
for the "gateway".  So I agree with Jonathan about the disadvantages of a shim
(or DCCP for that matter). 


> The big difference is that we either have a well reviewed and by the
> community and IESG approved specification in DCCP. Or we create
> something our selves that needs to go through all that review and will
> be even less tested than DCCP is.

[BA] Deployment counts, too.  How widely deployed is DCCP for realtime uses?