[rtcweb] No Plan - but what's the proposal

Cullen Jennings <fluffy@iii.ca> Thu, 30 May 2013 17:07 UTC

Return-Path: <fluffy@iii.ca>
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 0AC6721F9307 for <rtcweb@ietfa.amsl.com>; Thu, 30 May 2013 10:07:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 PQDkhDR+lFvD for <rtcweb@ietfa.amsl.com>; Thu, 30 May 2013 10:07:24 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 947D221F8616 for <rtcweb@ietf.org>; Thu, 30 May 2013 10:07:23 -0700 (PDT)
Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 03E4122E1F4; Thu, 30 May 2013 13:07:16 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <51A65017.4090502@jitsi.org>
Date: Thu, 30 May 2013 11:07:15 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <C3639EB3-0F44-4893-88DA-BB9F9C96A116@iii.ca>
References: <51A65017.4090502@jitsi.org>
To: Emil Ivov <emcho@jitsi.org>
X-Mailer: Apple Mail (2.1503)
Cc: rtcweb@ietf.org
Subject: [rtcweb] No Plan - but what's the proposal
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: Thu, 30 May 2013 17:07:32 -0000

Interesting draft but it seemed to have more questions about how things would wok than answers. Let me try and ask you some specifics to help flesh out what this plan is and offer a few comments.

Of the actual recommendations in the draft that relate to the problem I would summarize that draft as 

1) demux RTP based on PT but let the application know the SSRC in case it wants to do something more 

2) the way the applications interacts with the browser for set up of the media stack is via SDP 

3) Other session control not related to the media stack is left up to the application to do how it wants

4) Things like conference control and clue control  and call control should be handled by the application

5) you have a few avenues we might pursue for making FEC, RTC, etc work 

6) you have some API requirements which, with the exception of 4 about exposing the max number of incoming streams that can be decoded, I think are pretty much agreed to be put put in W3C API already. On the topic of #4, it's a big unclear what is really needed and ongoing discussion is happening around how do indicate what can be received but thats a webrtc issue

This is very close to Plan A. So I read the whole draft and asked myself how is this different than plan A. What parts of this draft would not be abel to do if we did Plan A. The only real topic I could come up with was the port music here is PT only instead of PT + SSRC. I'l start a separate thread on that. 

But lets ask what the proposal is for the question Plan A and Plan B are trying to resolve. 

Let's say browse A wants to say it can send two streams of video and here are the parameters for the video codecs for each to the streams. What does the SDP that createOffer generates look like? I see the draft says "strongly advises against the use of multiple m= lines for a single media type. " but I don't really know what you mean by that. Can you explain what you are actually proposing we do do instead of just saying what not to do ?

The above paragraph is the most important part of my email. Please, what is the proposal for what the SDP in the offer looks like. 

The idea of exposing a low level API to the media stack and having the all proposing to do FEC, RTX, SDP processing ect has been discussed many times across the various working groups. It' jokingly refereed to as comment 22 at this point. It's not that it does not have merits, but many people myself included see it as a much longer road to get done, a lot more work, and no clear gain. One of the other issues is we are trying to make this so you don't have to be a telephone expert to use it and that lots of developers can use it. I'm not going to try and summarize the low level API augments here but if you want to discus it webrtc is the right WG. 

I'll note there are many points in the draft that I disagree with but I'd rather try and sort through what the actually proposal is here before addressing any of them.

There is one point I would like to make that is the confusion introduced by "legacy endpoint". When I talk about legacy endpoints, I am talking about endpoints that use SIP or Jingle and both past ones and future endpoints. SIP will continue to evolve  and I expect WebRTC to continue being able to negotiate new features. For example, if a SIP phone added VP9 and a browser supported VP9, I would expect to be able to use it. The legacy refers to an older protocol, SIP, and not to the age of the endpoint. We do know that things can't work with all deployed endpoints and long ago we made the decision to give up on endpoints that don't do ICE. But we do try and have a reasonable experience with old and future endpoints. 


On May 29, 2013, at 12:59 PM, Emil Ivov <emcho@jitsi.org> wrote:

> Hey all,
> 
> Based on many of the discussions that we've had here, as well as many others that we've had offlist, it seemed like a good idea to investigate a negotiation alternative that relies on SDP and Offer/Answer just a little bit less.
> 
> The following "no plan" draft attempts to present one such approach:
> 
> http://tools.ietf.org/html/draft-ivov-rtcweb-noplan
> 
> The draft relies on conventional use of SDP O/A but leaves the intricacies of multi-source scenarios to application-specific signalling, with potentially a little help from RTP.
> 
> Hopefully, proponents of Plans A and B would find that the interoperability requirements that concerned them can still be met with "no plan". Of course they would have to be addressed by application-specific signalling and/or signalling gateways.
> 
> Comments are welcome!
> 
> Cheers,
> Emil
> 
> -- 
> https://jitsi.org
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb