RTCPeerConnection constructor doesn't fail with empty iceServers list.

RESOLVED INVALID

Status

()

Core
WebRTC
P3
normal
Rank:
35
RESOLVED INVALID
3 years ago
a year ago

People

(Reporter: gordon, Unassigned)

Tracking

(Blocks: 1 bug, {dev-doc-complete})

40 Branch
dev-doc-complete
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

3 years ago
According to the spec for updateIce [0], which is called from the RTCPeerConnection constructor:

"If the iceServers dictionary member is present, but its value is an empty list, then throw an InvalidAccessError and abort these steps."

However, I observe no such error being thrown.  In fact, one ICE candidate is generated and I am able to use the PeerConnnection to communicate between two tabs on the same machine.  This seems like reasonable behavior; you shouldn't have to specify ICE servers for testing on localhost.  I think the spec should be changed.

Interestingly, when I completely omit iceServers from the RTCConfiguration dictionary, two (instead of one) ICE candidates are produced.  This suggests to me (who knows nothing) that the ICE agent's default iceServers lists is non-empty, which seems odd.

[0] http://w3c.github.io/webrtc-pc/#dom-peerconnection-updateice
Blocks: 1165687
backlog: --- → webRTC+
Rank: 35
Priority: -- → P3
Status: UNCONFIRMED → NEW
Ever confirmed: true
I've opened https://github.com/w3c/webrtc-pc/issues/393 to attempt to resolve this in the spec instead.
Keywords: dev-doc-needed
This was fixed in the spec instead: https://github.com/w3c/webrtc-pc/pull/394
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → INVALID
Yeah, browsers are permitted to provide a default set of ICE servers if they wish; if they do, this would not throw. The documentation covers this now.
Keywords: dev-doc-needed → dev-doc-complete
To be clear, it does not throw, regardless of whether defaults have been configured or not. See bug 1272967.
You need to log in before you can comment on or make changes to this bug.