Re: [MMUSIC] FQDN Support Final Vote

[Roman Shpount <[e-mail]>]

On Fri, May 24, 2019 at 3:33 PM Christer Holmberg <
[e-mail]> wrote:

> I am fine (and I have seen nobody object) to the following part of Roman's
> suggested text (with some modifications by myself), which is about
> discarding FQDN candidates:
>
> "<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).  When parsing this field, an
> agent can differentiate  an IPv4 address and an IPv6 address by presence
> of a colon in its value - the presence of a colon indicates IPv6.  An
> agent processing remote candidates MUST ignore candidate lines that include
> candidates with FQDN or IP address versions that are not supported or
> recognized.  The procedures for handling FQDN candidates, and for agents
> to indicate support of such procedures, need to be specified in an
> extension specification."
>

I am fine with this change.


> >> Now, in addition to that, Roman wants to cover FQDNs in c= lines. for
> “verification of ICE support”. If that is needed, could it be in a separate
> section and/or paragraph?
> > Can you please provide a concrete text suggestion that satisfies your
> concerns.
>
> The second part of Roman's text covered that:
>
> "If candidate with FQDN <connection-address> is the default
> destination/candidate, the "c=" address type MUST be set the IP address
> family for the
> FQDN DNS resolution result and the "c=" connection address MUST be set to
> FQDN. Differences in the "c=" line address family and type with FQDN
> resolution result MUST not cause ICE support verification failure."
>
> I had some problems to parse the text, but that is probably only
> editorial. But, I *think* Suhas raised some technical issues with it.
>
> One way could be to simply say that, if the c= line contains a FQDN, the
> agent simply does not look for a matching candidate. Because, if the agent
> is anyway going to discard FQDN candidates, why does it matter whether the
> c= line FQDN has a matching FQDN candidate?
>
>
I like this. let's just add an appropriate clause to the verifying ICE
support procedures.

Current language in section 3.2.5 specifies:

If this condition is not met, the agents MUST process the SDP based on
normal [RFC3264] procedures, without using any of the ICE mechanisms
described in the remainder of this specification with the few exceptions
noted below:

1.  The presence of certain application layer gateways MAY modify the
transport address information as described in Section 8.2.2.  The behavior
of the responding agent in such a situation is implementation defined.
Informally, the responding agent MAY consider the mismatched transport
address information as a plausible new candidate learnt from the peer and
continue its ICE processing with that transport address included.
Alternatively, the responding agent MAY include an "a=ice-mismatch"
attribute in its answer and MAY also omit a=candidate attributes for such
data streams.

2.  The transport address from the peer for the default destination
correspond to IP address values "0.0.0.0"/"::" and port value of "9".  This
MUST not be considered as a ICE failure by the peer agent and the ICE
processing MUST continue as usual.

I would suggest adding:

3.  The transport address from the peer for the default destination is
an FQDN.  Regardless of the procedures used to resolve FQDN or the
resolution result, this MUST not be considered as a ICE failure by the peer
agent and the ICE processing MUST continue as usual.


If this is added the second part that Christer found confusing can be
removed.

Regards,
_____________
Roman Shpount