Re: [rtcweb] DRAFT Agenda for RTCWEB (Dale R. Worley) Mon, 04 March 2013 20:22 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9FB1A21F8FAC for <>; Mon, 4 Mar 2013 12:22:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.958
X-Spam-Status: No, score=-2.958 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6JzcVFoHPZQF for <>; Mon, 4 Mar 2013 12:22:02 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E7FA221F8FB3 for <>; Mon, 4 Mar 2013 12:22:01 -0800 (PST)
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id r24KLpXg029036 for <>; Mon, 4 Mar 2013 15:21:53 -0500
Received: from ( []) by (8.13.6/8.12.8) with ESMTP id r24KLpst3082914 for <>; Mon, 4 Mar 2013 15:21:51 -0500 (EST)
Received: (from worley@localhost) by (8.13.6/8.13.6/Submit) id r24KLpWl3070758; Mon, 4 Mar 2013 15:21:51 -0500 (EST)
Date: Mon, 04 Mar 2013 15:21:51 -0500
Message-Id: <>
In-reply-to: <112a01ce16ae$a1720d90$e45628b0$> (
References: <> <> <> <> <112a01ce16ae$a1720d90$e45628b0$>
Subject: Re: [rtcweb] DRAFT Agenda for RTCWEB
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 04 Mar 2013 20:22:02 -0000

> From: "Dan Wing" <>
> 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

> From: Michael Tuexen <>
> 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?, 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 <>
> 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 <>
> 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

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.