Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 19 June 2013 19:20 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1A521F9425 for <mmusic@ietfa.amsl.com>; Wed, 19 Jun 2013 12:20:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level:
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxlTearVoLjQ for <mmusic@ietfa.amsl.com>; Wed, 19 Jun 2013 12:20:44 -0700 (PDT)
Received: from qmta05.emeryville.ca.mail.comcast.net (qmta05.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:48]) by ietfa.amsl.com (Postfix) with ESMTP id 043BF21E8053 for <mmusic@ietf.org>; Wed, 19 Jun 2013 12:20:43 -0700 (PDT)
Received: from omta24.emeryville.ca.mail.comcast.net ([76.96.30.92]) by qmta05.emeryville.ca.mail.comcast.net with comcast id qJ831l0011zF43QA5KLj79; Wed, 19 Jun 2013 19:20:43 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([63.226.120.12]) by omta24.emeryville.ca.mail.comcast.net with comcast id qKJa1l00d0G8kgX8kKJcx3; Wed, 19 Jun 2013 19:18:41 +0000
Message-ID: <51C2040A.3010104@alum.mit.edu>
Date: Wed, 19 Jun 2013 15:18:34 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: mmusic@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1C3AFDB7@ESESSMB209.ericsson.se>, <51C1A4A3.6070105@alvestrand.no>, <7594FB04B1934943A5C02806D1A2204B1C3AFEA1@ESESSMB209.ericsson.se>, <51C1A89A.9020603@alvestrand.no> <BLU169-W56DEA51EC84C8180A7DCD5938D0@phx.gbl>
In-Reply-To: <BLU169-W56DEA51EC84C8180A7DCD5938D0@phx.gbl>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1371669643; bh=D+GfGMHUHjE07ySB9ZJsv+VjZo48cI9Rl7z+G0nCz8M=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=WIWYlOk7OKFHpqFeJQXUXCawtC8MYoFVibxNsv+LJ3uR7oOk7fisuQdMG9iZN79Hj Ykyrz/crKUvqOur86p1BUvEcD9qZ66tyQ+aeDgy3raPb4uq/ggCUauRIk0Vd9b3IJx SNqwMQP9FVrdrqMeFx+H/AdocW74Ozq1Om9GMMixiS8hJswEVCVwHrNSwtjsX50NT3 /7N3VENPyiu9k0EgYtMVOzoT9dPpB8rH2F3WhSldGDZogwbmTXCjZxwA6h/vmYneEi kiy3QZROcq7aO7qdI3702H/40dRhOmi5fnt/mzmGleDeYKcyQxdikRfPjGnnxLjOX2 KQLdhZcPTzNxQ==
Subject: Re: [MMUSIC] BUNDLE TEXT: De-mux procedures (June 19th)
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jun 2013 19:20:50 -0000

On 6/19/13 9:37 AM, Bernard Aboba wrote:
> Harald said:
>
>  > Absolutely, I'm saying that BUNDLE should not specify a procedure for
>  > de-muxing. Instead, it should point to the specs that already specify
> how the
>  > de-muxing is done.
>
> [BA] RTP/RTCP multiplexing is covered in RFC 5761, and de-multiplexing
> of RTP and DTLS is covered in RFC 5764, so there is no need for BUNDLE
> to create new text on those aspects.

I'm replying here, rather than to Harald because both of you say more or 
less the same thing and its more concise here.

IIUC, RFC 5764 says how to demux DTLS from DTLS/SRTP, but not how to 
demux DTLS from other RTP. I think it turns out that the same mechanism 
works for both, but that is by accident rather than specification.

I don't know if/when someone would want to use vanilla RTP with DTLS, 
but somebody will probably find a reason. (Not RTCWEB.) It will take 
more than a reference to 5764 to cover it.

Also, 5764 only covers a single m-line using DTLS payload packets. That 
also needs to be addressed explicitly.

> However, there is still the open
> question of whether payload type can be required to be unique on all
> bundled m lines.  If so, then PT demultiplexing is viable; if not, then
> a combination of PT and SSRC de-muliplexing will be needed.

I agree.

	Thanks,
	Paul