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

Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Thu, 07 November 2013 18:10 UTC

Return-Path: <stefan.lk.hakansson@ericsson.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 CFFD321E818A for <rtcweb@ietfa.amsl.com>; Thu, 7 Nov 2013 10:10:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.949
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v8lB+RFFHpVX for <rtcweb@ietfa.amsl.com>; Thu, 7 Nov 2013 10:10:21 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 727C111E8216 for <rtcweb@ietf.org>; Thu, 7 Nov 2013 10:07:14 -0800 (PST)
X-AuditID: c1b4fb25-b7eff8e000000eda-28-527bd6c3e862
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 4D.4C.03802.3C6DB725; Thu, 7 Nov 2013 19:06:59 +0100 (CET)
Received: from ESESSMB209.ericsson.se ([169.254.9.201]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Thu, 7 Nov 2013 19:06:59 +0100
From: Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com>
To: Martin Thomson <martin.thomson@gmail.com>, Justin Uberti <juberti@google.com>
Thread-Topic: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers
Thread-Index: AQHO10u5+4jB5R0tEke3keLV47NJvZoUll2AgAQNEACAAAvgAIAAAhoAgAAG1YCAAAFAgIAATuSAgABAxwCAAAiFgIAAsxqAgAAEKwA=
Date: Thu, 07 Nov 2013 18:06:58 +0000
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C3D4EF0@ESESSMB209.ericsson.se>
In-Reply-To: <CABkgnnVOj+A8ZF8VYBnb5v_wgCKnD17Lcoy3=XdnM88GHuidMQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.8.130913
x-originating-ip: [153.88.183.154]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <EFBC843312FE164EAD514DCF744A3A62@ericsson.com>
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: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] draft-ietf-rtcweb-jsep-05 - Subsequent Offers
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: Thu, 07 Nov 2013 18:10:43 -0000

On 07/11/13 18:52, "Martin Thomson" <martin.thomson@gmail.com> wrote:

>On 6 November 2013 23:11, Justin Uberti <juberti@google.com> 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
>>>according
>>> to some constraint.
>>>
>>
>> X may be using A in this case, but Y may be using B, so #3 would be bad
>>IMO.
>> (Remember, the reason for the new offer is because some other property
>>of
>> the session changed.)
>>
>> #2 would be the default behavior, and #1 would be the optional behavior
>>that
>> 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
opinion.


>
>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
>rtcweb@ietf.org
>https://www.ietf.org/mailman/listinfo/rtcweb