W3C home > Mailing lists > Public > public-webrtc@w3.org > July 2013

Re: Teleco Integrators vs Web Developers vs Browser Implementers

From: Suhas Nandakumar (snandaku) <snandaku@cisco.com>
Date: Wed, 3 Jul 2013 07:10:18 +0000
To: tim panton <thp@westhawk.co.uk>
CC: Iņaki Baz Castillo <ibc@aliax.net>, Ted Hardie <ted.ietf@gmail.com>, Christer Holmberg <christer.holmberg@ericsson.com>, cowwoc <cowwoc@bbs.darktech.org>, Robin Raymond <robin@hookflash.com>, "Roman Shpount" <roman@telurix.com>, Adam Bergkvist <adam.bergkvist@ericsson.com>, "piranna@gmail.com" <piranna@gmail.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>, Eric Rescorla <ekr@rtfm.com>
Message-ID: <22E0D60B-E93D-4C07-9510-B59EECAF51FA@cisco.com>


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

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:34 UTC