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

Re: "SDP"

From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Mon, 21 Oct 2013 03:43:32 +0200
Message-ID: <CALiegfkWoCD4Hzzqu53zeO=Z9mMyPhX6qHkC_7=UJGWtjCkptg@mail.gmail.com>
To: Barry Dingle <btdingle@gmail.com>
Cc: public-webrtc@w3.org, "Sunyang (Eric)" <eric.sun@huawei.com>, Matthew Kaufman <matthew.kaufman@skype.net>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Juts open the HTML version: http://tools.ietf.org/html/rfc2327

Anyhow, it is clear that, since WebRTC relies on SDP, it should implement
the latest SDP spec (so RFC 4566) right?

And what I expect is that finally WebRTC device implementors will take the
buggy Chrome SDP stack as reference for "interoperability" tests instead of
reading the specs ("Chrome expects this kind of SDP and fails otherwise so
let's imitate it").

Somebody here should read the entire RFC 2327 or 4566 to understand the
monster you have introduced into the browser and WebRTC API. It could not
be worse.

--
Iñaki Baz Castillo
<ibc@aliax.net>
El 21/10/2013 03:05, "Barry Dingle" <btdingle@gmail.com> escribió:

> Silvia,
>
> The preamble at  http://tools.ietf.org/rfc/  states -
>
> "Obsoletes xxxx refers to other RFCs that this one replaces;
> Obsoleted by xxxx refers to RFCs that have replaced this one."
>
> https://datatracker.ietf.org/doc/rfc2327/  states that -
>
> "Obsoleted by RFC 4566 <https://datatracker.ietf.org/doc/rfc4566/>
> Updated by RFC 3266 "
> <https://datatracker.ietf.org/doc/rfc3266/>
>
> So 2327 has been replaced by 4566.
>
> But if you look at  *http://www.ietf.org/rfc/rfc2327.txt*  you do not see
> that it has been 'replaced' by 4566.
>
> /Barry Dingle
>
>
>
> On Mon, Oct 21, 2013 at 11:44 AM, Silvia Pfeiffer <
> silviapfeiffer1@gmail.com> wrote:
>
>> Picking up on this old thread: are we anywhere near moving from
>> rfc3264 to rfc4566 for SDP yet?
>>
>> I'm asking because we've found some issue wrt order of lines and
>> rfc4566 is more strict which Chrome does not seem to adhere to.
>>
>> For example, Chrome creates and expects the "t=" line right after the
>> "s=" line and if you change the order to the one prescribed in rfc4566
>> (i.e. move the "t=" line after the "b=" line), you get the following
>> error:
>> [6:6:1019/154128:ERROR:rtc_peer_connection_handler.cc(419)] Failed to
>> parse SessionDescription. a=msid-semantic: WMS
>> mINCZktUQbGayYwubbgUTOh8SknO7HDlnqKq Expect line: t=
>>
>> Is there a plan to move to the "newer" (2006) RFC?
>>
>> Cheers,
>> Silvia.
>>
>>
>>
>> On Thu, Oct 18, 2012 at 8:23 PM, Sunyang (Eric) <eric.sun@huawei.com>
>> wrote:
>> > 3264+4566, and I think RFC 3264 may need to be revised to use 4566
>> instead
>> > of 2327.
>> >
>> > And I think all browser need to support that, right?
>> >
>> >
>> >
>> >
>> >
>> > Yang
>> >
>> > Huawei
>> >
>> >
>> >
>> > From: Matthew Kaufman [mailto:matthew.kaufman@skype.net]
>> > Sent: Thursday, October 18, 2012 5:07 AM
>> > To: public-webrtc@w3.org
>> > Subject: "SDP"
>> >
>> >
>> >
>> > The W3C WEBRTC specification refers to “SDP” and has a bibliography
>> entry
>> > for “SDP”. This entry points to RFC3264 (“An Offer/Answer Model with the
>> > Session Description Protocol (SDP)”, and not in fact to any of the RFCs
>> that
>> > describe SDP. RFC3264 itself points to RFC2327, which has been
>> obsoleted by
>> > RFC4566.
>> >
>> >
>> >
>> > When the specification says things like “sdp of type DOMString,
>> nullable –
>> > The string representation of the SDP” are we really trying to talk
>> about the
>> > subset of RFC2327 that is covered by RFC3264, or do we really mean the
>> SDP
>> > as described in RFC4566, or something else entirely?
>> >
>> >
>> >
>> > Matthew Kaufman
>>
>>
>
Received on Monday, 21 October 2013 01:44:01 UTC

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