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

From: Roman Shpount <[email-masked]>
Date: Wed, 3 Apr 2019 12:46:59 -0400

Reposting er Flemming's advise as a new thread:

Hi All,

I have created a pull request to ice-sip-sdp (
https://github.com/suhasHere/ice-sip-sdp/pull/1), which among other things
added back support for FQDN to ice-sip-sdp.

In order to do this, I've done the following:

1. I have changed "IP address" to "connection address" throughout the
document whenever address in c= line or ICE candidate attribute is
mentioned. I hope this is not controversial since it matches ABNF.

2. I have changed the definition of <connection-address>

Old:

<connection-address>: :: is taken from RFC 4566 <<RFC4566>>.
It is the IP address of the candidate. When parsing this field, an agent
can differentiate
an IPv4 address and an IPv6 address by presence of a colon in its value --
the presence of
a colon indicates IPv6. An agent MUST ignore candidate lines that include
candidates with
IP address versions that are not supported or recognized.

New:

<connection-address>: :: is taken from RFC 4566 <<RFC4566>>.
It is the IP address of the candidate, allowing for IPv4 addresses, IPv6
addresses, and fully
qualified domain names (FQDNs).  When parsing this field, an agent can
differentiate
an IPv4 address and an IPv6 address by presence of a colon in its value -
the presence of a
colon indicates IPv6.  An agent MUST ignore candidate lines that include
candidates with
IP address versions that are not supported or recognized.  An IP address
SHOULD be used,
but an FQDN MAY be used in place of an IP address.  In that case, when
receiving an
offer or answer containing an FQDN in an a=candidate attribute, the FQDN is
looked up in
the DNS first using both AAAA record (assuming the agent supports IPv6),
and using an A
record (assuming the agent supports IPv4). If, and only if, the DNS query
returns
only one IP address it is then used for the remainder of ICE processing. If
DNS query
returned more then one result, including situation where single IPv4 and
single IPv6
results are returned, an agent MUST ignore the candidate. Handling of
multiple DNS
results for a candidate can be defined in the future specification. If
candidate
with FQDN <connection-address> is the default destination/candidate, the
the "c="
address type MUST be set the IP address family for the FQDN DNS resolution
result
and the "c=" connection address MUST be set to FQDN.

This change reflects what was discussed previously. I am, personally, less
then happy with this change. My biggest issue is requirement for FQDN to
resolve to a single address or be ignored. In practice, this is problematic
when things like DNS64/NAT64 are used. When DNS64 is used, even when FQDN
was supposed to only resolve to IPv4, AAAA will also return result which
will point to the NAT64 gateway. Based on the current language, this will
result in candidate being ignored even though it should work with either
IPv4 or IPv6 address. Most immediately, this will mean FQDN resolving to
IPv4 will be ignored on a lot of mobile networks.

I have also added language that defines what is supposed to be placed in c=
line when default candidate is an FQDN candidate. What happens when FQDN
resolution result and address family in c= line do not match was not
specified.

To summarize, this no worse then RFC 5245, but still fairly messy. I see
two possible ways to clean this up:

a. Add a candidate extension which specifies candidate address type,
something like addrtype which can be set to "inipv4" or "inipv6". If IP
address is used and it does not match the addrtype candidate extension,
this candidate is ignored. When FQDN is used, it is resolved using A DNS
request when addrtype is inipv4 or not present and using AAAA DNS request
when addrtype is inipv6. Address family in c= line, when FQDN is a default
candidate must be IN IPV4 if addrtype is inipv4 or not present, and must be
IP IPV6 if addrtype is inipv6

b. Specify that during ICE nomination all DNS resolution results for the
candidate should be added as separate candidates to the candidate list.
This is likely to cause more problems then option a. One of these problems
that I see is priority values for these candidates. Candidate priorities
should be different for all of them but only one value is specified in SDP
candidate attribute.

In order to simplify tracking changes, I will write different emails about
other changes I've done in the pull request.

I have also included people who shown previous interest in this topic.
Please let me know if I need to cross post to rtcweb and ice WG.

Thank you for your attention,
_____________
Roman Shpount

---

From: Suhas Nandakumar <[email-masked]>
Date: Tue, 9 Apr 2019 22:40:23 -0700

Hi Roman & Chairs

Thanks for the text

I feel we should restrict the scope for FQDN resolution to just one address
for this specification. Future specifications may define handling of
multiple resolutions (or  DNS64/NAT64 ) scenarios

If others are fine with this, I would want to get an updated draft and move
this forward

Please let  me know

Thanks
Suhas

On Wed, Apr 3, 2019 at 9:47 AM Roman Shpount <[email-masked]> wrote:

> https://github.com/suhasHere/ice-sip-sdp/pull/1), which among other
> things added back support for FQDN to ice-sip-sdp.
>
> offer or answer containing an FQDN in an a=candidate attribute, the FQDN
> is looked up in
> only one IP address it is then used for the remainder of ICE processing.
> If DNS query
> This change reflects what was discussed previously.. I am, personally,
> less then happy with this change. My biggest issue is requirement for FQDN
> to resolve to a single address or be ignored. In practice, this is
> problematic when things like DNS64/NAT64 are used. When DNS64 is used, even
> when FQDN was supposed to only resolve to IPv4, AAAA will also return
> result which will point to the NAT64 gateway. Based on the current
> language, this will result in candidate being ignored even though it should
> work with either IPv4 or IPv6 address. Most immediately, this will mean
> FQDN resolving to IPv4 will be ignored on a lot of mobile networks.
>
> I have also added language that defines what is supposed to be placed in
> c= line when default candidate is an FQDN candidate. What happens when FQDN
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 10 Apr 2019 14:23:51 -0400

Hi Suhas & Chairs,

Limiting FQDN scope to resolving to just one address is an unimplementable
requirement. Currently on large number of devices, FQDN which is supposed
to resolve to IPv4 address only, will resolve to both IPv6 and IPv4
addresses. For instance on virtually all IOS and most of the Android
devices on mobile networks FQDN pointing to IPv4 returns results for IPv6
as well. Essentially what we are specifying now is that ICE candidates with
FQDN address MUST be ignored.

I think if no feedback is provided regarding this issue this is exactly
what we should do in the specification and say something like:

FQDN or IP address versions that are not supported or recognized.  Handling
of FQDN addresses
in candidate can be defined in the future specification.

Regards,
_____________
Roman Shpount

On Wed, Apr 10, 2019 at 1:40 AM Suhas Nandakumar <[email-masked]>
wrote:

> Hi Roman & Chairs
>
> Thanks for the text
>
> I feel we should restrict the scope for FQDN resolution to just one
> address for this specification. Future specifications may define handling
> of multiple resolutions (or  DNS64/NAT64 ) scenarios
>
> If others are fine with this, I would want to get an updated draft and
> move this forward
>
>
> Please let  me know
>
> Thanks
> Suhas
>
>> an IPv4 address and an IPv6 address by presence of a colon in its value
>> -- the presence of
>> address type MUST be set the IP address family for the FQDN DNS
>> resolution result
>> In order to simplify tracking changes, I will write different emails
>> about other changes I've done in the pull request.
>>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 10 Apr 2019 19:13:13 +0000

Hi,

>Limiting FQDN scope to resolving to just one address is an unimplementable requirement. Currently on large number of devices, FQDN
>which is supposed to resolve to IPv4 address only, will resolve to both IPv6 and IPv4 addresses. For instance on virtually all IOS and most
>of the Android devices on mobile networks FQDN pointing to IPv4 returns results for IPv6 as well. Essentially what we are specifying now is
>that ICE candidates with FQDN address MUST be ignored.

Isn’t the main reason for allowing FQDN to enable usage of mDNS?

In my opinion, the current ICE procedures assumes one IP address:port per candidate. If we allow a candidate to be associated with multiple IP addresses:ports, we would have to modify the ICE procedures in order to handle that: how a candidate can be part of multiple foundations (one for each resolved IP address:port), how the freezing/unfreezing procedure work, whether connectivity checks are sent to all resolved addresses, how the state of the candidate is set if one IP address:port succeeds but another doesn’t. Or, should the candidate be split into multiple candidates (one for each resolved IP address:port)? Etc etc etc etc etc. All of that could probably be done, but I think it would be quite a bit of work- an update (or even a bis) to RFC 8445. It is *NOT* an ice-sip-sdp specific issue in my opinion.

Regards,

Christer

On Wed, Apr 10, 2019 at 1:40 AM Suhas Nandakumar <[email-masked]<mailto:[email-masked]>> wrote:
Hi Roman & Chairs

Thanks for the text

I feel we should restrict the scope for FQDN resolution to just one address for this specification. Future specifications may define handling of multiple resolutions (or  DNS64/NAT64 ) scenarios

If others are fine with this, I would want to get an updated draft and move this forward

Please let  me know

Thanks
Suhas

On Wed, Apr 3, 2019 at 9:47 AM Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
Reposting er Flemming's advise as a new thread:

Hi All,

I have created a pull request to ice-sip-sdp (https://github.com/suhasHere/ice-sip-sdp/pull/1), which among other things added back support for FQDN to ice-sip-sdp.

1. I have changed "IP address" to "connection address" throughout the document whenever address in c= line or ICE candidate attribute is mentioned. I hope this is not controversial since it matches ABNF.

Old:
<connection-address>: :: is taken from RFC 4566 <<RFC4566>>.
It is the IP address of the candidate. When parsing this field, an agent can differentiate
an IPv4 address and an IPv6 address by presence of a colon in its value -- the presence of
a colon indicates IPv6. An agent MUST ignore candidate lines that include candidates with
IP address versions that are not supported or recognized.

New:
<connection-address>: :: is taken from RFC 4566 <<RFC4566>>.
It is the IP address of the candidate, allowing for IPv4 addresses, IPv6 addresses, and fully
qualified domain names (FQDNs).  When parsing this field, an agent can differentiate
an IPv4 address and an IPv6 address by presence of a colon in its value - the presence of a
colon indicates IPv6.  An agent MUST ignore candidate lines that include candidates with
IP address versions that are not supported or recognized.  An IP address SHOULD be used,
but an FQDN MAY be used in place of an IP address.  In that case, when receiving an
offer or answer containing an FQDN in an a=candidate attribute, the FQDN is looked up in
the DNS first using both AAAA record (assuming the agent supports IPv6), and using an A
record (assuming the agent supports IPv4). If, and only if, the DNS query returns
only one IP address it is then used for the remainder of ICE processing. If DNS query
returned more then one result, including situation where single IPv4 and single IPv6
results are returned, an agent MUST ignore the candidate. Handling of multiple DNS
results for a candidate can be defined in the future specification. If candidate
with FQDN <connection-address> is the default destination/candidate, the the "c="
address type MUST be set the IP address family for the FQDN DNS resolution result
and the "c=" connection address MUST be set to FQDN.

This change reflects what was discussed previously.. I am, personally, less then happy with this change. My biggest issue is requirement for FQDN to resolve to a single address or be ignored. In practice, this is problematic when things like DNS64/NAT64 are used. When DNS64 is used, even when FQDN was supposed to only resolve to IPv4, AAAA will also return result which will point to the NAT64 gateway. Based on the current language, this will result in candidate being ignored even though it should work with either IPv4 or IPv6 address. Most immediately, this will mean FQDN resolving to IPv4 will be ignored on a lot of mobile networks.

I have also added language that defines what is supposed to be placed in c= line when default candidate is an FQDN candidate. What happens when FQDN resolution result and address family in c= line do not match was not specified.

To summarize, this no worse then RFC 5245, but still fairly messy. I see two possible ways to clean this up:

a. Add a candidate extension which specifies candidate address type, something like addrtype which can be set to "inipv4" or "inipv6". If IP address is used and it does not match the addrtype candidate extension, this candidate is ignored. When FQDN is used, it is resolved using A DNS request when addrtype is inipv4 or not present and using AAAA DNS request when addrtype is inipv6. Address family in c= line, when FQDN is a default candidate must be IN IPV4 if addrtype is inipv4 or not present, and must be IP IPV6 if addrtype is inipv6

b. Specify that during ICE nomination all DNS resolution results for the candidate should be added as separate candidates to the candidate list. This is likely to cause more problems then option a. One of these problems that I see is priority values for these candidates. Candidate priorities should be different for all of them but only one value is specified in SDP candidate attribute.

In order to simplify tracking changes, I will write different emails about other changes I've done in the pull request.

I have also included people who shown previous interest in this topic. Please let me know if I need to cross post to rtcweb and ice WG.

Thank you for your attention,
_____________
Roman Shpount
_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Roman Shpount <[email-masked]>
Date: Wed, 10 Apr 2019 15:35:49 -0400

On Wed, Apr 10, 2019 at 3:13 PM Christer Holmberg <
[email-masked]> wrote:

> >Limiting FQDN scope to resolving to just one address is an
> unimplementable requirement. Currently on large number of devices, FQDN
>
> >which is supposed to resolve to IPv4 address only, will resolve to both
> IPv6 and IPv4 addresses. For instance on virtually all IOS and most
> >of the Android devices on mobile networks FQDN pointing to IPv4 returns
> results for IPv6 as well. Essentially what we are specifying now is

 It is now. Nothing in the latest language that I propose prohibits mDNS
draft define how FQDN are supposed to work when mDNS is used. All my
language states that default treatment for FQDN is to ignore it which keeps
mDNS backwards compatible. I would also suggest adding an ICE option to
specify that mDNS is supported. This being said, I am not sure mDNS
prevents IPv4 address being resolved as IPv6 through DNS64, so mDNS is
likely going to end up with two addresses for a single candidate.

In my opinion, the current ICE procedures assumes one IP address:port per
> candidate. If we allow a candidate to be associated with multiple IP
> addresses:ports, we would have to modify the ICE procedures in order to
> handle that: how a candidate can be part of multiple foundations (one for
> each resolved IP address:port), how the freezing/unfreezing procedure work,
> whether connectivity checks are sent to all resolved addresses, how the
> state of the candidate is set if one IP address:port succeeds but another
> doesn’t. Or, should the candidate be split into multiple candidates (one
> for each resolved IP address:port)? Etc etc etc etc etc. All of that could
> probably be done, but I think it would be quite a bit of work- an update
> (or even a bis) to RFC 8445. It is **NOT** an ice-sip-sdp specific issue
> in my opinion.
>

I am not suggesting changing that only one address is supported per
candidate. What I am suggesting is that candidate needs some sort of hint
when FQDN is used to specify how address should be resolved. Here is my
proposed solution:

Add a candidate extension which specifies candidate address type, something
like addrtype which can be set to "inipv4" or "inipv6". If IP address is
used and it does not match the addrtype candidate extension, this candidate
is ignored. When FQDN is used, it is resolved using A DNS request when
addrtype is inipv4 or not present and using AAAA DNS request when addrtype
is inipv6. Address family in c= line, when FQDN is a default candidate must
be IN IPV4 if addrtype is inipv4 or not present, and must be IP IPV6 if
addrtype is inipv6

Example:
a=candidate:2319437384 1 udp 2122260223
8a2fd7b5-41d5-4c15-ad83-d33a0d66a75a.local
60454 typ host *inipv4*
a=candidate:2319437384 1 udp 2122260223
8a2fd7b5-41d5-4c15-ad83-d33a0d66a78b.local
60454 typ host *inipv6*

This keeps each candidate line to one address and works in cases when FQDN
resolves to one IPv4 and one IPv6 address due to something like DNS64.

Regards,
 _____________
Roman Shpount

---

From: Suhas Nandakumar <[email-masked]>
Date: Thu, 11 Apr 2019 01:03:17 -0700

On Wed, Apr 10, 2019 at 12:36 PM Roman Shpount <[email-masked]> wrote:

> Add a candidate extension which specifies candidate address type,
> a=candidate:2319437384 1 udp 2122260223 8a2fd7b5-41d5-4c15-ad83-d33a0d66a75a.local
> 60454 typ host *inipv4*
> a=candidate:2319437384 1 udp 2122260223 8a2fd7b5-41d5-4c15-ad83-d33a0d66a78b.local
> 60454 typ host *inipv6*
>
>
I am not for or against the proposal. I am sure its fine.  I am concerned
about the scope of this change and current implementations who are willing
to support this new extension. Why can't this be in a total new draft ?

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Apr 2019 08:05:54 +0000

Hi,

> It is now. Nothing in the latest language that I propose prohibits mDNS draft define how FQDN are supposed to 
> work when mDNS is used. All my language states that default treatment for FQDN is to ignore it which keeps 
> mDNS backwards compatible. I would also suggest adding an ICE > option to specify that mDNS is supported. 
> This being said, I am not sure mDNS prevents IPv4 address being resolved as IPv6 through DNS64, so mDNS is 
>> In my opinion, the current ICE procedures assumes one IP address:port per candidate. If we allow a candidate to 
>> be associated with multiple IP addresses:ports, we would have to modify the ICE procedures in order to handle 
>> that: how a candidate can be part of multiple foundations (one for each resolved IP address:port), how the 
>> freezing/unfreezing procedure work, whether connectivity checks are sent to all resolved addresses, how the 
>> state of the candidate is set if one IP address:port succeeds but another doesn’t. Or, should the candidate be 
>> split into multiple candidates (one for each resolved IP address:port)? Etc etc etc etc etc. All of that could probably 
>> be done, but I think it would be quite a bit of work- an update (or even a bis) to RFC 8445. It is *NOT* an ice-sip-sdp 
>> specific issue in my opinion.
>
> I am not suggesting changing that only one address is supported per candidate. What I am suggesting is that candidate 
> needs some sort of hint when FQDN is used to specify how address should be resolved. Here is my proposed solution:
>
> Add a candidate extension which specifies candidate address type, something like addrtype which can be set to 
> "inipv4" or "inipv6". If IP address is used and it does not match the addrtype candidate extension, this candidate is 
> ignored. When FQDN is used, it is resolved using A DNS request when addrtype is inipv4 or not present and using 
> AAAA DNS request when addrtype is inipv6. Address family in c= line, when FQDN is a default candidate must be 
> IN IPV4 if addrtype is inipv4 or not present, and must be IP IPV6 if addrtype is inipv6 
>
> Example:
> a=candidate:2319437384 1 udp 2122260223 8a2fd7b5-41d5-4c15-ad83-d33a0d66a75a.local 60454 typ host inipv4
> a=candidate:2319437384 1 udp 2122260223 8a2fd7b5-41d5-4c15-ad83-d33a0d66a78b.local 60454 typ host inipv6  
>
> This keeps each candidate line to one address and works in cases when FQDN resolves to one IPv4 and one IPv6 address 
> due to something like DNS64. 

So, if I understand you correctly, you are suggesting that the one providing the FQDN candidate splits it into two separate candidates (two a=candidate lines when SDP is used), and the remote peer will process them as two separate candidates, but if DNS returns both an IPv4 and IPv6 address the peer will only use the IP version indicated by the address type ("inipv4" or "inipv6").

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 11 Apr 2019 09:09:55 +0000

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?

Regards,

Christer

From: Suhas Nandakumar <[email-masked]>
Date: Thursday, 11 April 2019 at 11.03
To: Roman Shpount <[email-masked]>
Cc: Christer Holmberg <[email-masked]>, Suhas Nandakumar <[email-masked]>, "[email-masked]" <[email-masked]>, Flemming Andreasen <[email-masked]>
Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp

On Wed, Apr 10, 2019 at 12:36 PM Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:

 It is now. Nothing in the latest language that I propose prohibits mDNS draft define how FQDN are supposed to work when mDNS is used. All my language states that default treatment for FQDN is to ignore it which keeps mDNS backwards compatible. I would also suggest adding an ICE option to specify that mDNS is supported. This being said, I am not sure mDNS prevents IPv4 address being resolved as IPv6 through DNS64, so mDNS is likely going to end up with two addresses for a single candidate.

I am not suggesting changing that only one address is supported per candidate. What I am suggesting is that candidate needs some sort of hint when FQDN is used to specify how address should be resolved. Here is my proposed solution:

Add a candidate extension which specifies candidate address type, something like addrtype which can be set to "inipv4" or "inipv6". If IP address is used and it does not match the addrtype candidate extension, this candidate is ignored. When FQDN is used, it is resolved using A DNS request when addrtype is inipv4 or not present and using AAAA DNS request when addrtype is inipv6. Address family in c= line, when FQDN is a default candidate must be IN IPV4 if addrtype is inipv4 or not present, and must be IP IPV6 if addrtype is inipv6

Example:

I am not for or against the proposal. I am sure its fine.  I am concerned about the scope of this change and current implementations who are willing to support this new extension. Why can't this be in a total new draft ?

This keeps each candidate line to one address and works in cases when FQDN resolves to one IPv4 and one IPv6 address due to something like DNS64.

Regards,
 _____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 11 Apr 2019 17:29:53 -0400

On Thu, Apr 11, 2019 at 5:10 AM Christer Holmberg <
[email-masked]> 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).
>
>
>
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.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 11 Apr 2019 17:48:23 -0400

On Thu, Apr 11, 2019 at 4:05 AM Christer Holmberg <
[email-masked]> wrote:

> something like addrtype which can be set to
> > "inipv4" or "inipv6". If IP address is used and it does not match the
> addrtype candidate extension, this candidate is
> > ignored. When FQDN is used, it is resolved using A DNS request when
> addrtype is inipv4 or not present and using
> 8a2fd7b5-41d5-4c15-ad83-d33a0d66a75a.local 60454 typ host inipv4
> 8a2fd7b5-41d5-4c15-ad83-d33a0d66a78b.local 60454 typ host inipv6
> >
> > This keeps each candidate line to one address and works in cases when
> FQDN resolves to one IPv4 and one IPv6 address
> So, if I understand you correctly, you are suggesting that the one
> providing the FQDN candidate splits it into two separate candidates (two
> a=candidate lines when SDP is used), and the remote peer will process them
> as two separate candidates, but if DNS returns both an IPv4 and IPv6
> address the peer will only use the IP version indicated by the address type
> ("inipv4" or "inipv6").
>

I am suggesting that:

If agent is dual stack, it can include the same FQDN in two candidate lines
with different address types, effectively creating two candidates. If agent
is single stack or if FQDN is supposed to resolve to an address of specific
address family (different FQDN for IPv4 and IPv6), agent will create a
single candidate line with this FQDN and address family.

On the receiving side, if candidate includes addrtype inipv4, an A DNS
request is sent to resolve FQDN. If more then one result is returned, this
candidate is ignored. If single result is returned, it is an IPv4
candidate. If candidate includes addrtype inipv6, an AAAA DNS request is
sent to resolve FQDN.  If more then one result is returned, this candidate
is ignored. If single result is returned, it is an IPv6 candidate.

Corrected Example for a dual stack agent (note different foundation,
priority and port for two candidates with the same FQDN ):

 a=candidate:2 1 udp 2129033471 alice.comany.biz 60460 typ host addrype
inipv4
 a=candidate:1 1 udp 2129289471 alice.comany. biz 60454 typ host
addrype inipv6

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 12 Apr 2019 09:25:45 +0000

Hi,

>> So, if I understand you correctly, you are suggesting that the one providing the FQDN candidate splits it into two separate candidates (two a=candidate lines when SDP is used), and 
>> the remote peer will process them as two separate candidates, but if DNS returns both an IPv4 and IPv6 address the peer will only use the IP version indicated by the 
>> address type ("inipv4" or "inipv6").
>
> I am suggesting that:
> 
> If agent is dual stack, it can include the same FQDN in two candidate lines with different address types, effectively creating two candidates.

Correct, that's what I meant by "splitting the candidate".

> If agent is single stack or if FQDN is supposed to resolve to an address of specific address family (different FQDN for IPv4 and IPv6), agent will create a single candidate line with this FQDN and address family. 

Yes.

>On the receiving side, if candidate includes addrtype inipv4, an A DNS request is sent to resolve FQDN. If more then one result is returned, this >candidate is ignored. If single result is returned, it is an IPv4 candidate. If candidate includes addrtype inipv6, an AAAA DNS request is sent to >resolve FQDN.  If more then one result is returned, this candidate is ignored. If single result is returned, it is an IPv6 candidate.
>
>Corrected Example for a dual stack agent (note different foundation, priority and port for two candidates with the same FQDN ):
>
> a=candidate:2 1 udp 2129033471 http://alice.comany.biz 60460 typ host addrype inipv4
> a=candidate:1 1 udp 2129289471 alice.comany. biz 60454 typ host addrype inipv6    

Looks fine.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 12 Apr 2019 09:32:46 +0000

Hi,

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

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Fri, 12 Apr 2019 14:23:00 -0400

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

> >> I *think* I agree with Suhas that the FQDN handling should be a
> > 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:
> >
> > 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

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 14 Apr 2019 08:43:20 +0000

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

> 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

---

From: Roman Shpount <[email-masked]>
Date: Sun, 14 Apr 2019 18:12:54 -0400

Hi  Christer,

On Sun, Apr 14, 2019 at 4:43 AM Christer Holmberg <
[email-masked]> wrote:

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

I think the question is if FQDN is just another way to encode a single IP
address or if FQDN resolution affects ICE nomination process. If we decide
that demarcation point between ICE candidate signaling (ice-sip-sdp) and
ICE nomination i(RFC 8445) s the list of candidates with IP addresses, then
handling FQDN falls under signaling (ice-sip-sdp). If you think DNS
resolution affects ICE nomination process, then we will need a separate
draft for handling candidates with FQDN. I think former is the case and we
can put FQDN handling in ice-sip-sdp.

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

I do not think ice-sip-sdp needs to have ice-pac as dependency, but I am
going to bring this up in another thread. I wanted to concentrate on FQDN
first and then address other ice-sip-sdp issues, such as the fact that SDP
offer can contain an empty candidate list.

> 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, even though 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.
>

This is part of the problem with DNS. One agent can publish FQDN that
points to a single IP, but when another agent runs the DNS query, it can
return more then one result (such as DNS64), different result (some sort of
NAT or proxy) or no results. DNS network can be adversarial and
deliberately send traffic through a proxy for man-on-the-middle attack. I
would prefer to limit what we require to each of the agents and then allow
connectivity checks to sort this out. So far the requirements are that
agent that creates the candidate list should only use FQDN that points to
single address of given type and agent receiving the candidate list should
only use candidate lines that produce a single address.

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

As I have mentioned earlier, this is the question of defining
responsibilities of signaling vs actual ICE processing. DNS resolution does
not have to be part of ICE processing and can be part of signaling. ICE
processing can always start with the list of candidates with addresses
already resolved.

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

 Since I just invented addrtype, I do not think anything would process it.
Unsupported candidate properties are supposed to be ignored. We see a lot
of unsupported properties in the wild, such as "generation" and
"network-id". These extra candidate attributes do not seem to cause any
interop issues, so I do not think adding a new candidate type attribute
would be a problem

> with
> > 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
> ignore
> > the candidate line otherwise. This matches RFC 5245 language and should
> work in all the same situations where RFC 5245 implementations were working.
>

Option d  is best effort for interop with current RFC 5245 implementations.
It would work in the same cases when RFC 5245 implementation would. I am
not sure any current RFC 5245 implementations actually use FQDN, but if
such implementations do exist, this is what RFC 5245 specified.

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

I do not think we need an ICE option. I think presence of addrtype can be
sufficient.

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.

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?

Based on answers to these questions we can deiced how many additional
drafts we will need.

Regards,
______________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 15 Apr 2019 08:13:22 +0000

Hi,

>>> 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.
>>
> I think the question is if FQDN is just another way to encode a single IP address or if FQDN resolution affects ICE nomination process. 
> If we decide that demarcation point between ICE candidate signaling (ice-sip-sdp) and ICE nomination i(RFC 8445) s the list of candidates 
> with IP addresses, then handling FQDN falls under signaling (ice-sip-sdp). If you think DNS resolution affects ICE nomination process, then we will 
> need a separate draft for handling candidates with FQDN. I think former is the case and we can put FQDN handling in ice-sip-sdp.

Assuming the FQDN is split into separate candidates, and each candidate is processed just like any other candidate, I don't think the nomination process is affected. It also means that if I nominate the IPv6 "version" of a candidate, I am not allowed to switch to the IPv4 "version" - even if the connectivity checks have been successful. I am only allowed to use the transport associated with the nominated candidate.

>> 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).
> 
> I do not think ice-sip-sdp needs to have ice-pac as dependency, but I am going to bring this up in another thread. 
>
> I wanted to concentrate on FQDN first and then address other ice-sip-sdp issues, such as the fact that SDP offer can contain an empty candidate list.

Yes. I did not want to discuss ice-pac in this thread, but simply point out that because of it we MAY have a dependency already.

>> We also need to keep in mind that, even though 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.
>
> This is part of the problem with DNS. One agent can publish FQDN that points to a single IP, but when another agent runs the DNS query, 
> it can return more then one result (such as DNS64), different result (some sort of NAT or proxy) or no results.. DNS network can be adversarial 
> and deliberately send traffic through a proxy for man-on-the-middle attack. I would prefer to limit what we require to each of the agents and 
> then allow connectivity checks to sort this out. So far the requirements are that agent that creates the candidate list should only use FQDN that 
> points to single address of given type and agent receiving the candidate list should only use candidate lines that produce a single address.

Yes.

>> 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. 
> 
> As I have mentioned earlier, this is the question of defining responsibilities of signaling vs actual ICE processing. DNS resolution does not have to be part of ICE processing and can be part of signaling. ICE processing can always start with the list of candidates with addresses already resolved.

Yes.

> Since I just invented addrtype, I do not think anything would process it.

I was thinking about unsupported properties in general.

>>> Unsupported candidate properties are supposed to be ignored. We see a lot of unsupported properties in the wild, such as "generation" and "network-id". 
>>> These extra candidate attributes do not seem to cause any interop issues, so I do not think adding a new candidate type attribute would be a problem
>>>
> Option d  is best effort for interop with current RFC 5245 implementations. It would work in the same cases when RFC 5245 implementation would. I am not sure any current RFC 5245 implementations actually use FQDN, but if such implementations do exist, this is what RFC 5245 specified.
>
>>> What do you think?
>>
> 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.

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

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Tue, 16 Apr 2019 20:17:54 -0400

Hi,

On Mon, Apr 15, 2019 at 4:13 AM Christer Holmberg <
[email-masked]> 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?
> >
> 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.

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

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 18 Apr 2019 05:14:14 +0000

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 <[email-masked]>
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,

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.

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

---

From: Suhas Nandakumar <[email-masked]>
Date: Sun, 21 Apr 2019 13:24:30 -0700

Hi Roman

   Do you have an ETA on the pull request

Thanks
Suhas

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

> 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 <[email-masked]>
> *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,
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 22 Apr 2019 08:34:07 +0000

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 <[email-masked]>
Date: Sunday, 21 April 2019 at 23.24
To: Christer Holmberg <[email-masked]>
Cc: Flemming Andreasen <[email-masked]>, Roman Shpount <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [MMUSIC] FQDN support in ice-sip-sdp

Hi Roman

Thanks
Suhas

On Wed, Apr 17, 2019 at 10:14 PM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi Roman,

Regards,

Christer
From: Roman Shpount <[email-masked]<mailto:[email-masked]>>

Hi,

Regards,
______________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 25 Apr 2019 21:36:42 -0400

Simon Perreault advised to remove FQDN support from the definition of
connection-address. We are now trying to figure out a way to add FQDN
support back.
_____________
Roman Shpount

On Mon, Apr 22, 2019 at 4:34 AM Christer Holmberg <
[email-masked]> wrote:

>    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 <[email-masked]>
> *Date: *Sunday, 21 April 2019 at 23.24
> *To: *Christer Holmberg <[email-masked]>
> *Cc: *Flemming Andreasen <[email-masked]>, Roman Shpount <
> [email-masked]>, "[email-masked]" <[email-masked]>
> *Subject: *Re: [MMUSIC] FQDN support in ice-sip-sdp
>
>
>
> Hi Roman
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 26 Apr 2019 07:02:30 +0000

Hi,

>Simon Perreault advised to remove FQDN support from the definition of connection-address. We are now trying to figure out a way to add FQDN support back.
Perhaps the text should then say something like “for advising on usage of FQDN in the candidate-address”, or something like that. “Address selection” sounds confusing.

Regards,

Christer

_____________
Roman Shpount

On Mon, Apr 22, 2019 at 4:34 AM Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

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

Hi Roman

Thanks
Suhas

Regards,

Christer

Hi,

Regards,
______________
Roman Shpount