hbos@: can you take a look at this?

hbos@ Gentle Ping! Could you please let us know is there any latest update available on this issue?

Thanks!

Sorry for the late response. I have not had any time to work on this at all. Does this need to be prioritized?

Those exist -
    readonly attribute DOMString               candidate;
    readonly attribute DOMString?              sdpMid;
    readonly attribute unsigned short?         sdpMLineIndex;
Those are missing -
    readonly attribute DOMString               foundation;
    readonly attribute unsigned long           priority;
    readonly attribute DOMString               ip;
    readonly attribute RTCIceProtocol          protocol;
    readonly attribute unsigned short          port;
    readonly attribute RTCIceCandidateType     type;
    readonly attribute RTCIceTcpCandidateType? tcpType;
    readonly attribute DOMString?              relatedAddress;
    readonly attribute unsigned short?         relatedPort;

I have not tested the serializer, but Chrome exposes a toJSON method.

As this issue can't be triaged from TE end removed the Needs-Triage-M57 and added appropriate milestone for this.

Published spec now also includes ufrag

Bumping to M60. Please correct if that's wrong.

deadbeef@, you added these to the spec in https://github.com/w3c/webrtc-pc/pull/325, do you still think it's a good idea to implement this? Nobody else has AFAICT, so just reverting it from the spec would be a quick fix to alignment :)

I think it's a good idea, yes. All of the necessary fields should already be there at the webrtc level.

It makes sense to address this after we've sorted out RTCRtpSender and friends, since that exposes candidates in a new way and will require fixing candidate-related things in the webrtc layer. RTCRtpSender -> RTCDtlsTransport -> RTCIceTransport -> RTCIceCandidate.

Per #11 this should already exist in the WebRTC layer.