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

Emil Ivov <emcho@jitsi.org> Mon, 03 June 2013 21:46 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 D528511E80FC for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 14:46:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.249
X-Spam-Level:
X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, 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 IHFr0TktWdaI for <rtcweb@ietfa.amsl.com>; Mon, 3 Jun 2013 14:46:11 -0700 (PDT)
Received: from mail-ea0-x230.google.com (mail-ea0-x230.google.com [IPv6:2a00:1450:4013:c01::230]) by ietfa.amsl.com (Postfix) with ESMTP id 7950E21F8EFE for <rtcweb@ietf.org>; Mon, 3 Jun 2013 14:44:04 -0700 (PDT)
Received: by mail-ea0-f176.google.com with SMTP id o14so1685675eaj.35 for <rtcweb@ietf.org>; Mon, 03 Jun 2013 14:44:03 -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=NhzK5ueQzSP3efUF3nWfJ9e7UdIXcFjOI2Hfmhuh57U=; b=UaP7ktLSTfpAxUohe7cxlJc2HBtug+qMbM85EEgL1yUGIH08y3Ncv0+WykfTvwfty5 Uhi+YuQClU+OZeJxF0X0lqk18pgxWkiDBHluLx4mL2L+p5Vjfv0G/m9iNKtP01wHMb3p 4ku1S3cL2//vLTfZYzl1x0YdCktVbD1Hulr/d2CX7/gJiVdOFfWrDwXTOSQxmwhzHX7C /8oIplM2wY1aO6GDD3wL1UYRvnlpHc0+cWu77a8uUwjh0moBy/xUl58+NYMT7i7QLZpl wN7HE64/ZO4//ZXHa+EdK5qrpQZYTPo+m9dX3Kir33SNE2hrocJqgSAdCgexqL5wo6Op H2oQ==
X-Received: by 10.14.204.3 with SMTP id g3mr24584310eeo.85.1370295843547; Mon, 03 Jun 2013 14:44:03 -0700 (PDT)
Received: from [10.1.1.28] (damencho.com. [78.90.89.119]) by mx.google.com with ESMTPSA id b14sm16658410ees.16.2013.06.03.14.44.01 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 03 Jun 2013 14:44:02 -0700 (PDT)
Message-ID: <51AD0E20.1070901@jitsi.org>
Date: Tue, 04 Jun 2013 00:44:00 +0300
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: =?UTF-8?B?ScOxYWtpIEJheiBDYXN0aWxsbw==?= <ibc@aliax.net>
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>
In-Reply-To: <CALiegf=pJtdL2A6V7bprZ_F=V39Fadb+kRw3yfO+6+MFVZ9x2A@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Gm-Message-State: ALoCoQnrdzMkzCwPSD2gwUhH/L+B4IW6l3Dm52InLrIVzjEhnd9aTAwP7io37IHEzr75fCz4jMgO
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: Mon, 03 Jun 2013 21:46:25 -0000

On 04.06.13, 00:07, Iñaki Baz Castillo wrote:
> 2013/6/3 Emil Ivov <emcho@jitsi.org>rg>:
>>>> 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?

Correct. Unless of course these streams require new payload types to be 
introduced, 5-tuples to be changed or other m= line parameters modified.

Emil

-- 
https://jitsi.org