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

[Roman Shpount <[e-mail]>]

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 <[e-mail]> wrote:

> Roman Shpount <[e-mail]> 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
>