New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 718741 link

Starred by 5 users

Issue metadata

Status: Assigned
Owner:
Last visit > 30 days ago
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

Failed to receive audio on WebRTC call with iOS device

Reported by vkravche...@intersog.com, May 5 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.133 Safari/537.36

Steps to reproduce the problem:
1. Initialize call from Chrome (using JsSIP library);
2. Pick up call with audio on iOS device (using Kamailio and CallKit API);
3. Attach remote stream to audio or video element;

What is the expected behavior?
Audio from iOS should be present;

What went wrong?
There is no audio from iOS device;

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 57.0.2987.133  Channel: stable
OS Version: OS X 10.12.4
Flash Version: Shockwave Flash 25.0 r0

Also this issue can be replicated on Windows machine.
It works in Mozilla Firefox ver. 51 as expected.

Please let me know if you need something else.
 
chrome_debug.log
1.1 MB View Download
Components: -Blink>WebRTC Blink>WebRTC>Audio

Comment 2 by ossu@chromium.org, May 11 2017

Just to clarify: is the problem that the audio from Chrome is not being played out on the iOS device, or that the audio recorded by the iOS device is not getting played out in Chrome?
The second one - audio captured on iOS device is not getting played in Chrome.

Comment 4 by ossu@chromium.org, May 11 2017

Owner: deadbeef@chromium.org
Status: Available (was: Unconfirmed)
Alright, thanks! In the logs, I see the following:

[45101:33415:0505/113823.762688:INFO:audio_receive_stream.cc(77)] AudioReceiveStream: {rtp: {remote_ssrc: 1928111853, local_ssrc: 3010997905, transport_cc: off, nack: {rtp_history_ms: 0}, extensions: [{uri: urn:ietf:params:rtp-hdrext:ssrc-audio-level, id: 1}]}, rtcp_send_transport: (Transport), voe_channel_id: 1, sync_group: default}
...
[45101:33415:0505/113823.762779:INFO:channel.cc(1371)] Add remote ssrc: 1928111853
[45101:33415:0505/113823.762792:INFO:channel.cc(1707)] Changing voice state, recv=1 send=0
...
[45101:33415:0505/113823.930112:VERBOSE1:webrtcvoiceengine.cc(2678)] WebRtcVoiceMediaChannel::SetRawAudioSink: ssrc:1928111853 (ptr)
[45101:33415:0505/113823.930280:INFO:webrtcvoiceengine.cc(2435)] SetOutputVolume() to 1 for recv stream with ssrc 1928111853
...
[45101:33415:0505/113823.989349:INFO:webrtcvoiceengine.cc(2435)] SetOutputVolume() to 0 for recv stream with ssrc 1928111853

So, it looks like the received stream has its volume set to zero, for some reason. It looks like the silence is caused by signalling, rather than some I/O problems on recording or playback.

Assigning to deadbeef@ for now. Any ideas what could cause this to happen?
Labels: Needs-Feedback
The only way this can happen, as far as I know, is if the application disables or mutes the received track. vkravchenko@, is there any way this could be happening?
I don't think it does because as I mentioned in issue description I tested the same application in Firefox browser, and it works as expected.
Status: Assigned (was: Available)
What's the status? Can we move forward with this?
A couple possibly-related bugs: the <video> tag will not start playing audio until video metadata is learned: https://bugs.chromium.org/p/chromium/issues/detail?id=403710

And the <audio> tag used to behave the same way: https://bugs.chromium.org/p/chromium/issues/detail?id=738379

Could that be what was going on?

Sign in to add a comment