ice connect fails when web have only one candidate including mdns addr。

[firechickrsx]

I am poor in English so I try hard to say something bug's condition: 1.Using new browser version which support mDns . MAC + chorme 79. 2.Only one candidate is created by web.

my advice: Use a fack ip instead in sdp will fix this problem, but it is not a good idea. In sdp.c .Don't abort the candidate when mDns check fail.continue to start ice comunicate.

[lminiero]

We already discussed in the past, and we decided we'd never inject a fake candidate ourselves: we wouldn't know in advance the kind of network Janus would be in, and so we'd risk injecting unwarranted traffic if the fake address matched the private network. If you need this, you can have your application inject fake candidates programmatically.

That said, you should never need it, since pretty much always users will use STUN as well to gather candidates, so srflx candidates would do the job there. Closing.

[firechickrsx]

Maybe we can just wait for connection's coming and not take the initiative to connect. Ice-pwd will ensure our safety. My application is too simple to discard stun server and replay server. In any case,Thank you so much,You are my God!

------------------ 原始邮件 ------------------ 发件人: "Lorenzo Miniero"<notifications@github.com>; 发送时间: 2020年2月24日(星期一) 晚上9:45 收件人: "meetecho/janus-gateway"<janus-gateway@noreply.github.com>; 抄送: "空转流明"<4248012@qq.com>; "Author"<author@noreply.github.com>; 主题: Re: [meetecho/janus-gateway] ice connect fails when web have only one candidate including mdns addr。 (#1960)

We already discussed in the past, and we decided we'd never inject a fake candidate ourselves: we wouldn't know in advance the kind of network Janus would be in, and so we'd risk injecting unwarranted traffic if the fake address matched the private network. If you need this, you can have your application inject fake candidates programmatically.

That said, you should never need it, since pretty much always users will use STUN as well to gather candidates, so srflx candidates would do the job there. Closing.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or unsubscribe.