IETF Logo Mail Archive

Re: [rtcweb] Plan A, respun

Cullen Jennings <fluffy@iii.ca> Fri, 10 May 2013 18:45 UTC

Return-Path: <fluffy@iii.ca>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF94921F9048 for <rtcweb@ietfa.amsl.com>; Fri, 10 May 2013 11:45:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level:
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599]
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 xQkGdXW2rF6g for <rtcweb@ietfa.amsl.com>; Fri, 10 May 2013 11:44:57 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 168A821F90C3 for <rtcweb@ietf.org>; Fri, 10 May 2013 11:44:44 -0700 (PDT)
Received: from [192.168.4.101] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 08CFC22E253; Fri, 10 May 2013 14:44:42 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <BLU169-W4273890266755A522DB03A93BA0@phx.gbl>
Date: Fri, 10 May 2013 10:38:19 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <C8C6F5C0-3613-493F-A75C-3300D21FAB0B@iii.ca>
References: <51894846.3090102@nostrum.com> <518955FE.9000801@alum.mit.edu>, <51895D71.3090000@nostrum.com>, <51896D91.9070004@alum.mit.edu> <BLU169-W4273890266755A522DB03A93BA0@phx.gbl>
To: Bernard Aboba <bernard_aboba@hotmail.com>
X-Mailer: Apple Mail (2.1503)
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Plan A, respun
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 May 2013 18:45:05 -0000

On May 7, 2013, at 2:44 PM, Bernard Aboba <bernard_aboba@hotmail.com> wrote:

> The "existing SDP semantics" have allowed multiplexing of RTP streams from multiple SSRCs on the 
> same RTP session without explicit declaration since multicast days -

Right, but what it has meant to do that in Offer / Answer cases has been that these are alternative encoding of same capture and not different captures. I think we need to have the signaling be explicit about the meaning if it is supposed to mean something different than that. Note, I'm not against an extension that indicates specific semantics that are different that the current O/A ones, but just it would need to be defined and signaled. The plan A seem to avoid needing to argue about this and at the same time make it easy to define theses semantics and signal them if CLUE or someone other user of RTP needs that.

v2.23.0 | Report a Bug | By Email