Re: [MMUSIC] FQDN Support Final Vote

[Suhas Nandakumar <[e-mail]>]

Thanks Roman .. just to ensure we are all on same page . Would you be ok to
create a new PR for FdN support from yours and Christers proposal  . We
will have one place to approve it and get it merged

Please let me know

Thanks
Suhas

On Sat, May 25, 2019 at 3:17 AM Roman Shpount <[e-mail]> wrote:

> 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
>
>