Subject: Re: [rtcweb] [MMUSIC] What goes into c= line address when FQDN is used for the default candidate?

From: Roman Shpount <[email-masked]>
Date: Thu, 31 Jan 2019 22:14:11 -0500

Hi Dale,

This is exactly what I've thought. I have added RtcWeb group to the email,
since they have a draft which describes using MDNS
candidates: rtcweb-mdns-ice-candidates (
https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-02). This
draft talks about replacing host candidates addresses with MDNS FQDN. What
it does not talk about is what ends up in c=/m= line in this case. In the
currently Chrome MDNS experiment, Chrome produces something like this:

v=0
o=- 5433632304511147701 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE audio
a=msid-semantic: WMS 6bb347f4-f699-4522-99ea-215c10022f50
m=audio 59372 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
*c=IN IP6*
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:1962264367 1 udp 2122260223
3557773f-5f01-46a4-aa14-54ab35b3d778.local 59372 typ host generation 0
network-id 1 network-cost 10
a=candidate:980827103 1 tcp 1518280447
3557773f-5f01-46a4-aa14-54ab35b3d778.local 9 typ host tcptype active
generation 0 network-id 1 network-cost 10
a=ice-ufrag:3iia
a=ice-pwd:HMo0mGLq8nYb9pfnG/nH3pNI
a=ice-options:trickle
a=fingerprint:sha-256
8D:22:EF:E4:8B:7F:B3:F0:69:2E:B2:1D:4B:F1:6F:DE:62:BE:B8:DC:92:A3:F7:E5:1B:E8:87:6D:BE:E2:44:48
a=setup:actpass
a=mid:audio
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=sendrecv
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
a=ssrc:4224017887 cname:aHDhJbcPUEXkWfRL
a=ssrc:4224017887 msid:6bb347f4-f699-4522-99ea-215c10022f50
ffd9edfb-e99c-4cc3-a1dd-817f0327d021
a=ssrc:4224017887 mslabel:6bb347f4-f699-4522-99ea-215c10022f50
a=ssrc:4224017887 label:ffd9edfb-e99c-4cc3-a1dd-817f0327d021

As you can see c= line is "c=IN IP6" and is missing the contact address,
which so far breaks every client except Chrome, including Firefox.

I was curious what should go into the c= line and if this would work
anywhere, or if this is completely misguided

Regards,
_____________
Roman Shpount

On Thu, Jan 31, 2019 at 9:48 PM Dale R. Worley <[email-masked]> wrote:

> Roman Shpount <[email-masked]> writes:
> > I wanted to see if it was ever decided if c= line should contain IN IP4
> or
> > IN IP6 when default ICE candidate address contains FQDN.
> >
> > For instance, in the following SDP:
> >
> > m=audio 59372 UDP/TLS/RTP/SAVPF 0
> > *c=IN IP6 3557773f-5f01-46a4-aa14-54ab35b3d778.local *
> > a=rtcp:9 IN IP4 0.0.0.0
> > a=candidate:1962264367 1 udp 2122260223
> > 3557773f-5f01-46a4-aa14-54ab35b3d778.local 59372 typ host
> > a=ice-ufrag:3iia
> > a=ice-pwd:HMo0mGLq8nYb9pfnG/nH3pNI
> > a=rtcp-mux
> >
> > Is it correct to use "c=IN IP6
> 3557773f-5f01-46a4-aa14-54ab35b3d778.local "
> > or should it be "c=IN IP4 3557773f-5f01-46a4-aa14-54ab35b3d778.local"?
>
> In regard to ICE *candidates*, RFC 8445 makes it clear that a candidate
> is an IP address, not an FQDN:
>
>    2.1.  Gathering Candidates
>
>    In order to execute ICE, an ICE agent identifies and gathers one or
>    more address candidates.  A candidate has a transport address -- a
>    combination of IP address and port for a particular transport
>    protocol (with only UDP specified here).  There are different types
>    of candidates; some are derived from physical or logical network
>    interfaces, and others are discoverable via STUN and TURN.
>
> The discussion of "default candidates" is a little vague due to the fact
> that the ICE specification factors out ICE from any protocol that uses
> it, but the default candidate is always a *candidate* and thus an
> address, not an FQDN:
>
>    5.2.  Lite Implementation Procedures
>
>    Next, an agent chooses a default candidate for each component of each
>    data stream.  If a host is IPv4 only, there would only be one
>    candidate for each component of each data stream; therefore, that
>    candidate is the default.  If a host is IPv6 only, the default
>    candidate would typically be a globally scoped IPv6 address.  Dual-
>    stack hosts SHOULD allow configuration whether IPv4 or IPv6 is used
>    for the default candidate, and the configuration needs to be based on
>    which one its administrator believes has a higher chance of success
>    in the current network environment.
>
>
>    5.3.  Exchanging Candidate Information
>
>    The using protocol may (or may not) need to deal with backwards
>    compatibility with older implementations that do not support ICE.  If
>    a fallback mechanism to non-ICE is supported and is being used, then
>    presumably the using protocol provides a way of conveying the default
>    candidate (its IP address and port) in addition to the ICE
>    parameters.
>
> Dale
>

---

From: Justin Uberti <[email-masked]>
Date: Thu, 31 Jan 2019 19:56:52 -0800

I looked into this before and it's pretty clear that ICE candidate and c=
line can both contain FQDN.

On Thu, Jan 31, 2019 at 7:14 PM Roman Shpount <[email-masked]> wrote:

> https://tools.ietf.org/html/draft-ietf-rtcweb-mdns-ice-candidates-02).
> This draft talks about replacing host candidates addresses with MDNS FQDN.
> What it does not talk about is what ends up in c=/m= line in this case. In
> the currently Chrome MDNS experiment, Chrome produces something like this:
>
> v=0
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
>

---

From: Justin Uberti <[email-masked]>
Date: Thu, 31 Jan 2019 19:57:59 -0800

We can however all agree that "c=IN IP6" is busted:
https://bugs.chromium.org/p/chromium/issues/detail?id=927309

On Thu, Jan 31, 2019 at 7:56 PM Justin Uberti <[email-masked]> wrote:

>> This is exactly what I've thought. I have added RtcWeb group to the
>> email, since they have a draft which describes using MDNS
>>> > I wanted to see if it was ever decided if c= line should contain IN
>>> IP4 or

---

From: Roman Shpount <[email-masked]>
Date: Thu, 31 Jan 2019 23:43:13 -0500

> https://bugs.chromium.org/p/chromium/issues/detail?id=927309
I guess one way to interpret this that each address should have a MDNS
alias. So, if you are dealing with dual stack host, it should provide two
MDNS candidates, one of which is IPv4 and another IPv6. The c= line should
specify FQDN for one of those candidates and specify the type (IP4 or IP6).

There are two problems:

1. There is no way to know which address type is in the candidate-address
when FQDN is used there. Guidance in ice-sip-sdp is talking about the
presence of column in IP6 address, but this definitely does not apply to
FQDN. It would've been better to specify something like local4 and local6
as FQDN suffix in MDNS alias to specify the candidate-address type so that
correct DNS request can be issued.

2. A lot (if not most) SDP/ICE implementations do no support parsing FQDN
in candidate-address or c= line. This might create interop problems since
RFC 5245 specified that candidate-address is an IP Address.

Regards,
_____________
Roman Shpount

---

From: Justin Uberti <[email-masked]>
Date: Thu, 31 Jan 2019 21:02:00 -0800

My recommendation here would be that we do c=IN IP6
3557773f-5f01-46a4-aa14-54ab35b3d778.local, with either IP4 or IP6
depending on which type of address is being wrapped.

Re #1: RFC 4566 seems to indicate you can use either IP4 or IP6 for FQDN in
the c= line.

     unicast-address =     IP4-address / IP6-address / FQDN / extn-addr

Re #2: Quoth 5245 <https://tools.ietf.org/html/rfc5245#section-15.1>:

   <connection-address>:  is taken from RFC 4566
<https://tools.ietf.org/html/rfc4566> [RFC4566
<https://tools.ietf.org/html/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 an AAAA record
      (assuming the agent supports IPv6), and if no result is found or
      the agent only supports IPv4, using an A.  If the DNS query
      returns more than one IP address, one is chosen, and then used for
      the remainder of ICE processing.