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

[Christer Holmberg <[e-mail]>]

Hi,

The draft contains the following text in the Acknowledgements section:

   “Thanks to Thomas Stach for text help, Roman Shpount for suggesting
   RTCP candidate handling and Simon Perreault for advising on IPV6
   address selection when candidate-address includes FQDN.”

I am not really sure what “advising on IPv6 address selection” means, and I can’t find any text in the draft that would be related to this.

Regards,

Christer

From: Suhas Nandakumar <[e-mail]>
Date: Sunday, 21 April 2019 at 23.24
To: Christer Holmberg <[e-mail]>
Cc: Flemming Andreasen <[e-mail]>, Roman Shpount <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp

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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/mmusic