Re: [rtcweb] DRAFT Agenda for RTCWEB

[[e-mail] (Dale R. Worley)]

> From: "Dan Wing" <[e-mail]>
> 
> The analysis should also examine impact of port-based QoS on 
> multiplexing data over the same port as audio.  Even audio and
> video often prefer different drop precedence.  I know the general
> consensus is to just supply more bandwidth, yet we consume all 
> available bandwidth much like disk space, memory, and CPU/GPU 
> cycles.

As Harald mentioned, since you can have more than one bundle in a
single session description, you can prescribe one bundle for the audio
and one for the video, and give different QoS parameters for each
bundle.

> From: Michael Tuexen <[e-mail]>
> 
> Sorry, I don't understand what you are saying. Which document
> describes the stack you are referring to? How would encryption be
> done for SCTP over UDP over IP?

http://tools.ietf.org/html/draft-worley-sdp-bundle-04, section 8, as I
provided in the original message.

You get two variants of the problem, one where you multiplex all the
streams, and then apply DTLS, the other where you encrypt each stream
separately (SRTP, SRTCP, SCTP-over-DTLS) and then multiplex them.  The
analysis of how to demultiplex differs slightly in the two cases.

> From: Salvatore Loreto <[e-mail]>
> 
> Dale: can you clarify which scenario you have in mind when you say:
> "Controlling port numbers is needed if SCTP is *not* encapsulated in 
> DTLS and yet has to be distinguished from RTP et al."
> is it a WebRTC usage or a usage for a different aim (maybe CLUE?)

Actually, I'm analyzing the situation in abstract.  Since it turns out
to be straightforward to demultiplex in the general case, the solution
isn't limited to specific scenarios.

> From: Bernard Aboba <[e-mail]>
> 
> Why would we want unsecured SCTP either for the WebRTC data channel or
> CLUE signaling? Let's not invent problems when we have enough real
> ones.

The question would arise if one multiplexed the various streams
*before* encrypting them, then the demultiplexing problem is slightly
different.

In this case, we can straightforwardly solve a general problem, which
includes the current real problems, and possibly other real problems
we don't yet know that we'll have.

Dale