I have the same issue when using Andriod > 5.0.1 and Chrome browser.

guidou: is this your area or grunell's? 

Assigning to grunell@. Please triage further if necessary.

Verified on test page in the report. Same for http://appr.tc. (Volume buttons/rocker controls phone notification volume.) Just as a reference, in the audio tag demo at HTML5Tutorials one can adjust the media volume.

Henrik A: do you perhaps have any experience in Android apps and how they control the usage of the phone volume buttons, i.e. what type of audio volume the buttons control. Specifically for Chrome. I'm looking for some pointers.

Tried it as well and some sort of regression has happened. Have not done work in this area for a long time but the audio mode is not correct and I know for sure that it has not always been like this. The volume icon during a call indicates that the audio mode is set to RING mode and the active stream requires COMM mode to follow the volume changes done by the user.

I recommend that you check why

https://cs.chromium.org/chromium/src/media/base/android/java/src/org/chromium/media/AudioManagerAndroid.java?sq=package:chromium&l=374

is not called any longer. Adding braveyao@ since he has done work in this area recently.

The audio mode is still set accordingly. The problem is AudioManager.OnAudioFocusChangeListener. It seems its behavior might change in latest OS.
The test with a appr.tc loopback call shows:
When the call is setup, we request audio focus and set audio mode with COMM.
At meantime, we get a unexpected onAudioFocusChange callback with mode AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK. Here we restore the audio mode saved. Oops
Then when we start play something at a Youtube page or with PlayMusic app, we get an expected onAudioFocusChange callback with mode AUDIOFOCUS_LOSS.
And things get worse onward, when we switch between the apprtc page and other page/app playing different audio, there is no more onAudioFocusChange callback.

Things were different when I firstly added the request-audioFocus for https://bugs.chromium.org/p/chromium/issues/detail?id=525597. 

Any idea?

BTW: FireFox on my Nexus5(M) can't adjust call volume.

I can't say for sure what has happened in here but it does feel like a regression. Assigning to braveyao@ for further investigation and changes.

 Issue 652259  has been merged into this issue.

Brave: one recommendation is to change AUDIOFOCUS_GAIN to AUDIOFOCUS_GAIN_TRANSIENT. My work with other applications shows that it is a more suitable mode for a VoIP application. 

Thanks Brave, I trust you can resolve it. Do you know if it is a change in Chrome or a change in Android that has triggered the new notification?

Android stops notifying audioFocusChange after losing the GAIN since L. So the previous implementation for crbug/525597 worked on JellyBean and Kitkat, not on L/M/N.
And the unexpected AUDIOFOCUS_LOSS_TRANSIENT_CAN_DUCK right after audio focus requesting even exists in J&K. I wonder why I didn't see it at implementing the callback last year...

I'm contacting Android guys to see if such a change is on purpose. 

See if you can come up with a simpler solution that does not rely on any notification at all. Would that be possible?

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/03623e2394747cac121f6c7d4dc011e0418e2b64

commit 03623e2394747cac121f6c7d4dc011e0418e2b64
Author: braveyao <braveyao@chromium.org>
Date: Thu Oct 20 17:23:22 2016

AudioManagerAndroid: remove audio focus request and saved audio mode

We used to request audio focus in AndioManagerAndroid and save/restore
the audio mode. Both are not necessary now.

The newly added MediaSessionDelegate will take care of audio focus.
And it's more resonable to switch back to NORMAL since we can't know
that the saved mode is still valid. This will be handled by Android
audio frame.

BUG= 650533 

Review-Url: https://chromiumcodereview.appspot.com/2437963002
Cr-Commit-Position: refs/heads/master@{#426519}

[modify] https://crrev.com/03623e2394747cac121f6c7d4dc011e0418e2b64/media/base/android/java/src/org/chromium/media/AudioManagerAndroid.java

I am observing the audio routing of webrtc call is changed once it received a cellular call. {WebRTC Audio started playing in earpiece after attending and ending the Cellular call.}

Is this fix will resolve the above issue as well?

And which WebView version it will be available.

That sounds like a different issue (or feature request) and should be filed separately.

[bulk-edit : please ignore if not applicable]

Could you please set the correct milestone for this issue?

Verified in M56 in Pixel XL using the test page https://webrtc.github.io/samples/src/content/devices/input-output/ and AppRTC call https://appr.tc/ - adjusting the volume of the active WebRTC call using the rocker, takes effect

Nexus 5x, chrome 54 or chrome 56 beta volume control not take effect

It's still doesn't work on my Nexus 5 and chome 54.0.2840.85
Also I tried use chrome beta 56.0.2924.23 - works realy strange: volume controls "phone call talking volume", so I can decrise volume, but can't increase it.

Re #25: it is intended behavior that a WebRTC client will affect the "phone call" volume since it is a VoIP client working in communication mode.

The fix landed in 56.0.2897.0 and is not included in 54.