W3C home > Mailing lists > Public > public-webrtc@w3.org > September 2012

RE: Poll for preferred API alternative

From: Hutton, Andrew <andrew.hutton@siemens-enterprise.com>
Date: Thu, 6 Sep 2012 18:44:19 +0000
To: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>, "public-webrtc@w3.org" <public-webrtc@w3.org>
Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF012B29BD@MCHP02MSX.global-ad.net>
Hi Stefan,

I agree completely with what you stated below we have to nail down the SDP to make sure different browser vendor implementations generate compatible SDP for the browser to browser case and so that more complex apps that need to manipulate the session description know what they to expect from the browser.

And yes that is primarily the work of that other group of people in the IETF.

Regards
Andy



> -----Original Message-----
> From: Stefan Hakansson LK [mailto:stefan.lk.hakansson@ericsson.com]
> Sent: 06 September 2012 19:17
> To: public-webrtc@w3.org
> Subject: Re: Poll for preferred API alternative
> 
> On 09/06/2012 07:51 PM, Hutton, Andrew wrote:
> > Hi Harald,
> >
> > I take your point but currently you are only talking about the SDP
> that
> > Chrome produces today which is likely to change and may not be the
> same
> > SDP that another browser vendors chooses to implement so examples of
> > existing interworking problems with the SDP Chrome produces are not
> so
> > useful.  All I am saying is that we still need to do some work to
> nail
> > this down.
> 
> I agree, this must be nailed down (but I think the responsibility for
> this part is currently with the IETF rtcweb WG). And what browsers
> produce as descriptions must be similar enough to enable the app to
> just
> apply what the browser at the other end produced  - that being an
> offer,
> answer or something else - with no modifications and things should just
> work. Simple apps should never have to resort to manipulation of these
> descriptions.
> 
> This applies regardless if we stick to SDP or, for some reason, adopt
> some other format.
> 
> I think it is OK if the descriptions must be manipulated for interop
> (with non-browser end-points) cases; after all, the main target for
> this
> work is the browser-browser case.
> 
> Stefan
> 
> >
> > Regards
> >
> > Andy
> >
> > *From:*Harald Alvestrand [mailto:harald@alvestrand.no]
> > *Sent:* 06 September 2012 18:05
> > *To:* public-webrtc@w3.org
> > *Subject:* Re: Poll for preferred API alternative
> >
> > On 09/06/2012 06:30 PM, Hutton, Andrew wrote:
> >
> >     Hi All,
> >
> >     I think the discussion on SDP issues raises an important point as
> >     some people might be of the impression that the PeerConnectionAPI
> is
> >     almost complete but reality is that the SDP blob that comes out
> of
> >     it is not specified and it is likely that it will end up looking
> >     quite different to SDP that existing implementations are familiar
> >     with. We are therefore quite some way from a standard API that
> will
> >     be interoperable between different browsers and legacy
> >     implementations without a lot of tweaking and knowledge of SDP in
> >     the application.
> >
> > I've heard this theory advanced.
> >
> > I've not heard it advanced by the people who have written the
> > applications that interwork between the present, early WebRTC
> > implementations and existing, legacy SDP-using devices, such as
> sipml5.
> > What comes out of Chrome is SDP, and conforms to the SDP RFCs. (If
> not -
> > file bugs!)
> >
> > I'd like this line of argument supported by "when I fire Chrome
> browser
> > SDP at <device>, it doesn't interwork because of <reason>". That's
> much
> > more actionable than "I think".
> >
> >            Harald
> >
> 

Received on Thursday, 6 September 2012 18:44:49 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 6 September 2012 18:44:49 GMT