Re: [rtcweb] We are moving beyond the assumptions on which O/A is based

"Roni Even" <ron.even.tlv@gmail.com> Mon, 13 May 2013 09:56 UTC

Return-Path: <ron.even.tlv@gmail.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 7475C21F93E9 for <rtcweb@ietfa.amsl.com>; Mon, 13 May 2013 02:56:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.21
X-Spam-Level:
X-Spam-Status: No, score=-1.21 tagged_above=-999 required=5 tests=[AWL=1.389, BAYES_00=-2.599]
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 k-eHSTp3t0gV for <rtcweb@ietfa.amsl.com>; Mon, 13 May 2013 02:56:05 -0700 (PDT)
Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id CF05321F9413 for <rtcweb@ietf.org>; Mon, 13 May 2013 02:56:03 -0700 (PDT)
Received: by mail-wi0-f177.google.com with SMTP id hr14so2729580wib.4 for <rtcweb@ietf.org>; Mon, 13 May 2013 02:56:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=SZfMAWQYlp4+t3/XXg8nGfPbxaf494B1WrGqJgv3auU=; b=PIxhmZfYKDL5QBsboqWCYUwMjYR7/iLjguEYn/SO551qEsrfaxoO0M928Em4pVYLvW 1YaJdKH6VxXKxAHrqsEe8T0oIeJTYCf/9DOuU6xWPtFxQKbuH2Rn7yaw9JaPFOaEvrZ3 SVxQSc6QIRp5aCVzZZDP3iaVDtgEjWHcEh9pjv3AHuIjPlp4TlML7o5LPtSgcqZIaPrc E4l1rrGRy6ELXxvE/galASmTv3pw6OLlW04+l/ofW2hDmXujELpqxigpooPuv7JeSHM3 1k5Tb4JCkbHIGNT90fGen2YdMcTyEiOzBuuMLZAJoebabER2hNBRWobtkCCx8tnpEVJ5 A4ew==
X-Received: by 10.180.212.3 with SMTP id ng3mr17572770wic.22.1368438962420; Mon, 13 May 2013 02:56:02 -0700 (PDT)
Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPSA id ay7sm6907301wib.9.2013.05.13.02.56.00 for <multiple recipients> (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 13 May 2013 02:56:01 -0700 (PDT)
From: Roni Even <ron.even.tlv@gmail.com>
To: 'Emil Ivov' <emcho@jitsi.org>, 'Paul Kyzivat' <pkyzivat@alum.mit.edu>
References: <20130503054601.4639.64651.idtracker@ietfa.amsl.com> <CALe60zAi_Lx3QFCbBQ5aPNkgorJAff0E79jkpbQX1Qt3wf2bzg@mail.gmail.com> <CAOJ7v-1Wk6u7XiYrNVmoqr5Jisu2WRvZpte7hQTOiP8YHUc6hg@mail.gmail.com> <518A1268.8090107@ericsson.com> <01AB1BF5-7ABF-4DD3-A831-3A6C96EA680C@iii.ca> <1447FA0C20ED5147A1AA0EF02890A64B1C2C818F@ESESSMB209.ericsson.se> <518E7700.1080906@alum.mit.edu> <518F67E1.3040205@jitsi.org>
In-Reply-To: <518F67E1.3040205@jitsi.org>
Date: Mon, 13 May 2013 12:55:06 +0300
Message-ID: <009f01ce4fbf$f4763b20$dd62b160$@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQIfv5wx4y9wP/O/FJv66Nx2OU8XsQM3rT1TAYHWzfgBrq/rAwLQUjLpAZ3w/YMBwZXOPQEVf9lIl/KRWhA=
Content-Language: en-us
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] We are moving beyond the assumptions on which O/A is based
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: Mon, 13 May 2013 09:56:06 -0000

Hi,
I do not think that CLUE is much different from RTCweb. Like Bernard said
the major usage of the CLUE channel is the support for the spatial
information.
CLUE is not replacing SDP o/a.  In CLUE there is still a need to have an SDP
that describe multiple RTP streams from the same media type multiplexed in a
single RTP session. There is also a need to map these streams to a media
capture in CLUE. The CLUE specific requirements stem from the need to
support different RTP topologies
(http://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update-00) . 
I am aware that there was no conclusion in the Stockholm interim meeting
about the need to support the different topologies for WebRTC

Roni Even

-----Original Message-----
From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of
Emil Ivov
Sent: 12 May, 2013 12:59 PM
To: Paul Kyzivat
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] We are moving beyond the assumptions on which O/A is
based



On 11.05.13, 19:51, Paul Kyzivat wrote:
> I don't have a specific action to recommend here. This just seems like 
> a somewhat fundamental shift that out to be recognized. It probably 
> isn't just RTCWEB and CLUE, it is really related to more complex 
> communication scenarios. ISTM that CLUE is addressing this by building 
> a layer on top of O/A, while RTCWEB is *battling* with O/A.

That's a nice way to put it. Interestingly the CLUE approach to take this
out of O/A seems to be more in line with the RTCWEB paradigm than both Plan
A or Plan B.

The decision not to implement an official signalling RTCWEB protocol was
taken very early in this working group and there was very strong consensus
on the fact that imposing a specific signalling protocol would be
incompatible with the web in general.

Still, it seems to me that we are now trying to compensate for the  lack of
such a signalling protocol by piggybacking on top of O/A and SDP with things
such as the possibility to turn off individual SSRCs.

Why do we need these things? Aren't they better handled by the API?

Emil

--
https://jitsi.org
_______________________________________________
rtcweb mailing list
rtcweb@ietf.org
https://www.ietf.org/mailman/listinfo/rtcweb