- 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