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

Emil Ivov <emcho@jitsi.org> Wed, 05 June 2013 15:21 UTC

Return-Path: <emil@sip-communicator.org>
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 F22BB21F9AAC for <rtcweb@ietfa.amsl.com>; Wed, 5 Jun 2013 08:21:46 -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 jCORXva5J57e for <rtcweb@ietfa.amsl.com>; Wed, 5 Jun 2013 08:21:44 -0700 (PDT)
Received: from mail-we0-x230.google.com (mail-we0-x230.google.com [IPv6:2a00:1450:400c:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 8CD7621F99F8 for <rtcweb@ietf.org>; Wed, 5 Jun 2013 08:21:43 -0700 (PDT)
Received: by mail-we0-f176.google.com with SMTP id t56so1387255wes.21 for <rtcweb@ietf.org>; Wed, 05 Jun 2013 08:21:42 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 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=3uBXNnrNZv9wRqabECK17Fnm/Z1vz4fK+tKPGw9kdog=; b=cn6glyAEMEpn6jw3yJGMCLL5h1zanBt+iSKtZo5ybTsNpAzf6FOeZqW41IgmKwb3yJ JGdsn9E4J9iDDK0VIRkLN9Dn0SghFPiH761Q9Xu1qyT9i9qDxMoKk5XBqH955owOPd6w 33iDe+VYIuNLhRkjdNdpU5laE9yDl/RtgYQbqu6bMzllzoyQXvV0Z3QsJcIz2CF3hoe3 3QrqVxvvqtQiteLMfHFIlUayTS1bV2PVn1pEepD66OmYysO0XlFgLQMGow0Sjt5uF7BM gOIB+tgMZUIm+4HiMAdqGWkqn7bE6LFhOQKacn8d+3q3x9Jzjqkr3u4FmskSJdC8Oqpa OR9A==
X-Received: by 10.180.105.231 with SMTP id gp7mr7201044wib.23.1370445702483; Wed, 05 Jun 2013 08:21:42 -0700 (PDT)
Received: from camionet.local (lec67-2-82-226-207-96.fbx.proxad.net. [82.226.207.96]) by mx.google.com with ESMTPSA id h8sm11085953wiz.9.2013.06.05.08.21.40 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Jun 2013 08:21:41 -0700 (PDT)
Message-ID: <51AF5784.3060307@jitsi.org>
Date: Wed, 05 Jun 2013 17:21:40 +0200
From: Emil Ivov <emcho@jitsi.org>
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 <fluffy@iii.ca>
References: <51A65017.4090502@jitsi.org> <C3639EB3-0F44-4893-88DA-BB9F9C96A116@iii.ca> <51A8EB7F.6000506@jitsi.org> <72B58042-78E3-4759-B3CD-204B82A38447@iii.ca> <51ACF998.5030202@jitsi.org> <CALiegf=pJtdL2A6V7bprZ_F=V39Fadb+kRw3yfO+6+MFVZ9x2A@mail.gmail.com> <5ED2CC48-1514-4C00-AEE8-A334EB67A6F4@iii.ca>
In-Reply-To: <5ED2CC48-1514-4C00-AEE8-A334EB67A6F4@iii.ca>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQlbd5fmnRmEmFgo2cC1dMSOwAmSIX2DXGb+/Ms/8lMhdWOZ5Az7dgal+9yaQzjpRISvuPuW
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [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: Wed, 05 Jun 2013 15:21:49 -0000

On 05.06.13, 02:40, Cullen Jennings wrote:
>
>
> On Jun 4, 2013, at 4:07 AM, Iñaki Baz Castillo <ibc@aliax.net>
> wrote:
>
>> 2013/6/3 Emil Ivov <emcho@jitsi.org>:
>>>>> 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.
>>>>
>>>>
>>>> Great - I have super news for you. The WG agree to do that a
>>>> year or more ago.
>>>
>>>
>>> So I've heard indeed.
>>>
>>> Unfortunately however, it seems that we might have forgotten this
>>> decision. We are now trying hard to come up with a signalling
>>> mechanism that will do everything with Offer/Answer.
>>
>>
>> I think there is a misunderstanding here. I understand from Emil's
>> mail that media re-negotation or streams addition after the first
>> SDP O/A is not carried as a new full SDP O/A. Am I right?
>>
>>
>
>
> I'm just trying to understand what the "No Plan" proposal is. I have
> not even started to think about what parts of if I like. So far, the
> more we talk about this, the more confused I get. I think some simple
> examples that showed what O/A got passed across the API from the JS
> into the browser for applications with multiple video steams would
> really help.

Then, in case you've missed any of these:

You asked how Plan A endpoints would work with No Plan browsers here:

http://www.ietf.org/mail-archive/web/rtcweb/current/msg07696.html

The reply, with sample SDP went here:

http://www.ietf.org/mail-archive/web/rtcweb/current/msg07724.html

You then moved the thread to MMUSIC and asked to see the answer here:

http://www.ietf.org/mail-archive/web/mmusic/current/msg11347.html

In the above you also asked how the answerer could refuse one video 
stream. I replied with the SDP answer and additional sample signalling here:

http://www.ietf.org/mail-archive/web/mmusic/current/msg11354.html

I don't think I've seen any additional questions from you since then.You 
are now saying that the situation is still unclear, so please let me 
know if I can help in any way. Otherwise we could also switch to 
whatever problems you have with the approach itself.

In the mean time, again on MMUSIC, Eric has asked for more detailed 
examples including sample JS code here:

http://www.ietf.org/mail-archive/web/mmusic/current/msg11360.html

Enrico has put up a very helpful and very complete example to this here:

http://www.ietf.org/mail-archive/web/mmusic/current/msg11382.html

I added a nit here:

http://www.ietf.org/mail-archive/web/mmusic/current/msg11386.html

Cheers,
Emil

-- 
https://jitsi.org