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

Re: [SPAM] RE: VS: Teleco Integrators vs Web Developers vs Browser Implementers

From: tim panton <thp@westhawk.co.uk>
Date: Fri, 5 Jul 2013 18:35:10 +0100
Cc: "'Martin Thomson'" <martin.thomson@gmail.com>, "'Parthasarathi R'" <partha@parthasarathi.co.in>, "'cowwoc'" <cowwoc@bbs.darktech.org>, "'Christer Holmberg'" <christer.holmberg@ericsson.com>, 'Iñaki Baz Castillo' <ibc@aliax.net>, "'Robin Raymond'" <robin@hookflash.com>, "'Roman Shpount'" <roman@telurix.com>, "'Adam Bergkvist'" <adam.bergkvist@ericsson.com>, "'Ted Hardie'" <ted.ietf@gmail.com>, "'piranna_gmail.com'" <piranna@gmail.com>, "'public-webrtc_w3.org'" <public-webrtc@w3.org>, "'Eric Rescorla'" <ekr@rtfm.com>
Message-Id: <F977E583-4B5F-495A-B7E5-53E740C20823@westhawk.co.uk>
To: "Martin Steinmann" <martin@ezuce.com>

On 5 Jul 2013, at 18:20, "Martin Steinmann" <martin@ezuce.com> wrote:

>> 
>> From: tim panton [mailto:thp@westhawk.co.uk] 
>> Sent: Friday, July 05, 2013 1:05 PM
>> To: Martin Steinmann
>> Cc: 'Martin Thomson'; 'Parthasarathi R'; 'cowwoc'; 'Christer Holmberg';
> 'Iñaki Baz Castillo'; 'Robin Raymond'; 'Roman Shpount'; 'Adam Bergkvist';
> 'Ted >Hardie'; 'piranna_gmail.com'; 'public-webrtc_w3.org'; 'Eric Rescorla'
>> Subject: Re: [SPAM] RE: VS: Teleco Integrators vs Web Developers vs Browser
> Implementers
>> 
>> 
>> On 5 Jul 2013, at 17:59, "Martin Steinmann" <martin@ezuce.com> wrote:
>> 
>>>> 
>>>> From: Martin Thomson [mailto:martin.thomson@gmail.com]
>>>> Sent: Friday, July 05, 2013 12:50 PM
>>>> To: Martin Steinmann
>>>> Cc: Parthasarathi R; cowwoc; Christer Holmberg; Iñaki Baz Castillo; 
>>>> Robin Raymond; Roman Shpount; Adam Bergkvist; Ted Hardie; 
>>>> piranna_gmail.com; >public-webrtc_w3.org; Eric Rescorla
>>>> Subject: Re: VS: Teleco Integrators vs Web Developers vs Browser 
>>>> Implementers
>>>> 
>>>> On 5 July 2013 09:41, Martin Steinmann <martin@ezuce.com> wrote:
>>>>> If you abstract from proprietary solutions, can you make a list of what
> else is used other than SIP and XMPP?  We are talking about a standard here,
>> aren't >we?
>>>> 
>>>> That's an excellent question.
>>>> 
>>>> Most Web applications don't need and really don't want a standard when
> it comes to signaling.  It's too restrictive.  And most of the examples I've
> seen >>don't use any sort of standardized signaling.  That list includes
> almost every WebRTC example in existence, with the exception of a small few.
>>>> 
>>>> That's why we explicitly state that signaling is out of scope for rtcweb
> and WebRTC.
>>> 
>>> If so this is really sad as it will make WebRTC pretty useless for all
> enterprise applications where interop with anything but itself is desired.
> We have >enough proprietary communications applications in the consumer
> space already and don't need yet another one.  I am also sad to see that
> this group seems >to have deteriorated into a debate club after the WebRTC
> conference in Atlanta, after very promising progress had been made until
> then.  Please get back >on track.
>> 
>> In your enterprise :
>> Does your web-based HR app use a standardised signalling to transfer data
> between the browser and the server?
>> Does your web-based calendar app use the same standardised signalling ?
>> 
>> I'm guessing they don't - but that they interop with a standardised
> server-to-server protocol which is not the same as is used to the browser.
>> 
>> Tim.
> 
> If you want to solve 'world hunger' you will likely never get to any API
> anyone will agree with.  What I would suggest is that the group gets back to
> focus.  The primary application is voice and video at least in my book and
> the standard protocols for that are SIP and XMPP and I haven't heard
> anything to the contrary on this list.


>  Avoiding gateways and media
> anchoring points and enable seamless enterprise interop between different
> devices might cost you a few more bits on the wire or a bit more complexity
> for your proprietary app, but so be it.

I have no idea why you might think I'm trying to avoid that. 
I've just spent the last 8 years _not_ avoiding that - indeed providing exactly what you describe.
Turns out that SDP is a _really_ bad API surface for doing that. 
It is _much_ easier to get the SDP your enterprise devices are expecting if you start with a sensible
object model and mange that. So much so that we take the SDP the browser emits, parse it to an object
model and then go from there.

Why? Well because there is no pre-existing device on the planet, enterprise or not, that will consume the SDP
that chrome and firefox generate, so inevitably you need to rewrite it (and proxy the media, but that is a separate story).


>  Otherwise, create your own browser
> plugin and you can do whatever.

Been there, done that, got the t-shirt.

> --martin
> 
Received on Friday, 5 July 2013 17:35:37 UTC

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