Re: [Dart] multiplexing different media types

"Paul E. Jones" <paulej@packetizer.com> Sun, 15 June 2014 14:24 UTC

Return-Path: <paulej@packetizer.com>
X-Original-To: dart@ietfa.amsl.com
Delivered-To: dart@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 37E1B1B2844 for <dart@ietfa.amsl.com>; Sun, 15 Jun 2014 07:24:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.642
X-Spam-Level:
X-Spam-Status: No, score=-1.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YZ9FlKtzcIZN for <dart@ietfa.amsl.com>; Sun, 15 Jun 2014 07:24:28 -0700 (PDT)
Received: from dublin.packetizer.com (dublin.packetizer.com [75.101.130.125]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E2D481B283E for <dart@ietf.org>; Sun, 15 Jun 2014 07:24:27 -0700 (PDT)
Received: from dyn-225.arid.us (cpe-024-211-197-136.nc.res.rr.com [24.211.197.136]) (authenticated bits=0) by dublin.packetizer.com (8.14.5/8.14.5) with ESMTP id s5FEOO9d021925 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Jun 2014 10:24:25 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=packetizer.com; s=dublin; t=1402842265; bh=wbq2mTImMYMPOL36KmYPeWrcV5/FRTBIvN+R/WGFes0=; h=In-Reply-To:References:MIME-Version:Content-Type: Content-Transfer-Encoding:Subject:From:Date:To:Message-ID; b=PmyFfBxyHcecl/JQd/1g/bHbuZYqCZ0Jxg25VZx6FsP/mcmxQKrUBnao4erJlgFw6 eWA1KFAGuY0ZrJOolI/xi2qcgxlHYJa+S2Fy4jOSG42QeNVxWebLjQpwYfrbdJBWyI FgnhfOQbjZYkJ+oIdo8bqs3gdS7GC4apEmAlncJA=
User-Agent: Kaiten Mail
In-Reply-To: <539D48B1.80003@alvestrand.no>
References: <emcef68d3e-8260-40c5-9b7d-c6838a595d8b@sydney> <539D48B1.80003@alvestrand.no>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----ONXJMSX59YOBS00FR0Z8TET469KGD6"
Content-Transfer-Encoding: 8bit
From: "Paul E. Jones" <paulej@packetizer.com>
Date: Sun, 15 Jun 2014 10:24:23 -0400
To: Harald Alvestrand <harald@alvestrand.no>, dart@ietf.org, Eric Rescorla <ekr@rtfm.com>
Message-ID: <7c0233f4-fe8b-4902-afd0-82d7ef6e1f36@email.android.com>
Archived-At: http://mailarchive.ietf.org/arch/msg/dart/bC8o4WnsOeoWbr-F-K2GXFTESls
Subject: Re: [Dart] multiplexing different media types
X-BeenThere: dart@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "\"DiffServ Applied to RTP Transports discussion list\"" <dart.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dart>, <mailto:dart-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dart/>
List-Post: <mailto:dart@ietf.org>
List-Help: <mailto:dart-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dart>, <mailto:dart-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 15 Jun 2014 14:24:29 -0000

Harald,

Thanks for the clarification. If you'll indulge, allow me to ask one more basic question...

In draft-ietf-avtcore-multiplex-guidelines, it goes to great length to explain that multiplexing is on the SSRC. It also says no two media sources shall use the same PT value. Thus, a payload type could be used when demultiplexing, though the text says otherwise. Perhaps this language exists to support multipoint?  Thus, a receiver first looks at the SSRC to identify the source, then the PT to determine what the packet contains? Is SSRC demuxing there only for multipoint?

Why not allow the PT number space to be distinct per SSRC?

Paul


-------- Original Message --------
From: Harald Alvestrand <harald@alvestrand.no>
Sent: June 15, 2014 3:18:09 AM EDT
To: "Paul E. Jones" <paulej@packetizer.com>, dart@ietf.org, Eric Rescorla <ekr@rtfm.com>
Subject: Re: multiplexing different media types

(Adding EKR to thread to get a definitive DTLS answer)

On 06/15/2014 06:52 AM, Paul E. Jones wrote:
> Harald,
>
>
>> "SCTP ... can be multiplexed with one or more RTP sessions". Actually
>> we can only multiplex SCTP with a single RTP session. There have been
>> proposals that would allow multiplexing of multiple RTP sessions
>> (each containing multiple media flows) over a single 5-tuple, but
>> these were not accepted.
>
> Your draft (draft-ietf-rtcweb-transports) says:
>
>     RTCWEB implementations MUST support multiplexing of DTLS and RTP over
>     the same port pair, as described in the DTLS_SRTP specification
>     [RFC5764], section 5.1.2. All application layer protocol payloads
>     over this DTLS connection are SCTP packets.
>
> I had a question about this as we discussed the DART draft.  I assumed
> the only DTLS connection would be one used for key negotiation for
> SRTP.  Is that not the case? Would there be multiple DTLS connections
> multiplexed?  If so, how would one be differentiated from another?

EKR is the expert here.

As I understand it, the key material for DTLS-SRTP is derived from the
session keys from the DTLS session. This does not in any way affect the
usage of the same DTLS session for passing DTLS data.

>
> As for RTP Session multiplexing, it's interesting to hear that
> proposals are dead.  Is there a proposal for multiplexing different
> media types (e.g., audio and video) within the same RTP Session,
> then?  RFC 3550 discourages that, but it was my understanding that
> browser makers wanted to multiplex the different media types somehow. 
> What's the plan?

draft-ietf-avtcore-multiplex-guidelines covers the RTP aspects.
draft-ietf-mmusic-sdp-bundle-negotiation has the details on SDP.

The only thing in RTP itself that prevents such multiplexing is the
words in RFC 3550; technically there is no barrier at the RTP level.

At the SDP level things are a bit more complex, which is why -bundle-
isn't an RFC yet.

>
> Paul
>


-- 
Surveillance is pervasive. Go Dark.