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

Lorenzo Miniero <lorenzo@meetecho.com> Tue, 02 July 2013 18:11 UTC

Return-Path: <lorenzo@meetecho.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 E008821F9C0D for <rtcweb@ietfa.amsl.com>; Tue, 2 Jul 2013 11:11:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.119
X-Spam-Level:
X-Spam-Status: No, score=-0.119 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_IT=0.635, HOST_EQ_IT=1.245, J_CHICKENPOX_55=0.6]
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 JwFQYdMeVBYX for <rtcweb@ietfa.amsl.com>; Tue, 2 Jul 2013 11:11:30 -0700 (PDT)
Received: from smtpdg9.aruba.it (smtpdg8.aruba.it [62.149.158.238]) by ietfa.amsl.com (Postfix) with ESMTP id 9E7C721F9C0C for <rtcweb@ietf.org>; Tue, 2 Jul 2013 11:11:29 -0700 (PDT)
Received: from rainpc ([79.10.53.156]) by smtpcmd03.ad.aruba.it with bizsmtp id vWBS1l00z3NCyFj01WBTG1; Tue, 02 Jul 2013 20:11:27 +0200
Date: Tue, 2 Jul 2013 20:11:27 +0200
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: Enrico Marocco <enrico.marocco@telecomitalia.it>
Message-ID: <20130702201127.08676aef@rainpc>
In-Reply-To: <51D2FC3C.8090609@telecomitalia.it>
References: <CABw3bnOp1jY6-ziR-PFG4-fRTT5zQ5ebQkmp5PhzeS1ew=h98g@mail.gmail.com> <51D2FC3C.8090609@telecomitalia.it>
Organization: Meetecho
X-Mailer: Claws Mail 3.9.1 (GTK+ 2.24.18; x86_64-redhat-linux-gnu)
Mime-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API
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: Tue, 02 Jul 2013 18:11:35 -0000

On Tue, 2 Jul 2013 18:13:48 +0200
Enrico Marocco <enrico.marocco@telecomitalia.it> wrote:

> On 7/2/13 6:04 PM, José Luis Millán wrote:
> > Hi,
> > 
> > Please, let me know how this normal use case could be solved with the
> > current API.
> 
> Just off the top of my head:
> 
> Audio-only call establishment:
> 
> A --{"action":"CALL","sdp":"v=0..."}-> B
> B --{"action":"ACCEPT CALL","sdp":"v=0..."}-> A
> 
> Rejected audio+video upgrade proposal:
> 
> A --{"action":"UPGRADE","sdp":"v=0..."}-> B
> B --{"action":"REJECT UPGRADE"}-> A
> 
> Alice rolls back and removes local video display.
> 
> I may be missing something, but doesn't look like rocket science to me...
> 
> Enrico
> 
> 

For the same reasons I just wrote in response to Jim's mail, I'm not sure some kind of a REJECT-UPGRADE action would be enough to address such a scenario, especially in case, for instance, part of the update attempt was accepted and the rest rejected. Considering several different aspects of a session may be subject to change, such a mechanism should be aware of that.

Lorenzo

-- 
Lorenzo Miniero, COB

Meetecho s.r.l.
Web Conferencing and Collaboration Tools
http://www.meetecho.com