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

Emil Ivov <> Fri, 31 May 2013 18:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1EED721F9050 for <>; Fri, 31 May 2013 11:27:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.294
X-Spam-Status: No, score=-1.294 tagged_above=-999 required=5 tests=[AWL=-1.154, BAYES_20=-0.74, J_CHICKENPOX_15=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GrS+-6KNtC+4 for <>; Fri, 31 May 2013 11:27:18 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4008:c01::22b]) by (Postfix) with ESMTP id A9E3421F8FCB for <>; Fri, 31 May 2013 11:27:17 -0700 (PDT)
Received: by with SMTP id jm2so917482bkc.2 for <>; Fri, 31 May 2013 11:27:16 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding:x-gm-message-state; bh=QVCeerntQ/RfFrsKOA6qSbPP16zsKzFIuHNnlPgfvuM=; b=HNgzAzYrlpEJHIzdlsJCgPx7vGWnHP54H2Rc0U1m99qsGnFwQ7IkyZarHQ2r7S0K09 rBppAxqrOrJycrTfwUzCMhBzif38MP0Y0KdD4hVFZe8TbIKKyGVH+WA0ncpmkJISlxPI BOlu8yg7gnkzZq/lPzYgSGT8YY2Zj0PieMmvF0lFfsDd4EJ5qHNwUyRFKPNoOEtaJT6b lYp8BE2ntvHREN8UZpf909mJUedszkLUYC/0m4gJUfdROdNXpcQ5PiX9JMS109ov0JS4 yLAthRPkPgIC3bIWfaq8AiF0eF2sFWDrprtr/CdOhXG9fWcjavmf3ZguwBm5b6wQEInf hS+Q==
X-Received: by with SMTP id l8mr3656285bkz.49.1370024836605; Fri, 31 May 2013 11:27:16 -0700 (PDT)
Received: from camionet.local ([]) by with ESMTPSA id da16sm15604733bkb.2.2013. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 31 May 2013 11:27:15 -0700 (PDT)
Message-ID: <>
Date: Fri, 31 May 2013 21:27:11 +0300
From: Emil Ivov <>
Organization: Jitsi
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: Cullen Jennings <>
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Gm-Message-State: ALoCoQkpInODCrxDH2v6VdNSkk5nBGXqYKBQ0wN5MS6tCuNlbK+estQK47WJ2USHz+I/iR+KT3dh
Subject: Re: [rtcweb] No Plan - but what's the proposal
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 31 May 2013 18:27:19 -0000

Hey Cullen,

On 30.05.13, 20:07, Cullen Jennings wrote:
> 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

Yes, the above seem like an accurate summary.

> 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

Then I suppose this is a good time for us to agree here on what we need 
the API to expose so that the underlying protocols would work.

> This is very close to Plan A.

I'd say it's actually closer to Plan B but Plan-A-style signalling 
should certainly be possible to implement by the app or a signalling 

> 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 part where one doesn't have to redo (and propagate) an Offer/Answer 
exchange every time a source is added or removed.

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

This is another difference indeed.

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

There's an example in the draft. I assume the "parameters" you mention 
are not in there, so could you please be more specific?

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

It means a browser should generate and offer that looks like this:


rather than an offer that looks like this


Also if one bundle is not enough to fit all payload types in the two 
media lines, then we split them in two.

> Can you explain what you are actually proposing we do do instead of
> just saying what not to do ?

We create an offer that would describe the media types and the bundle. 
We use that offer to also describe capabilities in terms of maximum 
resolutions, supported header extensions, potentially max-ssrc-s, etc.

It is up to the application how to handle the rest. If it needs to 
transmit additional signalling: let it. If it wants to encode that in 
SDP, great. If it wants to attach it in JSON next to the browser 
generated SDP, that also works.

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

You started another thread for this, so I'll respond there.

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

I appreciate you are trying to turn this into a joke (which I think is a 
pity provide your chairing role in this working group), but abandoning 
SDP really isn't what this is about. You might have noticed text about 
this as early as the abstract:

   This document does not question the use of SDP and the Offer/Answer
   model or the value they have in terms of interoperability with legacy
   or other non-WebRTC devices.


> 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 <> 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:
>> 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
>> --
>> _______________________________________________ rtcweb mailing
>> list