Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate?

[Justin Uberti <[e-mail]>]

On Tue, Feb 5, 2019 at 10:19 AM Roman Shpount <[e-mail]> wrote:

> On Tue, Feb 5, 2019 at 10:03 AM Alan Ford <[e-mail]> wrote:
>
>> If that update was to be made, this goes against the text
>> in draft-ietf-rtcweb-mdns-ice-candidates-02 which says:
>>
>>    An ICE agent that supports mDNS candidates MUST support the situation
>>    where the hostname resolution results in more than one IP address.
>>    In this case, the ICE agent MUST take exactly one of the resolved IP
>>    addresses and ignore the others.  The ICE agent SHOULD, if available,
>>    use the first IPv6 address resolved, otherwise the first IPv4
>>    address.
>>
>
> This is obviously not going to work. At the very minimum ICE client should
> be listening for connectivity checks on all addresses to which FQDN
> candidate resolves, including IPv4 and IPv6. It also should do connectivity
> checks to all addresses. Otherwise, if you have two clients, one dual stack
> and another single stack, they are not going to see each other, since one
> will be listening and sending connectivity checks via IPv6 and another via
> IPv4. This is why language about FQDN was removed from mmusic-ice-sip-sdp
> -- it was broken.
>

> For ICE to work, you want to include all possible addresses for FQDN in
> the candidate list and then proceed with nomination as if they were
> independent candidates.
>

I don't think this is correct behavior, but it's really beside the point
since we can ignore it if we have the one-FQDN-per-address concept we
discussed.

>
> But there’s a bigger problem here, which is how to cope with an FQDN is
>> not resolvable.. So the intention, as I understand it, is that when these
>> host candidates leave the mDNS domain and are thus not resolvable, they
>> will be treated as peer reflexive candidates.
>>
>> But at that point there is no address family information available, so
>> how does an ICE agent know to do pairing with these candidates, which
>> requires the address family to be known?
>>
>
> I do not think this is a problem. For peer reflexive candidates, ICE agent
> knows address family/local address/port where connectivity check was
> received and the address family/remote address/port from which the
> connectivity check was received. Everything, including the address family
> is known in this case and agent can proceed with nomination as with any
> other peer reflexive candidate.
>

Right - this is implemented today in Chrome and appears to be working well
so far (with a few minor bugs discovered along the way).