Webrtc : No sound during call from Chrome

RESOLVED FIXED

Status

()

Core
WebRTC: Audio/Video
P1
normal
Rank:
15
RESOLVED FIXED
2 years ago
2 years ago

People

(Reporter: Sergio, Assigned: drno)

Tracking

44 Branch
x86_64
Windows 7
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

2 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.116 Safari/537.36

Steps to reproduce:

I open a webrtc session call between Chrome and Firefox. Chrome as presenter and firefox as viewer.
Firefox version 44.
Crome version 48


Actual results:

In a WebrTC session between Chrome as presenter and Firefox 44 as viewer, Firefox can't reproduce the audio stream. In the Firefox tab it appears the speaker icon but not sound is played. If you duplicate the tab in Firefox with the same url and make again the call (without closing the first tab), then the audio works properly. It seems that Firefox doesn't  connect properly  to the device that plays the audio in the system.


Expected results:

In a webrtc call between Chrome as presenter and Firefox viewer audio and video must be played.
(Reporter)

Updated

2 years ago
Severity: normal → critical
OS: Unspecified → Windows 7
Hardware: Unspecified → x86_64
Summary: Webrtc : Chrome → Webrtc : No sound during call from Chrome

Updated

2 years ago
Severity: critical → normal
Component: Untriaged → WebRTC: Audio/Video
Product: Firefox → Core
Where are you seeing this?  Can you reproduce this with talky.io or apprtc?  

If you can reproduce or give us a URL where we can try it that would help.  Otherwise logs as discussed here will help:
https://wiki.mozilla.org/Media/WebRTC/Logging
Flags: needinfo?(sergio.puertas)

Comment 2

2 years ago
Hello everybody,
the problem was discovered using the demo one2may of Kurento Media Server (but not with a room, the loopback demo, etc.). You can see the related issue here: https://github.com/Kurento/bugtracker/issues/38

The one2many demo has the next logic:
 - The "one" negotiates with KMS in sendonly mode.
 - The "viewers" negotiate with KMS in **recvonly** mode (NOTE recvonly)

We have tested this demo in this way:
 1 - Add the "one" in Chrome, or in Firefox in the PC-A
 2 - Open a **new instance** of Firefox in the PC-B (NOTE new instance)
    2.1 - The OS of PC-B must be Windows or MAC-OSX, in Ubuntu it works fine.
 3 - Create the first tab in Firefox(PC-B) and add a "viewer" (The audio is not listened)
    3.1 - In about:webrtc we can see that packets are received in "inbound_rtp_audio_0", so audio arrives.
 4 - Create a second tab in Firefox(PC-B) and add a "viewer" (The audio is listened in this viewer and in the first one)

So, in conclusion, audio is not listed in the first tab of Firefox receiving from Chrome or another Firefox in another PC.

Could be a bug in Firefox when the PeerConnection is negotiated in recvonly mode in Windows or MAC-OSX?

Best!!
Odd... logs would help a ton, see comment 1
Flags: needinfo?(sergio.puertas) → needinfo?(mparisdiaz)
(Assignee)

Comment 4

2 years ago
The logs from comment 1 would be awesome. A little bit easier to get would be a copy of 'about:webrtc' after the first tab failed to play back the audio and another refreshed/reloaded snapshot of 'about:webrtc' after it started playing in the second tab.

Comment 5

2 years ago
Hello @randell and @nils,
we have a public demo here: https://kurento.lab.fiware.org:8083, so you can test the related issue by yourself.
For this, follow these steps:
 1 - Go to https://kurento.lab.fiware.org:8083 with Chrome.
 2 - Press "Presenter" button
 3 - Go to https://kurento.lab.fiware.org:8083 with a new instance of Firefox (previously, close all opened Firefox windows)
 4 - Press "Viewer" button. You will hear nothing
 5 - Go to https://kurento.lab.fiware.org:8083 in another Firefox tab
 6 - Press "Viewer" button. You will hear the audio in the first and in the second tabs.


If you need more info, please, let me know ;).
Flags: needinfo?(mparisdiaz)
(Assignee)

Updated

2 years ago
Assignee: nobody → drno
(P1 - Rank:15 to investigate what's going on.)
Status: UNCONFIRMED → NEW
backlog: --- → webrtc/webaudio+
Rank: 15
Ever confirmed: true
Priority: -- → P1
(Assignee)

Comment 7

2 years ago
I was able to follow steps 1, 2 and 3, but when I click on 4 I get an error message from the server:
  "Call not accepted for the following reason: No active sender now. Become sender or . Try again later ..."
I get this error message in Chrome as well as in Firefox. Can you please clarify what I need to do to watch the stream from the presenter? :-)
Flags: needinfo?(mparisdiaz)

Comment 8

2 years ago
Hello Nils,
it seems that the demo is in an inconsistent state.
I haven't could contact with the demo maintainer yet, but it seems that you can check it doing steps 1 and 2 in a Firefox browser in a different PC that the Firefox of steps 3, 4, 5 and 6.
Do you have the possibility of doing it in this way? (remember that the "viewer" must be in Windows or in MAC-OSX)

Sorry for the inconveniences.
Flags: needinfo?(mparisdiaz)
(Assignee)

Comment 9

2 years ago
(In reply to mparisdiaz from comment #8)
> Sorry for the inconveniences.

No worries. With two different machines I'm sometimes able to start seeing and hearing something.

Unfortunately I'm not able to reproduce the issue so far. I tried a wild mix of Linux, Windows and Mac. I tried Chrome as sender and receiver. I tried Firefox 44, 45 and 47 as receiver and presenter. The result is either:
A) The viewer is able to see AND hear the presenter
B) The viewer doesn't see or hear anything
  B.1) Either because the server claims there is currently no presenter (which is not true - I guess some state information on the server side gets confused)
  B.2) When presenting from Firefox on Windows to Chrome on Mac, Chrome failed to establish the ICE connection, apparently because it never received the server reflexive candidates from the server side

A couple of observations/questions:
1) The demo server is running on a private IP address behind a NAT. Not ideal (see above for the Chrome ICE failure, because of server issues).
2) Have you tried using Firefox Nightly instead of 44?
3) Which version of Windows are you using?
4) I noticed that the server always answers for the audio m section with two audio codecs: Opus and PCMU. My educated guess is that this is potentially causing the problem. What is the reason for answering with two audio codecs instead of one?
5) As I'm still not able to reproduce the problem could you check with wireshark what payload type the audio packets from the server to Firefox have in case you don't hear anything?
Flags: needinfo?(mparisdiaz)
(Reporter)

Comment 10

2 years ago
It seems that the problem is solved in Firefox 45!
(Assignee)

Comment 11

2 years ago
Great. Thanks for testing it with a more recent version!
I'm going to close this. If it should not be fixed feel free to re-open this ticket.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → FIXED

Comment 12

2 years ago
To complete the info,
in my case using MAC-OSX El Capitan (version 10.11.3) in a MacBook Pro for the Viewer in the first tab of a new instance of Firefox:
 - Fails with Firefox 44
 - Works with Firefox 45

So, I agree with moving this issue to FIXED ;).
Flags: needinfo?(mparisdiaz)
You need to log in before you can comment on or make changes to this bug.