Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting)

Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com> Fri, 19 October 2012 06:37 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 9061A21F85B0 for <rtcweb@ietfa.amsl.com>; Thu, 18 Oct 2012 23:37:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hkauBCfsvAbL for <rtcweb@ietfa.amsl.com>; Thu, 18 Oct 2012 23:37:01 -0700 (PDT)
Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 9BF4021F85B4 for <rtcweb@ietf.org>; Thu, 18 Oct 2012 23:36:59 -0700 (PDT)
X-AuditID: c1b4fb30-b7f7d6d0000042ea-45-5080f50ab520
Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A4.3E.17130.A05F0805; Fri, 19 Oct 2012 08:36:58 +0200 (CEST)
Received: from [150.132.142.225] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Fri, 19 Oct 2012 08:36:58 +0200
Message-ID: <5080F509.5020102@ericsson.com>
Date: Fri, 19 Oct 2012 08:36:57 +0200
From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:16.0) Gecko/20121011 Thunderbird/16.0.1
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <201210182110.q9ILAq4K4836140@shell01.TheWorld.com> <5080F1E9.2050509@alvestrand.no>
In-Reply-To: <5080F1E9.2050509@alvestrand.no>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNJMWRmVeSWpSXmKPExsUyM+JvrS7X14YAg92dJhZr/7WzOzB6LFny kymAMYrLJiU1J7MstUjfLoEro2P2duaCeZwV+7/1MDYwrmbvYuTkkBAwkXj78jsbhC0mceHe eiCbi0NI4BSjxIL+l+wQzlpGiftXG5lBqngFtCXeP3zHBGKzCKhK7H62nQXEZhOwkVjbPQUs LioQJrF852YmiHpBiZMzn4DViAgIS2x91QsWFwaqmXJyOpgtJJAgMaHnPdhFnAK6Em9Xzwar Zxawlbgw5zqULS+x/e0cZoh6XYl3r++xTmAUmIVkxSwkLbOQtCxgZF7FKJybmJmTXm6ul1qU mVxcnJ+nV5y6iREYgAe3/DbYwbjpvtghRmkOFiVxXj3V/f5CAumJJanZqakFqUXxRaU5qcWH GJk4OKUaGAU2Hy+PX8N8VjUpzG0xa9biQ3mP0oxMHbVfOyqav7zjmbY06Jpmc8LJt1sWfZ79 7133od4ll2OeqhheStUID1vceoOx4CTbxOOF685uTD7peK4xR99trXug8veN9xRzN22R3ZLP s2Zu/xcRbsG8A8+ZLE54ya081qfYGlvz4nr11szob5L9BkosxRmJhlrMRcWJAP6waXYOAgAA
Subject: Re: [rtcweb] Relaxing SDP O/A (was RE: Agenda requests for Atlanta meeting)
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, 19 Oct 2012 06:37:01 -0000

On 10/19/2012 08:23 AM, Harald Alvestrand wrote:
> On 10/18/2012 11:10 PM, Dale R. Worley wrote:
>>> From: Harald Alvestrand <harald@alvestrand.no>
>>>
>>> But the API never forces the application to send an offer; sending or
>>> not sending an offer is strictly the application's responsibility.
>> Is the API able to report that the far end has rejected the offer?
> The concept of "the far end" (application far end, not RTP far end) and
> "reject" are application-level concepts, not API-level concepts.
> So in the context of the API, I can't parse the question.
>
> The API can report that it was handed an SDP blob it couldn't use.

One discussion I think we've not had yet is the granularity the API 
could report "can't use this SDP blob" on. Say that a new offer (in on 
ongoing sessions) was received indicating the addition of two audio and 
two video tracks (from Alice to Bob). What if Bob's browser could decode 
both audio tracks but has resources to handle only one of the video 
tracks, should it be able to tell so (perhaps with the result that two 
audio and one video track was added)? Or should the update of the 
session just fail?