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

[Justin Uberti <[e-mail]>]

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

> 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 <[e-mail]> wrote:
>
>> 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
>>>
>> _______________________________________________
>> rtcweb mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
>