Re: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API

Enrico Marocco <> Tue, 02 July 2013 20:12 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 93ACB21F9B21 for <>; Tue, 2 Jul 2013 13:12:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.419
X-Spam-Status: No, score=-101.419 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id J68P9cW7ilqL for <>; Tue, 2 Jul 2013 13:11:59 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A486321F9993 for <>; Tue, 2 Jul 2013 13:11:58 -0700 (PDT)
Received: from grfhub701rm001.griffon.local ( by ( with Microsoft SMTP Server (TLS) id; Tue, 2 Jul 2013 22:11:54 +0200
Received: from MacLab.local ( by ( with Microsoft SMTP Server (TLS) id; Tue, 2 Jul 2013 22:11:54 +0200
Message-ID: <>
Date: Tue, 2 Jul 2013 22:11:53 +0200
From: Enrico Marocco <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Martin Thomson <>
References: <> <> <>
In-Reply-To: <>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020508030209060907070106"
X-TI-Disclaimer: Disclaimer1
Cc: "" <>
Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API
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: Tue, 02 Jul 2013 20:12:09 -0000

On 7/2/13 8:05 PM, Martin Thomson wrote:
> There are two separate problems here:
> 1. How do I reject a proposed stream?
> 2. How do I learn that my proposed stream was rejected?
> I'm sure that there are controls for this already...  Maybe.  You
> could, as Enrico suggests, add streams one-by-one using multiple
> offer/answer rounds - then you would be able to isolate what was
> rejected. That doesn't really scale.

Come on, Martin, what Enrico suggested was one of a probably unlimited
number of possible approaches for one very specific supposedly
unaddressable use case. It was put together and sent within 9' since the
initial email hit the list -- don't build your case on it!

FWIW I agree that, in more complex scenarios where streams are
frequently added and/or removed, requiring a single O/A for each
operation is going to be a problem. My preference -- a reasonable
tradeoff at this point in time -- would be to limit SDP O/A to
negotiation of ICE params, crypto material and payload types, and do
stream manipulation in an app-specific way. The latter is no-plan, that
incidentally carries my name on it. The former looks pretty much like
plan A.