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

Stefan Håkansson LK <stefan.lk.hakansson@ericsson.com> Wed, 03 July 2013 07:38 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 12B4111E8176 for <rtcweb@ietfa.amsl.com>; Wed, 3 Jul 2013 00:38:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.849
X-Spam-Level:
X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-1.750, BAYES_00=-2.599, J_CHICKENPOX_15=0.6, J_CHICKENPOX_18=0.6, MIME_8BIT_HEADER=0.3]
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 AEc8X87vvAig for <rtcweb@ietfa.amsl.com>; Wed, 3 Jul 2013 00:38:52 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net [193.180.251.56]) by ietfa.amsl.com (Postfix) with ESMTP id 76FC311E8174 for <rtcweb@ietf.org>; Wed, 3 Jul 2013 00:38:52 -0700 (PDT)
X-AuditID: c1b4fb38-b7f456d000002e83-e8-51d3d50bf99b
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.253.125]) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id 8B.22.11907.B05D3D15; Wed, 3 Jul 2013 09:38:51 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.6]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0328.009; Wed, 3 Jul 2013 09:38:51 +0200
From: =?iso-8859-1?Q?Stefan_H=E5kansson_LK?= <stefan.lk.hakansson@ericsson.com>
To: =?iso-8859-1?Q?Jos=E9_Luis_Mill=E1n?= <jmillan@aliax.net>
Thread-Topic: [rtcweb] Basic scenario 'impossible?' to achieve with the actual API
Thread-Index: AQHOdz3PRfxdtB3UtEOLGBOa395CpA==
Date: Wed, 3 Jul 2013 07:38:50 +0000
Message-ID: <1447FA0C20ED5147A1AA0EF02890A64B1C30A16F@ESESSMB209.ericsson.se>
References: <CABw3bnOp1jY6-ziR-PFG4-fRTT5zQ5ebQkmp5PhzeS1ew=h98g@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.148]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrALMWRmVeSWpSXmKPExsUyM+JvrS731cuBBuePaFusO2BisfZfO7sD k8e5hvfsHkuW/GQKYIrisklJzcksSy3St0vgymhZd5yp4LtAxeqFj5gbGE/zdjFyckgImEi8 /LONCcIWk7hwbz1bFyMXh5DAUUaJP7P+skM4Cxkl3t5bxQ5SxSYQKLF13wKgKg4OEQFbictH /EDCzAKaEhOW7WIDsYUFgiX+TT0NVi4iECLR9ewQC4StJ7Hqz3wwm0VAReLjhblgNbwCvhIv Ts5nBrGFBAIk3qzqBoszAh30/dQaJoj54hK3nsyHOlRAYsme88wQtqjEy8f/WCFsJYnGJU9Y Ier1JG5MncIGYWtLLFv4mhlil6DEyZlPWCYwis5CMnYWkpZZSFpmIWlZwMiyipGjOLU4KTfd yGATIzAWDm75bbGD8fJfm0OM0hwsSuK8W/TOBAoJpCeWpGanphakFsUXleakFh9iZOLglGpg 3BW+7UaxxZ6PPxqyFx+I8ZgzJTw1WcaO72sST3CD6mFtsXPi962WCtVLbNh0akqNzuLNCxbx TXz00V+9ozV8+Xo5nhd+E+Y+vRr4ueL5zxl5j2YJ3z5iUqRp8GYD3//YhPciJwrrdj1faHU0 5xS753POD0ov7u48/WnWpcvXzn6bzdGV+3LLNVMlluKMREMt5qLiRACEiw6GUwIAAA==
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: Wed, 03 Jul 2013 07:38:59 -0000

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.
>
> Alice and Bob have accessed to a Web page offering a basic WebRTC
> application   that they use to speak and see each other. They are in the
> middle of a media session right now.
>
> Alice presses the "Video" button in her web application. A SDP offer
> with video description is sent to Bob:
>
> Bob doesn't want to see her, so his web application rejects the media by
> using any valid method for that:
> -- a=inactive
> -- m=video 0

My personal view is that even if we use SDP for carrying the association 
between RTP SSRCs and the MediaStream and MediaStreamTrack structures as 
well as negotiating codecs, we should not use it to negotiate what 
streams and tracks to use. It should only be used to set up the streams 
and tracks over the networks that is decided by the application.

One way in this specific case could be that Bob's application (since Bob 
does not want to see Alice) simply does not show the video. Bob's 
application could in addition signal this to Alice's application (in 
some app proprietary way) and Alice's app could remove the video stream 
(or track) from PeerConnection to save bandwidth and processing.

Stefan

>
> Alice web application received a SDP answer which was consumed
> successfully by the RTCPeerConnection. Alice thinks she is sharing her
> video, but she is not.
>
> The application "Video" button is disabled since the video is already
> being shared (theoretically)
>
> The application "self-Video" HTML5 video element displays Alice's face.
> She thinks that Bob is seeing her face too, but he did indeed rejected so.
>
> I hope this common scenario can be achieved somehow with the current
> API. I can't find how to do it though.
>
> Thanks in advance
>
> --
> José Luis Millán