Re: [MMUSIC] FQDN support in ice-sip-sdp

[Christer Holmberg <[e-mail]>]

Hi,

>>>>> I *think* I agree with Suhas that the FQDN handling should be a separate draft – a generic ICE draft produced by the ICE WG. 
>>>>> ice-sip-sdp would then specify how it is implemented in SDP (separate a=candidiate lines etc).
>>>> 
>>>> Perhaps it could be combined with the mDNS draft?
>>>
>>> I am not sure if this belongs to a new draft or mDNS draft. We can decide this later. 
>>> What we need to decide now comes down to two choices:
>>>
>>> a. Say that FQND is allowed in candidate connection-address but these candidate lines are skipped. 
>>> Handling of FQDN lines is defined in the future specification.
>>>
>>> b. Figure out how FQDN is handled. Options written up so far imply either selecting one resolution result
>>> in random or requiring the FQDN resolves to a single address. I think former is broken and later does not 
>>> exist in real life.
>>> I would not like this draft to be released with either option. I think adding address type to candidate brings 
>>> candidate line connection address definition in line with SDP c= line specification and should work, but someone 
>>> needs to review this. I do not think this will require more then 2-3 extra paragraphs in the document which I am 
>>> willing to write. I agree this is scope creep but FQDN were included in RFC 5245 so people expect them to be supported 
>>> by this draft as well.
>>>
>>> At the end, this is up to the group to decide. I just need something I can implement. If option a makes people unhappy 
>>> then we will need to find minimal viable option b.
>>
>> As far as the technical solution is concerned (using separate a=candidate lines for each IP version family etc),
>> I think it looks good.
>>
>> As far as documenting is concerned, I think the SDP specifics (separate a= lines etc) could be defined in ice-sip-sdp - but I
>> would not object to having a separate draft.
>>
>> My point is that I don't see FQDN support as SDP-specific, so I would like to have generic ICE FQDN text documented 
>> somewhere, which the SDP-specific procedures then reference.
>
> I see your point, but I would prefer to avoid creating another dependency which will prevent ice-sip-sdp from 
> being published.

We need to keep in mind why we are doing RFC 8445 ice-sip-sdp in the first place.

Sure, one reason was to separate functionality from protocol.

But, the other reason was to correct issues and unspecified cases found in RFC 5245, and FQDN seems to be one such issue. Unfortunately we didn't detect it before publishing RFC 8445, so any generic ICE FQDN procedures would have to be in a separate draft.

Again, I don't have a strong opinion on whether the SDP specific parts of FQDN are in ice-sip-sdp or in a separate draft.

Keep in mind that we also need to decide on whether ice-pac should be an ice-sip-sdp dependency, in which case the publication may get delayed anyway (eventhough we hope to finalize ice-pac pretty fast).

> Please note, that if we specify that candidate line using FQDN contact-address MUST specify address type and FQDN MUST resolve 
> to a single address per address type, then FQDN handling is trivial: Agent should do a DNS resolution and use the result. 

Yes.

> Figuring out how to handle multiple results per DNS query certainly warrants a separate draft and should be out of scope. 

We also need to keep in mind that, eventhough a single DNS request only returns a single address, if some kind of load balancing is used different DNS requests may return a different address. Perhaps we need to cover that by saying that an ICE agent must not change the IP address:port associated with a candidate.

> What makes sense for me is:
>
> a. Define how to specify address type in candidate line. This is certainly an SDP problem and I think is a pre-requisite to using any addresses, such as 
> FQDN, where address type is non-obvious

HOW to define the address type in a candidate lite is for sure an SDP problem. But, the fact that the address type needs to be provided for a candidate is an ICE problem. 

It is very similar to the ICE option. RFC 8445 defines it in an abstract way, and ice-ice-sdp defines how to encode it in SIP/SDP.

> b. Specify that if agent compliant with ice-sip-sdp uses FQDN contact-address, it MUST specify addrtype for the candidate.

Do we know how an existing implementation would process the addrtype? Are there any procedures regarding unsupported candidate properties?

> c. Specify that if FQDN resolves to a single address for the specified family then that this address is used for this candidate. Candidate lines with 
> FQDN returning multiple results per query MUST be ignored until their handling is defined in a future draft
>
> d. Specify what to do with FQDN without address type specified such as SDP from legacy RFC 5245 implementations. We can go with try AAAA resolution 
> first and use if single address is returned. If nothing is returned from AAAA query, try A query. If single address is returned, used that address, ignore 
> the candidate line otherwise. This matches RFC 5245 language and should work in all the same situations where RFC 5245 implementations were working.

d) works assuming both ICE agents get the same IP address:port from DNS.

> What do you think?

I think you suggestion is good. But, as I have indicated, I would like to have a generic ICE FQDN draft that ice-sip-sdp (or a separate MMUSIC draft) references.

Similarly to ice-pac, I think such draft could be produced relatively fast. It more or less only needs to say that:

1) An ICE agent that uses FQDN needs to provide one candidate per address family, and indicate the addrtype for each of those candidates.
2) Some text regarding backward compatibility. Do we assume some default behavior by existing implementations, or do we require an ICE option?
 
Regards,

Christer