It's a bug in Chrome. We had to two-step it, namely add support for parsing the non a= version first, and then generating the non a= version later. All current versions of Chrome support parsing the non a= version; we just forgot to do the generate part. We're taking care of it now. On Mon, Jun 23, 2014 at 11:11 AM, Eric Rescorla <ekr@rtfm.com> wrote: > > > > On Mon, Jun 23, 2014 at 8:20 AM, Adam Roach <adam@nostrum.com> wrote: > >> On 6/23/14 09:32, Emil Ivov wrote: >> >>> Personally I thought it was an oversight in the FF implementation >>> >> >> No; starting with the W3C spec (because we're talking about a JS API >> here), we reached the same conclusion as Iñaki did, using the same (rather >> obvious) chain of logic. It is most assuredly not an oversight, as we've >> had to take extra steps to process the candidates that Chrome generates: >> >> http://dxr.mozilla.org/mozilla-central/source/media/ >> webrtc/signaling/src/sipcc/core/gsm/fsmdef.c#4148 >> >> There were discussions about that at the interim in Boston and then >>> again in Orlando... >>> >> >> Orlando? Ah, I see the confusion here. Iñaki is talking about a W3C API. >> You're talking about... actually, wait. I don't know what you're talking >> about. The W3C didn't meet in Orlando, and the IETF doesn't specify >> Javascript APIs. > > > As Adam says, this is totally clear in the W3C API and Firefox is behaving > correctly. > > I don't want to speak for Justin, but IIRC we discussed this a while ago > and > he agreed that it was a bug in Chrome, so I assume it's just an oversight > it hasn't been fixed. > > -Ekr > > >
Received on Wednesday, 25 June 2014 03:09:08 UTC