IETF Logo Mail Archive

Re: [rtcweb] A problem with both A and B

Martin Thomson <martin.thomson@gmail.com> Fri, 17 May 2013 20:50 UTC

Return-Path: <martin.thomson@gmail.com>
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 D7A0421F898B for <rtcweb@ietfa.amsl.com>; Fri, 17 May 2013 13:50:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.156
X-Spam-Level:
X-Spam-Status: No, score=-4.156 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-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 C0r09mcdbANM for <rtcweb@ietfa.amsl.com>; Fri, 17 May 2013 13:50:16 -0700 (PDT)
Received: from mail-lb0-f175.google.com (mail-lb0-f175.google.com [209.85.217.175]) by ietfa.amsl.com (Postfix) with ESMTP id 2F76F21F968E for <rtcweb@ietf.org>; Fri, 17 May 2013 13:50:11 -0700 (PDT)
Received: by mail-lb0-f175.google.com with SMTP id v10so4862377lbd.34 for <rtcweb@ietf.org>; Fri, 17 May 2013 13:50:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=aK4SJFi6hWHpCOsMZlqxQgfhgYXhw5rkTBbYcpg7iwo=; b=0+WuhWWH1ako3dZTxKD3PDN3eXSzQiwCdO+N88E1Iycqb70OldeNkcdQ4nqfYkI7dS UgNH8K7wNZ1n0CGJauKDmVPwt9D4EytdKjR/F78lVi1XWv2kXdV/NtYsR/Ln2Ya+jhAo 4AA1fus5zMOJBrkLzIuiGlUUGJjtQGFgZr6VGr8zgWEHudYyAvh5aDFVJDLbZnRe2Li8 LZ+aHr7uBEyPlo5B/O+iZb9WUqTyJEk9hj8Wo7ofcutIuAzYNpxyLHoq/dERc5uDBlkL z34UWRz/sW8s+Wbc0Ge6McD6aYqXunKXqpanq5PEDiKvv+UakMiHGJYMOR1ZRILXTROn 936A==
MIME-Version: 1.0
X-Received: by 10.152.26.166 with SMTP id m6mr23747330lag.50.1368823810582; Fri, 17 May 2013 13:50:10 -0700 (PDT)
Received: by 10.112.159.138 with HTTP; Fri, 17 May 2013 13:50:10 -0700 (PDT)
In-Reply-To: <BLU403-EAS40305B2D015B786CC67EB9293AC0@phx.gbl>
References: <BLU403-EAS40305B2D015B786CC67EB9293AC0@phx.gbl>
Date: Fri, 17 May 2013 13:50:10 -0700
Message-ID: <CABkgnnXX3zoeKqjFxjsfMgaGGRM0JzymaeWfA13LEjUZ4tGF9Q@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: Bernard Aboba <bernard_aboba@hotmail.com>
Content-Type: text/plain; charset="UTF-8"
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] A problem with both A and B
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, 17 May 2013 20:50:22 -0000

> "Dale R. Worley" <worley@ariadne.com> wrote:
>    DES F11  It must be possible to add and remove one way video flows
>       within the bundle without requiring an additional offer/answer
>       cycle.

I'm not sure why this speaks specifically about video...

On 17 May 2013 13:21, Bernard Aboba <bernard_aboba@hotmail.com> wrote:
> It is important. In fact, I would argue it is critical for congestion control (e.g. removal of simulcast or layered streams by the sender should not require an O/A exchange).

This is different I think.  Responding to congestion only requires
that it be possible to stop sending a given stream.  (Or maybe crank
down resolution or frame rate.)

This item talks about addition.  That's an entirely different
proposition.  As long as we assume constraints (you don't need to
re-ICE a new transport for the stream, you don't use new packet types
and codec profiles), this could be possible.  But to get WebRTC to
support this requires API changes.

v2.23.0 | Report a Bug | By Email