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

RE: Format of candidate-attribute string

From: Martin Thomson <martin.thomson@gmail.com>
Date: Mon, 14 Jan 2013 02:35:40 +0000
Message-ID: <-5934614650064800954@unknownmsgid>
To: Justin Uberti <juberti@google.com>, Cullen Fluffy Jennings <fluffy@cisco.com>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
In this case, the right thing would be to make a candidate object with
discrete attributes for ip, port, priority, foundation, base, etc...

We could argue about what then best facilitates ease of use in signaling,
maybe a stringify that produces a=candidate.

 *From:* Cullen Jennings (fluffy)
*Sent:* ‎January‎ ‎9‎, ‎2013 ‎2‎:‎22‎ ‎PM
*To:* Justin Uberti <juberti@google.com>
*CC:* public-webrtc@w3.org
*Subject:* Re: Format of candidate-attribute string

every rev of the spec breaks all the running code so I am a long ways from
worrying about backwards compatibility at this point - lets just do the
right things even if that causes some small amount of pain. That said, I
don't care much what we do on this but I think it needs to be resolved in
the IETF trickily ice draft you and others are writing.

On Jan 8, 2013, at 5:47 PM, Justin Uberti <juberti@google.com> wrote:

> According to the latest editor's draft, section, the candidate
field is defined as follows:
>    candidate of type DOMString, nullable
>    This carries the candidate-attribute as defined in section 15.1 of
> In other words, candidate-attribute is just "candidate:<blah>", not
> However, Chrome currently emits and expects to receive candidates of type
"a=candidate:<blah>CRLF". Naturally, this is not trivially changeable,
although we could transition this over a series of Chrome releases.
> So the question becomes: is this (i.e., no a=) what was originally
intended? If so, is this something we want to change?
> Firefox doesn't currently emit trickle candidates, and it could be made
to handle either incoming format, so regardless of whether we choose to use
a= or not, we have an opportunity to resolve this issue without breaking
the world.
Received on Monday, 14 January 2013 04:01:51 UTC

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