Re: [MMUSIC] FQDN Support Final Vote

[Christer Holmberg <[e-mail]>]

Hi,

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

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

Regards,

Christer