Re: [rtcweb] SDP offer/answer vs. JSON

Dzonatas Sol <dzonatas@gmail.com> Tue, 20 September 2011 17:54 UTC

Return-Path: <dzonatas@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 36AE621F8B45 for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 10:54:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.815
X-Spam-Level:
X-Spam-Status: No, score=-3.815 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 xgdQ11LfNiXX for <rtcweb@ietfa.amsl.com>; Tue, 20 Sep 2011 10:54:50 -0700 (PDT)
Received: from mail-iy0-f172.google.com (mail-iy0-f172.google.com [209.85.210.172]) by ietfa.amsl.com (Postfix) with ESMTP id E896A21F8B3F for <rtcweb@ietf.org>; Tue, 20 Sep 2011 10:54:49 -0700 (PDT)
Received: by iaby26 with SMTP id y26so1034225iab.31 for <rtcweb@ietf.org>; Tue, 20 Sep 2011 10:57:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=x8hPoic+WWvhiCPfAUSO4GNG8nyDFBLub7ANcmxL59Y=; b=tovnYZMre6K8wmAAz2COGplBafqsVmwEuNeGSsBPIJme/efrglLvA/oVMnrzh1sqZF bBcvqdqhXFVRSVgOUUPf4lVHjY8Oo7uAOA5xOgFiRduu7Z6Zahvtchso/R6ZmI01kPrY tqUilh1TzCavIU7fb45wOGVF9Gx2wm8aQZZcI=
Received: by 10.231.9.40 with SMTP id j40mr1820048ibj.2.1316541435274; Tue, 20 Sep 2011 10:57:15 -0700 (PDT)
Received: from [192.168.0.50] (adsl-70-133-70-225.dsl.scrm01.sbcglobal.net. [70.133.70.225]) by mx.google.com with ESMTPS id ek22sm3048517ibb.12.2011.09.20.10.57.11 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 20 Sep 2011 10:57:14 -0700 (PDT)
Message-ID: <4E78D47C.70405@gmail.com>
Date: Tue, 20 Sep 2011 10:59:24 -0700
From: Dzonatas Sol <dzonatas@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.16) Gecko/20110818 Icedove/3.0.11
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <CALiegfnOCxyTo9ffQ272+ncdu5UdgrtDT-dn10BWGTZMEjZoCg@mail.gmail.com> <4E71927C.1090606@skype.net> <CALiegfnEaYVsZpKQOoVtT=2gGCzssX79pxLGo7H2Ez0GcMTG-A@mail.gmail.com> <0BF9ED5E-5B73-4316-AE95-0D85B73CBD19@phonefromhere.com> <CALiegfnE9G_vxXDha7pb57pmd=rovLOz=-uWTOirSPDV-pLyMg@mail.gmail.com> <20110915140248.4cc17977@lminiero-acer> <4E71F90D.8030302@alvestrand.no> <F0A2E045-68FC-4DC0-A0E8-BF29E7690FAF@acmepacket.com> <A444A0F8084434499206E78C106220CA0BC11A7E43@MCHP058A.global-ad.net> <4E78CC51.5080706@gmail.com>
In-Reply-To: <4E78CC51.5080706@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [rtcweb] SDP offer/answer vs. JSON
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: Tue, 20 Sep 2011 17:54:51 -0000

Login to the simulator may mean no login needed to other credentials; 
further, this is where some debate over ICE or...

http://www.ietf.org/about/note-well.html

...browser in the simulator.

Maybe we can SSRC the XPointer XML, and focus on that interop with OAuth 
MAC in single UDP over S/MIME or IPv6.

Again, where this makes sense: OAuth MAC plus S/MIME TOGETHER. I bet the 
browsers devs can guess the default.

On 09/20/2011 10:24 AM, Dzonatas Sol wrote:
> In the simulated room, the board posted the note-well such that all 
> participants, even unknown, had this much quickness in resolution 
> rather than be stuck in cap-neg in more blind situations.
>
> On the media plane, we may be able to make those "styx" notices, much 
> like iNotify, yet these are one of those things that just works and 
> still needs improvements, like this.
>
> From the top, the API needs the JSON-to-XPointer device driver for 
> late binds; use-case: default emulation of scripted UI-only with 
> saved-state.
>
> Is there some default for display size? Shop owners may want some 
> signal sent that switches modes on all display units from after-hours 
> to real-time. With some notices, where it makes sense, you don't 
> always want to-allow augmentation of posted note-well displays.
>
> On 09/20/2011 09:41 AM, Elwell, John wrote:
>> I agree with the points Hadriel makes. And I would add another point. 
>> SDP sometimes has several ways of doing the same thing, some 
>> official, some de facto. For example, cap-neg as the official way of 
>> negotiating a profile (say AVP versus SAVP) and well-practiced but 
>> simpler techniques for doing the same thing. By having JSON at the 
>> API, it is left to the application (JS or server) to decide which 
>> techniques to use when federating, according to the environment it 
>> finds itself in. I believe this is the right way to go. Please don't 
>> lock this into the browser and force cap-neg (say) on everyone.
>>
>> John
>>
>>
>>
>>> -----Original Message-----
>>> From: rtcweb-bounces@ietf.org
>>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Hadriel Kaplan
>>> Sent: 16 September 2011 19:29
>>> To: Harald Alvestrand
>>> Cc:<rtcweb@ietf.org>
>>> Subject: [rtcweb] SDP offer/answer vs. JSON (was: About
>>> defining a signaling protocol for WebRTC (or not))
>>>
>>>
>>> On Sep 15, 2011, at 9:09 AM, Harald Alvestrand wrote:
>>>
>>>> The disadvantage of parsing to another structure (I am fond
>>> of JSON myself) is that one has to maintain a data definition
>>> for the format being parsed to, a defined transform between
>>> that and the "canonical SDP structure" has to be implemented
>>> in user space when one does SDP interoperability, both of
>>> those have to be updated for every SDP extension that someone
>>> defines somewhere, and one is still not free to define
>>> extensions on the non-SDP side if one still requires the
>>> ability to map them into SDP.
>>>> If one uses the "native" SDP format, which is the format in
>>> which every extension to the format gets documented, the
>>> browsers are the ones who *have* to parse it (although others
>>> are likely to).
>>>
>>>
>>> Right so the above paragraphs get to the heart of the matter,
>>> methinks.  Ultimately we need W3C to define an API, and the
>>> API has to provide a means of learning RTP/media info from
>>> the browser and commanding the browser to perform certain
>>> things with RTP/media.  One could expose this API as a true
>>> data structure, or as a long string of tokens to be
>>> parsed/serialized back/forth.  If the latter, then the
>>> choices are basically JSON or SDP.  And SDP seems
>>> advantageous because it appears to be the least work for the
>>> simple use-cases, because the javascript could just copy
>>> back/forth the SDP between the browser and server.  In other
>>> words you're optimizing for the very simple use-cases, in
>>> exchange for making it more complicated for the advanced
>>> use-cases.  Right?
>>>
>>> OK, that's a laudable goal.  And I recognize that the
>>> decision has basically already been made, and nothing's going
>>> to change it.
>>>
>>> But email's free... so for the sake of posterity (and email
>>> archiving) here're some reasons not to use SDP anyway:
>>> 1) Incorporating SDP and the offer/answer model into the
>>> Browser and W3C API inexorably ties the W3C to the IETF
>>> MMUSIC working group for all time.  So far, I had been going
>>> on the assumption the IETF would be defining what the RTP
>>> library had to do/expose, while W3C would define the API.
>>> But if the API includes SDP offer/answer, that portion is the
>>> IETF's domain too, afaik.  Anything the W3C wants to do in
>>> the future for that has to go through the IETF, not just
>>> IANA. (right?)
>>>
>>> 2) This isn't just about JSON vs. SDP - it's about SDP
>>> *offer/answer*.  SDP offer/answer wasn't meant to be an API
>>> between an application and its RTP library - it's a
>>> *protocol* between applications.  One side-effect of this is
>>> it has historic state.  For example, if an SDP offer contains
>>> two media lines, and one media is removed, the number of SDP
>>> media lines don't reduce back to one - EVER.  So if
>>> PeerConnection.removeStream() is invoked, the Browser needs
>>> to remember there was that stream and signal it in SDP as
>>> disabled for all time, until PeerConnection is closed.  If
>>> addStream() is invoked later, it could/could-not re-use that
>>> same (disabled) media line, or add a new one.
>>>
>>> As another example, if a new SDP offer is sent out in SIP and
>>> gets rejected with a 488, the session reverts to the
>>> previously agreed SDP state.  The Browser would therefore
>>> have to keep state of previous SDP and revert to it to handle
>>> this case.  For example, if my Javascript started with only
>>> an audio MediaStream in PeerConnection and later added a
>>> video MediaStream to it, the new SDP offer would contain two
>>> media lines - if the offer gets rejected with 488, how is
>>> that communicated to the Browser and what will the browser do?
>>>
>>> 3) You might well want information conveyed across that "API"
>>> that is not meant to be sent on the wire in SDP - things you
>>> don't want defined by IANA as SDP tokens.  For example, you
>>> may want to provide packet counts, jitter, latency, and other
>>> meta-information about individual RTP codecs.  Using JSON
>>> allows you to have data member variables which will not get
>>> serialized into SDP, but are purely for the javascript's use,
>>> while still within the referential tree structure of the
>>> media stream info.  Or they may be for sending to peers, but
>>> simply not for SDP. (like you could send the jitter/latency
>>> info through the signaling channel)
>>>
>>> 4) Obviously if the application as a whole needs to do SDP
>>> offer/answer, then *someone* will have to implement it
>>> correctly, including the state-related stuff.  It could be
>>> the browser or the javascript that do this.  Chrome may do a
>>> perfect job of that in the browser, afaik.  But there are
>>> other browser vendors, including niche ones such as Dolphin
>>> and Skyfire.  What are the odds they all get it right the first time?
>>>
>>> So which would you rather have updating an SDP engine, if one
>>> is even needed... or updating "every SDP extension that
>>> someone defines somewhere": the javascript which is written
>>> by the developer that knows what they want when they want it,
>>> and can update their code by updating their javascript (or
>>> not if they don't need to); or the browsers which are written
>>> by companies not under the javascript developer's control, at
>>> a time of the browser companies' choosing?
>>>
>>> Obviously for some things the browser will have to be updated
>>> regardless, for example to understand rather than just ignore
>>> new JSON entries, to provide new codecs, etc.  But not all
>>> new SDP attributes require changes in the media plane, nor
>>> encoding into JSON.  In fact, a lot doesn't - some of it's
>>> higher-application info, not really for the RTP library, and
>>> more of it's coming in the future.
>>>
>>> -hadriel
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>> _______________________________________________
>> rtcweb mailing list
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
>


-- 

---
<i>The wheel.</i metro-link=t dzonatasolyndra>