Webrtc-pc: rename RTCIceCandidate.ip to address?

[fippo]

We expose the ICE candidate IP in https://w3c.github.io/webrtc-pc/#dom-rtcicecandidate-ip

Given Safaris plans to use mdns hostnames here (@youennf probably knows the tracking bug) should we rename this field to address or connectionAddress?

https://tools.ietf.org/html/rfc5245#section-15.1 calls it connectionAddress and defines the content as

<connection-address>:  is taken from RFC 4566 [RFC4566].  It is the
      IP address of the candidate, allowing for IPv4 addresses, IPv6
      addresses, and fully qualified domain names (FQDNs).

I hate late-stange renames but AFAIK nobody has shipped RTCIceCandidate properties yet (apart from adapter shimming it)

[fippo]

also needs to be taken care of in webrtc-stats:
https://w3c.github.io/webrtc-stats/#dom-rtcicecandidatestats-ip
-- it would be silly to not leak in onicecandidate but then in getStats.

[lgrahl]

Wouldn't this clash with ORTC implementations that shim WebRTC?

[a2sheppy]

FWIW, from a docs standpoint, I agree with this proposal to rename ip to address, for a couple of reasons:

1. As @fippo notes, if anyone implements a scenario in which the address is not an IP address, the name becomes obsolescent.
2. This one sounds frivolous but I'm actually serious: property names as short as ip are an oddity in documentation, in that they can be difficult to read and to differentiate, potentially resulting in developers missing details as they read. When possible, I feel that 3 or 4 characters is a practical minimum for property names, with certain exceptions like coordinate axis names in some cases.

[jan-ivar]

Since we already have relatedAddress and relatedPort s/ip/address/ seems reasonable to me.

[jan-ivar]

it would be silly to not leak in onicecandidate but then in getStats.

Good catch. Not just a simple rename in getStats since it says: "(FQDNs) are not allowed".

Implementations will likely need to map ips back to FQDNs here.

There's also this: "If the DNS query returns more than one IP address, one is chosen, and then used for the remainder of ICE processing."—How well will that interop? I guess it's rare.

[alvestrand]

Mapping an IP to a FQDN is impossible in principle.
We can make it a requirement to store the FQDN that the IP was learned from, and report that in "address", but that's the way we have to phrase it.
For remote peer-reflexive addresses (I think that was the name), we don't have the FQDN that it was learned from (we pick up the address from the from address an incoming STUN packet on one of our announced interfaces).

WRT the DNS processing returning multiple candidates, this is now covered by https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-16 section 5.1, with slightly more convoluted language:

"
An IP
address SHOULD be used, but an FQDN MAY be used in place of an IP
address. In that case, when receiving an offer or answer
containing an FQDN in an a=candidate attribute, the FQDN is looked
up in the DNS first using an AAAA record (assuming the agent
supports IPv6), and if no result is found or the agent only
supports IPv4, using an A record. The rules from section 6 of
[RFC6724] is followed by fixing the source address to be one from
the candidate pair to be matched against destination addresses
reported by FQDN, in cases where the DNS query returns more than
one IP address."

I'm not completely sure what the last portion means.

[fippo]

Implementations will likely need to map ips back to FQDNs here.

No. Implementations should at a very low level only return the hostname-or-address. Otherwise you risk issues like resolving the hostname and then using it in a subsequent offer, thereby leaking the ip.

[jan-ivar]

Under the hood I suspect implementations can do whatever they want, as long as they hang on to and only expose the relevant FQDNs, right?

[aboba]

Note that the grammar for candidate in RFC 5245 Section 15.1 does not permit an mDNS name or FQDN to be used instead of an IP address, and AFAIK there are no existing ICE implementations that can handle a name today. Also, ORTC implementations expect an address, not a name. The backwards compatibility problem has been pointed out during review of the mDNS document, so we should probably wait to see how that shakes out first before changing it.

[jan-ivar]

TBC this issue only covers renaming the attribute, which I guess does not technically need to block on having it represent mDNS names.

[fippo]

chrome should actually handle addresses now: https://bugs.chromium.org/p/webrtc/issues/detail?id=4165

[jan-ivar]

@aboba section 15.1 says: "An IP address SHOULD be used, but an FQDN MAY be used in place of an IP address."

Ok to merge PR?

[jan-ivar]

Note there are two PRs here, one for webrtc-pc and one for webrtc-stats.

[vr000m]

LGTM