Re: ICECandidate.candidate syntax is wrong in Chrome

FWIW, the trickle ICE draft [0] does require that the "a=" be present. 
Personally I thought it was an oversight in the FF implementation (and I 
really hope we are not going to get into an argument about that).

[0] Trickle ICE: http://tools.ietf.org/html/draft-ietf-mmusic-trickle-ice-01

Emil

On 23.06.14, 13:16, Iñaki Baz Castillo wrote:
> Hi,
>
> Current Chrome generates a ICECandidate.candidate attribute as follows:
>
> candidate: "a=candidate:2575492245 1 udp 41885439 X.X.X.X 52784 typ
> relay raddr Y.Y.Y.Y rport 52897 generation 0\r\n"
>
> While Firefox 30 generates it as follows:
>
> candidate: "candidate:2 1 UDP 100401151 Z.Z.Z.Z 53955 typ relay raddr
> A.A.A.A rport 53955"
>
>
> Well, the spec clearly says:
>
> ------------------
> candidate of type DOMString, , nullable
> This carries the candidate-attribute as defined in section 15.1 of [ICE].
> ------------------
>
> And section 15.1 of RFC 5245 clearly defines candidate-attribute
> without the "a=" and without the leading \r\n":
>
> ------------------
>     candidate-attribute   = "candidate" ":" foundation SP component-id SP
>                             transport SP
>                             priority SP
>                             connection-address SP     ;from RFC 4566
>                             port         ;port from RFC 4566
>                             SP cand-type
>                             [SP rel-addr]
>                             [SP rel-port]
>                             *(SP extension-att-name SP
>                                  extension-att-value)
> ------------------
>
> How is possible that Chrome generates such a wrong stuff when it is
> clearly documented in the specs?
>
> In Firefox 30 I get a "Failed to add remote candidate", not sure if
> the above is the reason (anyhow I'm pretty sure that all the WebRTC
> implementations are "ready" to accept whatever Chrome generates).
>
>
>

-- 
https://jitsi.org

Received on Monday, 23 June 2014 14:32:37 UTC