Re: [MMUSIC] FQDN Support Final Vote

[Roman Shpount <[e-mail]>]

Suhas,

I have created a pull request on top of the mismatch branch:
https://github.com/suhasHere/ice-sip-sdp/pull/3

New language in ICE Verification procedures is:

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.

New language for connection address:

<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
generating local candidates MUST not use FQDN addresses. 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
generation and handling FQDN candidates, as well as, how agents indicate
support of such procedures, need to
be specified in an extension specification.

I have kept Christer's edits and, since we provide no guidance on how to do
this, I added extra language that agents must not use FQDN when generating
local candidates.

Regards,
_____________
Roman Shpount


On Fri, May 24, 2019 at 6:42 PM Suhas Nandakumar <[e-mail]>
wrote:

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