W3C home > Mailing lists > Public > public-webrtc-logs@w3.org > March 2017

Re: [webrtc-pc] Candidate from onicecandidate event and addIceCandidate are incompatible

From: Lennart Grahl via GitHub <sysbot+gh@w3.org>
Date: Fri, 17 Mar 2017 20:14:26 +0000
To: public-webrtc-logs@w3.org
Message-ID: <issue_comment.created-287459701-1489781665-sysbot+gh@w3.org>
Before I can respond to your questions, let me ask:

1. What is the status quo for the `onicecandidate` event? Does it only return a single event with `null` to indicate end-of-candidates or does it return both `{ candidate: '', sdpMid: null, sdpMLineIndex: null, ... }` and `null` events to indicate end-of-candidates? If not the latter, why not?
2. Does `candidate = null` have the exact same meaning as `{ candidate: '', sdpMid: null, sdpMLineIndex: null, ... }`? If not, why not?

> I see the argument that new users would expect that... Current users are I believe accustomed to checking candidate != null though.

I can only speak for myself: I stopped checking for `null` since I've read that this information can be passed to `addIceCandidate` to indicate the end of candidates. (The normal user will have no insight whether this is actually implemented or not.)

> How does it allow candidate to be null? candidate's type isn't nullable anywhere I can see.

It is: https://github.com/w3c/webrtc-pc/blob/387e0bdb4e7db21e754209f8f0a1bb5e2f3cb333/webrtc.html#L2286
And if we really want to keep backwards compatibility to the specification, I think allowing `null` is correct. But it should be handled in the description. I think we should treat `null` as if it were `{ candidate: '', sdpMid: null, sdpMLineIndex: null, ... }` (if my assumption is correct and this has the exact same meaning as `null` as specified previously). That part is missing in the description.

GitHub Notification of comment by lgrahl
Please view or discuss this issue at https://github.com/w3c/webrtc-pc/issues/1077#issuecomment-287459701 using your GitHub account
Received on Friday, 17 March 2017 20:14:32 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 6 May 2023 21:19:40 UTC