Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers

Stefan Håkansson LK <> Thu, 07 November 2013 18:10 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CFFD321E818A for <>; Thu, 7 Nov 2013 10:10:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Status: No, score=-5.949 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v8lB+RFFHpVX for <>; Thu, 7 Nov 2013 10:10:21 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 727C111E8216 for <>; Thu, 7 Nov 2013 10:07:14 -0800 (PST)
X-AuditID: c1b4fb25-b7eff8e000000eda-28-527bd6c3e862
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id 4D.4C.03802.3C6DB725; Thu, 7 Nov 2013 19:06:59 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Thu, 7 Nov 2013 19:06:59 +0100
From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= <>
To: Martin Thomson <>, Justin Uberti <>
Thread-Topic: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers
Date: Thu, 7 Nov 2013 18:06:58 +0000
Message-ID: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrLLMWRmVeSWpSXmKPExsUyM+Jvje7ha9VBBovfGVpsnSpkce3MP0aL tf/a2R2YPXbOusvusWBTqceSJT+ZApijuGxSUnMyy1KL9O0SuDKuHt7CWjBPqOLBjJtsDYyn +LoYOTkkBEwkVl/ZzQRhi0lcuLeerYuRi0NI4BCjxLcnl9ghnMWMEo0P9rCDVLEJBEps3beA DcQWEQiWuHX0LjOIzSygLnFn8TmwGmEBZ4mNZ7cwQ9S4SLQcXA9VXybx4M5vFhCbRUBF4unN d4wgNq+Ar0TPnvdgcU6g+SfuNoHNYQS66PupNUwQ88Ulbj2ZD3WpgMSSPeeZIWxRiZeP/7GC 2KICehKdPx+zQMSVJBbd/gzVqydxY+oUNgjbWuLfi11QN2tLLFv4mhniBkGJkzOfsExgFJ+F ZN0sJO2zkLTPQtI+C0n7AkbWVYzsuYmZOenlRpsYgVF2cMtv1R2Md86JHGKU5mBREuf98NY5 SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANjno7/UhlBl92C1kbiKz3XvU6b+i/CYUtQRsXu t3fsKtnsbu/hMP4ruo1/W29I2lf1ZIYXzs6vNJq2XHifs67gjcaetaUF8/9XtStzVD9+kRRU 1rTEtus5V/hzJusQVYtY5nq9Izd5axaczJDWsPa1cFxn/zVrhZj+/KRHdfk215mClt1yTFdi Kc5INNRiLipOBACQNc5ygAIAAA==
Cc: "" <>
Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers
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: Thu, 07 Nov 2013 18:10:43 -0000

On 07/11/13 18:52, "Martin Thomson" <> wrote:

>On 6 November 2013 23:11, Justin Uberti <> wrote:
>>> A more complex case is:
>>>   X offers A, B, C
>>>   Y answers A, B
>>> Then X begins using A, and not using B.
>>> When doing next offer,
>>> 1) X MUST offer A, B, C
>>> 2) X MUST offer A, B
>>> 3) X MUST offer A
>>> 4..N) X MUST offer one of above by default, but may offer more
>>> to some constraint.
>> X may be using A in this case, but Y may be using B, so #3 would be bad
>> (Remember, the reason for the new offer is because some other property
>> the session changed.)
>> #2 would be the default behavior, and #1 would be the optional behavior
>> the application could choose.
>Thanks to Paul for the example, and I definitely agree with the
>requirement that the negotiated (not just in-use) parameters MUST
>remain.  That's a given.
>My suggestion is that we *don't* add a constraint, we just require the
>inclusion of everything.  If you want to constrain codec use, then you
>can use the mechanisms that we provide for doing that.  Currently,
>that's editing SDP; though we've talked about specific constraints in
>the form of { video: { disableCodec: 'VP8' } } or something like that.

At the last WebRTC teleconf we discussed what media transmission related
constraints we should have for v1, and the consensus at that meeting was
clear: codec selection was not one of them. So if you have to remove
codec(s) from the offer that would have to be done by SDP mangling. I
guess that I¹m trying to say that your suggestion is in line with
consensus at that meeting at least, and also in line with my personal

>I don't want to create a special new set of constraints that will
>effectively never get used.

I agree.

>(We do need to be careful about overconstraining implementations by
>using MUST here.  Implementations should be encouraged to offer
>everything that they can do, but circumstances might change such that
>even negotiated codecs can become unavailable.  Any MUST will need to
>be modulated.)
>rtcweb mailing list