Hello, may I please have Feedback, if and when I can expect a solution, so I can give the Information to our customer. Thanks. 

is the other side tha does not receive the audio stream a server? Providing a dump from chrome://webrtc-internals might be very helpful in triaging this further.

Could you attach a Chrome debug log? See https://webrtc.org/native-code/logging/

FYI, the microphone permission makes a difference because it allows WebRTC to use all network interfaces, rather than binding a socket to "0.0.0.0" and using whatever interface the OS selects.

With that in mind, a couple questions:

* When you say "caused by virtual machine", do you mean you're running from within a virtual machine, or just in the presence of one?
* How is the set of candidates different when mic permission is granted? Is it strictly larger? Or is it missing a candidate that was gathered before?

Hi:

We are also hitting a similar issue with our chrome based WebRTC client. Here are the details:

- As specified by the original reporter of this bug, whenever we force the browser to ask for microphone permission (by cleaning the content settings for the microphone) there is no problem.
- Whenever the previous microphone permission is retained and used, we are getting into the ICE failure issue.

Other Information:

- We are setting up 4 RTP sessions(audio/video) one after the other. When it's working fine, it sets up all the 4 RTP sessions fine.
- When it's not working, the ICE failure occurs with only one of the RTP session.
- When split the audio and video streams into separate RTP sessions, then the failure rate is very minimum.
- This ICE failure occurs only in few of our systems. Not sure about the system specification - like the one the original reporter reported with multiple NIC.

Attachments:

1. Chrome webrtc logs capture for a non-working case.
2. Chrome webrtc logs capture for a working case for reference.

Deleted: Appshare_Issue_WOCC_With_Original_Files.txt 47.7 KB

Appshare_Issue_WOCC_With_Original_Files.txt 47.7 KB View Download

Deleted: Appshare_Issue_WCC_With_Original_Files.txt 46.7 KB

Appshare_Issue_WCC_With_Original_Files.txt 46.7 KB View Download

* When you say "caused by virtual machine", do you mean you're running from within a virtual machine, or just in the presence of one?
** Our application is not running inside a virtual machine, but a VM may be present and the host machine.

* How is the set of candidates different when mic permission is granted? Is it strictly larger? Or is it missing a candidate that was gathered before?
** When mic permission is granted we gather more candidates than before.

Thanks for the additional information. However, the files attached don't contain any WebRTC log messages; did you launch a fresh instance of Chrome with the command line arguments to enable logging? If successful you should see messages that include "Gathered candidate" (among others).

By the way, an idea that philipp.hancke@ had: this could occur if the remote endpoint doesn't implement "aggressive nomination", which Chromium uses. It attempts to nominate every candidate pair (rather than only one), expecting that the remote endpoint will select the one with the highest priority, rather than simply the first one nominated.

Sorry, I have attached the wrong log files(our WebRTC client application). Here are the chrome webrtc log files - for the non-working and the working one.

-KMurali

Deleted: chrome_debug_without_cache_cleared.log 1.3 MB

chrome_debug_without_cache_cleared.log 1.3 MB View Download

Deleted: chrome_debug_with_cache_cleared.log 1.4 MB

chrome_debug_with_cache_cleared.log 1.4 MB View Download

Both logs show candidates only gathered from one interface, and both get connected (DTLS handshake completes successfully). And afterwards, there's no transition to the ICE failed (or disconnected) state. Are you sure these are the right logs?

To the question of Philipp Hancke: The remote endpoint is a server currently only supporting ice-lite. But shouldn’t connection establishment still work with ice-lite? We receive a success response to the stun binding request only for the “right” candidate (not for the vm-nic-candidate). This “right” candidate also appears in the candidates in the sdp answer that is sent to the server.
Does this mean that the server nominated the wrong candidate? (cf. rfc5245 7.2.2)

this sounds like an issue with the server, not chrome (even though using aggressive nomiation is probably the cause).
The easiest way to determine that might be a pcap from the server showing the stun packets and the rtp packets.

No feedback was received in the last 30 days from the reporter, so archiving this issue. Please re-open or file a new bug if necessary.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot