Note : This has been an issue on the earlier version as well not specific to 58

Please include webrtc-internals graphs and logs for the audio channel.

Here are the Graph and wireshark traces

Deleted: Screen Shot 2017-05-12 at 3.34.21 PM.png 78.9 KB

	Screen Shot 2017-05-12 at 3.34.21 PM.png 78.9 KB View Download

Deleted: PSTN-May12.pcapng 7.5 MB

PSTN-May12.pcapng 7.5 MB Download

I couldnt get a test account for the above scenario . But this issues is similar to https://bugs.chromium.org/p/chromium/issues/detail?id=721597 . If the audio issue gets fixed for the above bug, PSTN should work fine.

Attaching event log and internals dump. Taylor, can you see why the audio connection isn't established? I see that we get packets with payload type 98 (Spark uses this one for Opus) in wireshark.

Deleted: event_log.24.1 516 KB

event_log.24.1 516 KB Download

Deleted: webrtc_internals_dump (4).txt 573 KB

webrtc_internals_dump (4).txt 573 KB View Download

It's actually that we send packets with payload type 98. We receive packets with payload type 111, which is correct since that's what's in the offer (for opus).

I'm not seeing any obvious clues as to what's going wrong, though I'm not used to debugging using RtcEventLogs. Could we get a native webrtc log, and/or could someone on the audio team take a look at the RtcEventLog?

Right, mixed up the payload types but it doesn't affect the results, attaching a chrome log with WebRTC native logging.

Deleted: chrome_debug.log 1.2 MB

chrome_debug.log 1.2 MB View Download

tlegrand, can someone in your team take a look?

I wouldn't expect Opus to be used in a call to PSTN. Is there some server that transcode the packets? What is sent on PT 98?

Assigning to Henrik to take a look at the attached event-log.

RTC Event logs can be analyzed with the rtp_analyzer.sh tool in native WebRTC.

$ out/Default/rtp_analyzer.sh event_log.24.1

Incoming:

0 0x3a4f9198 payload type(s): 100, 35.39% packets, 39.59% data
  packet sizes:
 31.0 - 246.8: 15.35%
 246.8 - 462.6: 10.40%
 462.6 - 678.4: 3.65%
 678.4 - 894.2: 4.83%
 894.2 - 1110.0: 65.77%
1 0x28b83e43 payload type(s): 111, 13.41% packets, 2.03% data
  packet sizes:
 66.0 - 84.2: 25.12%
 84.2 - 102.4: 3.38%
 102.4 - 120.6: 27.00%
 120.6 - 138.8: 36.19%
 138.8 - 157.0: 8.31%

Outgoing:

2 0x1a94d5d8 payload type(s): 108, 37.76% packets, 55.21% data
  packet sizes:
 45.0 - 276.0: 0.09%
 276.0 - 507.0: 0.00%
 507.0 - 738.0: 1.69%
 738.0 - 969.0: 9.95%
 969.0 - 1200.0: 88.28%
3 0xfc85a7fc payload type(s): 98, 13.43% packets, 3.17% data
  packet sizes:
 159.0 - 182.6: 99.38%
 182.6 - 206.2: 0.31%
 206.2 - 229.8: 0.12%
 229.8 - 253.4: 0.06%
 253.4 - 277.0: 0.12%


So we have incoming packets with PT 111, and outgoing with PT 98.

In the tool, you can chose one of the streams (0, 1, 2, 3) and get a bit more information about it, together with plots for actual bitrates and transport delay variations.

If you append --dump_header_to_stdout to the command line, you will get all RTP headers parsed and printed.

I cannot see any strange things in the RTC event log.

(Comment #15 was based on the event log in comment #9.)

Looking at the webrtc internals dump in comment #9, I see a strange thing. There are not media "graphs" for incoming streams, only for outgoing streams.

There are usually a number of metrics names ssrc_XX_send-* and ssrc_YY_recv-*, where XX and YY are decimal SSRCs. In the attached log I only see the send metrics, no receive metrics. I see no traces at all of 0x28b83e43 (683163203 decimal). It seems to me that the connection is broken, but I'm not the best to figure out why.

Taylor, does this give you any more insights?

Just some more printf debugging, ACM gets packets inserted, RecOut is called, AudioDecoderOpus::DecodeInternal gets called.

Extracted rtp (attached) plays fine with a ToT neteq_rtpplay.

Deleted: ios_Opus_decr.rtp 86.3 KB

ios_Opus_decr.rtp 86.3 KB Download

From the log:

"[1:87:0607/103706.268973:INFO:webrtcvoiceengine.cc(2020)] SetOutputVolume() to 0 for recv stream with ssrc 2935485648"

This indicates that the remote audio track is muted or disabled by the application. At lesat, that's the only thing I know that could cause this. Could someone on the Cisco side check if this is possible? If not, could I have a way to reproduce so I can dig further?

I can repro this and can share credentials if you want to. I met with cisco this morning and I've already asked them to double check the states at the JS level (since that seem like a more and more likely explanation). 

Not sure if this is the cause or a symptom, but if I call:

vids = document.getElementsByTagName('video');

vids[1] appear to be the remote feed, and it doesn't have any audioTrack. If I instead call from Android where video works there is an audiotrack for that video element.

Possibly related, I noticed this in the log:

[1:87:0607/103706.620221:INFO:webrtcvoiceengine.cc(2020)] SetOutputVolume() to 0 for recv stream with ssrc 2935485648
[1:86:0607/103706.668741:WARNING:statscollector.cc(973)] The SSRC 2935485648 is not associated with a receiving track

Taylor, can you explain the second log line?

The second log line is just because the old stats collector doesn't properly handle unsignaled SSRCs; it's expected in this case.

This problem is apparently linked to not being able to decode the video (https://bugs.chromium.org/p/chromium/issues/detail?id=721597). Taylor, would we somehow mute or disable the audio track just because the VideoTrack still is is in muted state? The video is in muted state since we can't decode any frames.

> Taylor, would we somehow mute or disable the audio track just because the VideoTrack still is is in muted state?

If something like that is happening, it would have to be caused by something at the chromium level; I'm not aware of anything in webrtc code that could cause that.

P.S.: Removing myself as owner since there's not much more I can do without a way to reproduce.

Yeah something must be happening at the Chrome level. webrtc_audio_device_impl in chromium is receiving valid audio, and it's being passed on to one sink.

Niklas, if I can repro this it would simplify. Is that possible? Is this a Mac only problem?

I'll email you instructions.

I could repro and when we get data from WebRTC to Chrome[1] we get only zeros. I also saw that we do receive data on the network, according to webrtc-internals.

Assigning to Fredrik for looking into WebRTC.

[1] https://cs.chromium.org/chromium/src/content/renderer/media/webrtc_audio_device_impl.cc?l=103

Really? I added a   
fwrite(audio_data,sizeof(int16_t),frames_per_10_ms*audio_bus->channels(),fid); 

after PullRenderData and I get perfect audio in the recording, but nothing is played. 

Yes, exactly that outputs a file with only zeros for me. I'm on Linux and Chrome 61.0.3136.0.

It sounds like there may be two issues surfacing here. Can you please try to figure out in what way(s) your testing differs?

I'm doing a call between the app on an iPhone and the web client on Linux on Chrome 61.0.3138.0 release build. This patch[1] applied and --no-sandbox flag. It doesn't matter who initiates the call.

What did you test Niklas?

[1] https://chromium-review.googlesource.com/c/543476/

Pretty much the same thing, added the line in #33 plus a hacky global FILE* = fopen... declaration, initiated the call from Chrome on a build that was ToT maybe 2 weeks ago. I didn't disable the sandbox since that wasn't needed for some reason.

On Linux as well? Maybe you could test again with your patch and mine and tot? I could also test with your patch. I wonder if no-sandbox would affect this.

OK, I've figure out why we saw different results. Based on #23 I hardcoded  WebRtcVoiceMediaChannel::SetOutputVolume to always set the volume to 1.0. That didn't have any effect so I forgot about it but moved on. Without that tweak we only get silence from the audio device (what grunell@ observed) - but with that tweak the audio is still muted at the Chrome level later on(!?).

If you're using latest ToT the repro method has changed a bit since we have fixed the iOS video problem, and this issue only applies to voice-only calls. Call from Chrome and have the screen locked on the iPhone. Answer the call with the slider on iOS and you'll get a voice-only call.

OK, I can repro the same hard-coding the volume to 1.0. I tracked backwards why the volume is set to 0, and found that the audio track isn't playing. This is because the remote stream contains a video track, so a video renderer (and an audio renderer) is created in [1], and video frames are expected; that would have started playing the track[2]. In for example appr.tc in audio only mode, there's no video renderer is created for the remote stream which starts playing the audio track, see end of [1].

I'm not sure if this is expected behavior for the case.

* Are you using autoplay on the video tag?
* As a test, could you try starting playing explicitly instead?
* Do you know why the stream would contain a video track when it's an audio only call?

CC Guido who maybe knows streams and tracks better.

[1] https://cs.chromium.org/chromium/src/content/renderer/media/webmediaplayer_ms.cc?l=217
[2] https://cs.chromium.org/chromium/src/content/renderer/media/webmediaplayer_ms.cc?l=655

arungane: can you please answer my questions in comment #40?

It seems to me that this is the same as  bug 403710 , where the audio track in a stream that also contains a remote video track is not played until the first video frame is decoded. This leads to problems with remote streams that are supposed to send a video track but don't send it.

We landed a patch once to work around this, but had to revert it (see https://codereview.chromium.org/2138813002/) because the spec for the video element says the metadata must be known before starting to play. For the video track the metadata (i.e., resolution) is not known until the first frame is decoded.

Yes, it sure does. Thanks Guido. So this works as intended and the solution is that the user makes sure the stream only contains audio track(s), right?

Correct.

There is one bug in Chrome, though. If the stream is assigned to an audio element, waiting for video metadata is not required by the spec, but Chrome behaves the same way as for video elements (i.e., waits for the first video frame).

I see, thanks. Do you know if we have a bug filed for that? Does that spec accept assigning a stream with video track(s) to an audio tag?

arungane: this works as intended and you have to make sure the stream doesn't contain any video tracks.

I'll close this bug in a while if nothing else comes up.

I just filed  bug 738379  for the audio-element issue.