Re: [MMUSIC] FQDN Support Final Vote

[Roman Shpount <[e-mail]>]

On Tue, May 21, 2019 at 5:42 PM Christer Holmberg <
[e-mail]> wrote:

> >>4. Clarify ICE support validation procedures when processing session
> descriptions with FQDN in candidate connection address. Specifically, if
> agent implementing ice-sip-sdp receives a session >>description where
> candidate with FQDN connection address is the default candidate, address in
> c= line must be the literal FQDN value used connection address of the
> default candidate. If >>address in c= line is an IP address which is result
> of the FQDN resolution of candidate connection address, or FQDN which
> resolves to the same IP address as FQDN in the candidate, or anything
> >>else except the literal FQDN value used in the default candidate
> connection address, then this m= line must be treated as ICE mismatch. On
> the other hand, difference in address family and type >>between c= line and
> FQDN resolution result (regardless of what procedure is used to resolve
> FQDN), must not be considered a mismatch.
> >>
> >> It is very difficult for me to parse what you are trying to say in
> bullet 4.
> >>
> >> If an agent receives SDP with an IP address in the c= line, how does it
> know whether it is a “result of the FQDN resolution of the candidate
> connection address”?
> >> Does that agent have to do a DNS lookup after all, to see whether the
> result matches the IP address in the c= line?
> >
> > I am talking about Verifying ICE Support Procedures (
> https://tools.ietf.org/html/draft-ietf-mmusic-ice-sip-sdp-27#section-3.2.5)
> when session description is received
> > with FQDN in default candidate.
>
> First, not related to FQDN, I don't think the text in section 3.2.5 is
> valid anymore - or at least it needs to be modified. It says that if the
> SDP does not contain a candidate for each component it shall continue with
> normal RFC 3264 procedures.
>
> But, I understand that we will now explicitly say that an agent receiving
> an SDP without candidates is valid, but the agent will still continue with
> the ICE procedures.
>

To be clear, 3.2.5  adds an exception when default address
is "0.0.0.0"/"::" and port is "9", but this can be made clearer.

There are a few more problems with the language in 3.2.5, such as stating
that a=ice-mismatch is a session level attribute and applies to the entire
ICE session, not just a single m= line.

I have suggested some edits for this section but more might be needed.

> What I am saying is that when validating ICE Support, connection address
> in c= line MUST be literal FQDN from default candidate. Not its IP address
> or some other
> > resolution result, but actual FQDN. Also, in case FQDN is used in
> default candidate, ice mismatch should not be caused by any values of
> address family and type
> > in c= line. This way client does not need to do FQDN resolution when
> validating ICE support. For instance, Suhas suggests that IP address and
> family should be
> > used in c= line when FQDN is used in default candidate, but, in this
> case, ICE support cannot be validated without resolving FQDN and even this
> can produce
> > accidental ICE mismatch based on resolution result.
>
> Isn't the agent going to discard the FQDN candidate - no matter if it is
> the default candidate or not? The FQDN problems apply to such candidates
> too.
>
>
Agent receiving the session description can discard ICE candidates with
FQDN. Agent that generated the session description could have used FQDN for
the default candidate in the c= line. ICE candidate is discarded when
generating a candidate list for ICE processing, but it is still used for
ICE support verification, which occurs earlier. This is the same as IPv6
address which can be discarded by an agent on IPv4 only network, but would
still correctly validate ICE support if this IPv6 address were used in c=
line.

Regards,
_____________
Roman Shpount