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

Jim Barnett <Jim.Barnett@genesyslab.com> Tue, 02 July 2013 17:20 UTC

Return-Path: <jim.barnett@genesyslab.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 96AFF21F888F for <rtcweb@ietfa.amsl.com>; Tue, 2 Jul 2013 10:20:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.149
X-Spam-Level:
X-Spam-Status: No, score=-3.149 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, J_CHICKENPOX_55=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 Hg3G7hNYF6R9 for <rtcweb@ietfa.amsl.com>; Tue, 2 Jul 2013 10:20:17 -0700 (PDT)
Received: from service107-us.mimecast.com (service107-us.mimecast.com [207.211.31.84]) by ietfa.amsl.com (Postfix) with ESMTP id 0077C21F9A2E for <rtcweb@ietf.org>; Tue, 2 Jul 2013 10:20:10 -0700 (PDT)
Received: from webmail-us.genesyslab.com (168.75.250.4 [168.75.250.4]) (Using TLS) by service107-us.mimecast.com; Tue, 02 Jul 2013 13:20:05 -0400
Received: from GENSJZMBX01.msg.int.genesyslab.com ([fe80::c80a:d985:3cca:a5e7]) by GENSJZFE02.msg.int.genesyslab.com ([::1]) with mapi id 14.02.0318.004; Tue, 2 Jul 2013 10:20:04 -0700
From: Jim Barnett <Jim.Barnett@genesyslab.com>
To: =?utf-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= <ibc@aliax.net>, Enrico Marocco <enrico.marocco@telecomitalia.it>
Thread-Topic: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API
Thread-Index: AQHOd0PwQJX9HXzqg0mu/Vpj2CjNXplRmgAg
Date: Tue, 2 Jul 2013 17:20:04 +0000
Message-ID: <57A15FAF9E58F841B2B1651FFE16D2810539DF@GENSJZMBX01.msg.int.genesyslab.com>
References: <CABw3bnOp1jY6-ziR-PFG4-fRTT5zQ5ebQkmp5PhzeS1ew=h98g@mail.gmail.com> <51D2FC3C.8090609@telecomitalia.it> <CALiegfkrbw7ouiEP726LMOkGJb3bmicU03svZ-3VMLH3Oxhtjw@mail.gmail.com>
In-Reply-To: <CALiegfkrbw7ouiEP726LMOkGJb3bmicU03svZ-3VMLH3Oxhtjw@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [108.7.220.231]
MIME-Version: 1.0
X-MC-Unique: 113070213200504801
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: base64
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 17:20:22 -0000

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

-----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>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