Re: Teleco Integrators vs Web Developers vs Browser Implementers

Sent from my iPhone

On Jul 3, 2013, at 12:02 AM, "tim panton" <thp@westhawk.co.uk> wrote:

> 
> On 3 Jul 2013, at 00:51, "Suhas Nandakumar (snandaku)" <snandaku@cisco.com> wrote:
> 
>> 
>> ________________________________________
>> From: Iņaki Baz Castillo [ibc@aliax.net]
>> Sent: Tuesday, July 02, 2013 4:37 PM
>> To: Ted Hardie
>> Cc: Christer Holmberg; cowwoc; Robin Raymond; Roman Shpount; Adam Bergkvist; piranna@gmail.com; public-webrtc@w3.org; Eric Rescorla
>> Subject: Re: VS: Teleco Integrators vs Web Developers vs Browser Implementers
>> 
>> 2013/7/3 Ted Hardie <ted.ietf@gmail.com>:
>>> The question we're trying to answer is:
>>> 
>>> How do peers agree on the set of data sources to be exchanged, send them to
>>> each other via a browser, and understand how to associate the received flows
>>> with application behaviour?
>> 
>> Hi Ted, I replied to this in my mails yesterday:
>> 
>> Instead of passing SDP between JS and WebRC stack, use a real JS
>> Object based API.
>> Instead of sending an opaque SDP blob in-the-wire send the media info
>> in any custom format designed by the website developer. Anyone is fine
>> if the receiver JS can de-serialize/decode/parse it, construct the
>> requires JS Object(s) with it, and pass it to the WebRTC stack via a
>> JS API.
>> 
>> just curious, how does the one define the agreed upon structure to understand the semantics of the data stored in such a  data structure passed from one end-point to the another ...
> 
> At the standards level you don't . 
> 
> The W3C standard describes what the browser API looks like to the javascript developer. 
> 
> It defines what the developer has to do to set up a peer-connection with a set of desired properties.
> The way the javascript programmer determines what those desired properties are is up to her.
> Likewise the way the desired properties are communicated from one end to the other(s) can be 
> independent of the API.
> 
> Those properties will be derived 5 places :
> 1) from the local user's wishes, 
> 2) from the capabilities of the local hardware,
> 3) from the service's policies, 
> 4) from the remote hardware capabilities,
> 5) from the remote users wishes
> 
> Our current API surface (SDP) is good at expressing 2) and 4) but weak at expressing the other sources, especially 3)
> 
> Tim.
> 

Hello Tim

I would be interested in learning about minimally extending existing API or constraints to solve the use cases that aren't covered by 1 and 3. Also 5 is can be covered within existing API and data model semantics

My 2 cents

Cheers
Suhas

Received on Wednesday, 3 July 2013 07:11:13 UTC