- From: Hutton, Andrew <andrew.hutton@siemens-enterprise.com>
- Date: Thu, 6 Sep 2012 17:51:38 +0000
- To: Harald Alvestrand <harald@alvestrand.no>, "public-webrtc@w3.org" <public-webrtc@w3.org>
- Message-ID: <9F33F40F6F2CD847824537F3C4E37DDF012B28A8@MCHP02MSX.global-ad.net>
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. 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 17:52:06 UTC