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

Lorenzo Miniero <lorenzo@meetecho.com> Tue, 02 July 2013 18:08 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 2919421F9BD5 for <rtcweb@ietfa.amsl.com>; Tue, 2 Jul 2013 11:08:02 -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 Ly2qVfTVuh4J for <rtcweb@ietfa.amsl.com>; Tue, 2 Jul 2013 11:07:57 -0700 (PDT)
Received: from smtpdg7.aruba.it (smtpdg3.aruba.it [62.149.158.233]) by ietfa.amsl.com (Postfix) with ESMTP id 6756521F9BF8 for <rtcweb@ietf.org>; Tue, 2 Jul 2013 11:07:57 -0700 (PDT)
Received: from rainpc ([79.10.53.156]) by smtpcmd03.ad.aruba.it with bizsmtp id vW7q1l00K3NCyFj01W7qnZ; Tue, 02 Jul 2013 20:07:54 +0200
Date: Tue, 02 Jul 2013 20:07:50 +0200
From: Lorenzo Miniero <lorenzo@meetecho.com>
To: Jim Barnett <Jim.Barnett@genesyslab.com>
Message-ID: <20130702200750.73d1e5b9@rainpc>
In-Reply-To: <57A15FAF9E58F841B2B1651FFE16D2810539DF@GENSJZMBX01.msg.int.genesyslab.com>
References: <CABw3bnOp1jY6-ziR-PFG4-fRTT5zQ5ebQkmp5PhzeS1ew=h98g@mail.gmail.com> <51D2FC3C.8090609@telecomitalia.it> <CALiegfkrbw7ouiEP726LMOkGJb3bmicU03svZ-3VMLH3Oxhtjw@mail.gmail.com> <57A15FAF9E58F841B2B1651FFE16D2810539DF@GENSJZMBX01.msg.int.genesyslab.com>
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" <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:08:02 -0000

On Tue, 2 Jul 2013 17:20:04 +0000
Jim Barnett <Jim.Barnett@genesyslab.com> wrote:

> When the JS calls setRemote with the response (which rejects the video), the UA will know that the video has been rejected.  Is the idea that the UA will let the user know via the chrome?  Do we think it is the JS applications job to notify the user of success/failure, or the UA's?  I don't recall a discussion of this.
> 
> - Jim
> 


I think that success/failure in such a case would be a quite complex thing to notify, mostly because you'd first have to define/understand what you're trying to change: are you just trying to add video? are you changing the port? are you muting one direction? what if something was accepted, and something else not? etc. etc.

Anyway, I agree with you that the UA knows about that. In the case of Alice trying to add video and Bob rejecting it, there may be no callback as of now, but the JS application should already have a way to know the video has been rejected nevertheless. It might just look at the updated MediaStream instance: if nothing changed, video was rejected (unless in case Bob is only receiving video and not sending it, e.g., because it has no webcam, there would be no video track as well?). Not saying it's not ugly, or that a callback isn't needed, but it may work.

Lorenzo


> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Iñaki Baz Castillo
> Sent: Tuesday, July 02, 2013 12:48 PM
> To: Enrico Marocco
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API
> 
> 2013/7/2 Enrico Marocco <enrico.marocco@telecomitalia.it>:
> > 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
> 
> 
> SDP itself is a media negotiation protocol so SDP (and its WebRTC
> "API") should provide a way to determine whether the remote has accepted or not our new stream/track. But how? Current API lacks any kind of event for the case in which the remote replies a SDP rejecting our new local strem/track.
> 
> --
> Iñaki Baz Castillo
> <ibc@aliax.net>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb


-- 
Lorenzo Miniero, COB

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