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

[Roman Shpount <[e-mail]>]

On Fri, Apr 12, 2019 at 5:32 AM Christer Holmberg <
[e-mail]> wrote:

> >> 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=candidiate
> 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 somehwhere, 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.

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. Figuring out how to handle multiple
results per DNS query certainly warrants a separate draft and should be out
of scope.

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

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

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.

What do you think?
_____________
Roman Shpount