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

[Suhas Nandakumar <[e-mail]>]

Hi Roman

   Do you have an ETA on the pull request

Thanks
Suhas

On Wed, Apr 17, 2019 at 10:14 PM Christer Holmberg <
[e-mail]> wrote:

> Hi Roman,
>
> I think a pull request would be good. Then we have text to look at - no
> matter where it will end up.
>
> I also suggest to try to keep the generic text separated from the SDP
> specifics, so it can easily be moved elsewhere if needed.
>
> Regarding agents that don’t understand the addrtype parameter, perhaps we
> could define a default IP version of an FDQN returns multiple (unless such
> default already exists somewhere)? It will of course not help with 5245
> implementations, but at least new implementations will have predicatable
> functionality.
>
> Regards,
>
> Christer
> ------------------------------
> *From:* Roman Shpount <[e-mail]>
> *Sent:* Wednesday, April 17, 2019 3:17:54 AM
> *To:* Christer Holmberg
> *Cc:* Flemming Andreasen; mmusic WG
> *Subject:* Re: [MMUSIC] FQDN support in ice-sip-sdp
>
> Hi,
>
> On Mon, Apr 15, 2019 at 4:13 AM Christer Holmberg <
> [e-mail]> wrote:
>
> >> 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?
> >
> > I do not think we need an ICE option. I think presence of addrtype can
> be sufficient.
>
> But if the peer ICE agent does not support it, and the FQDN resolves into
> both IPv4 and IPv6, we don't know what version it will use.
>
>
> I do not think adding ICE option will help. Unsupported ICE options are
> simply ignored so we end up not knowing what address remote agent is using.
> Unfortunately FQDN was not well defined in RFC 5245. "Fortunately" I have
> not seen anybody actually implementing FQDN In the worst case ICE
> nomination fails.  This is no different then having no connectivity for
> this specific candidate. Also, if FQDN handling is part of ice-sip-sdp,
> then agent should already include ice2 option.
>
> > This being said we need to decide two things:
> >
> > 1. Does FQDN resolution belongs to ICE processing? In this case
> candidate list includes FQDN with address type and ICE processing describes
> how FQDN are resolved and converted to addresses.
> > Or, alternatively, does FQDN resolution belongs to ICE signaling? In
> this case candidate list includes resolved address and ICE agent deals with
> addresses only.
>
> That would not work with mDNS, right?
>
> > 2. Do we specify how to deal with FQDN in ice-sip-sdp or do we specify
> in ice-sip-sdp that FQDN must be ignored and their handling is defined in
> some other draft?
>
> Perhaps the best thing would simply to produce a separate draft, to get
> some text. We can then decide whether to merge it into ice-sip-sdp.
>
>
> I can probably describe this in ice-sip-sdp in about 3 paragraphs. The
> background and other text for a new draft will make is much bigger effort.
> How about I put together a pull request for ice-sip-sdp and then we can
> decide if this requires a new draft?
>
> Regards,
> ______________
> Roman Shpount
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>