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

[Dzonatas Sol <[e-mail]>]

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: [e-mail]
>>> [mailto:[e-mail]] On Behalf Of Hadriel Kaplan
>>> Sent: 16 September 2011 19:29
>>> To: Harald Alvestrand
>>> Cc:<[e-mail]>
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>
>


-- 

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