- From: Iñaki Baz Castillo <ibc@aliax.net>
- Date: Mon, 23 Jun 2014 12:16:48 +0200
- To: "public-webrtc@w3.org" <public-webrtc@w3.org>
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).
--
Iñaki Baz Castillo
<ibc@aliax.net>
Received on Monday, 23 June 2014 10:17:39 UTC