Re: Teleco Integrators vs Web Developers vs Browser Implementers

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.

Received on Wednesday, 3 July 2013 07:03:15 UTC