Muted video element still produce audio when WebRTC call is on-HOLD
Reported by
alexande...@gmail.com,
Jun 2 2016
|
||||
Issue descriptionChrome Version : 51.0.2704.79 (Official Build) m (32-bit) What steps will reproduce the problem? (1) Establish WebRTC call between Google Chrome and FireFox 46.0.1 (2) In Chrome put call on-HOLD (3) Set "muted" attribute/property for 'video' element that displays remote video What is the expected result? Muted video element should not output audio What happens instead? I still hear audio from FireFox Please provide any additional information below. Looks like FireFox continues sending audio when Chrome put call on-HOLD (let's say it's bug of FireFox), but the main problem here is ignoring 'muted' property by Chrome. Chrome should not output audio even if it's received from FireFox when muted=true.
,
Jun 21 2016
hta: can you comment on this and/or reassign?
,
Jun 21 2016
Please define "In Chrome put call on-HOLD". This term has been used in a number of ways, with very different suggested API calls supporting it. How are you setting the "muted" attribute property for "video"? According to http://www.w3schools.com/tags/att_video_muted.asp the "muted" property has been around for a long time, so a bug here is a bit surprising. I've verified that in https://webrtc.github.io/samples/src/content/peerconnection/audio/ setting audio2.muted=true results in sound not being played any more; offhand, I couldn't find a demo using <video> that played back sound.
,
Jun 22 2016
Hi, Please use our client at https://testwebrtc.avistar.com/bug/ Fill form and register on any your SIP server and make call from Google Chrome to FireFox, press HOLD button in Chrome and you will got a problem. It's 100% reproducible.
,
Jun 23 2016
[triage]: https://testwebrtc.avistar.com/bug/ 404's for me. Is it enough to create a conference with your tool?
,
Jun 23 2016
[triage]: no, wait, it works now. I tried creating a room and joining from firefox and chrome, but the call doesn't go up. The last line in the js log is: | sip.transport | connecting to WebSocket wss://192.168.0.103:10443 That won't work for me since that wss is on a private ip address range, which means I can't see it from my machine even if you can. It will really be a lot easier for us if you write a smaller repro case that demonstrates the bug (in a single .html file preferably).
,
Jun 23 2016
Sorry, our admin just changed URL, please use https://testwebrtcg.avistar.com/bug/
,
Jun 23 2016
> | sip.transport | connecting to WebSocket wss://192.168.0.103:10443 Please fill all fields on start page (especially "WebSocket Server:"), and when you press "register" button default value will be changed to yours.
,
Jun 23 2016
The WebRTC test team doesn't have SIP servers. Please again - can you provide a shorter demo?
,
Jun 23 2016
I'll try to do something
,
Jul 11 2016
,
Aug 11 2016
alexander.kozlov.iv@ : Could you please update the thread providing the required info.
,
Sep 9 2016
alexander.kozlov.iv@: any update on a shorter demo that can be used to reproduce the behavior?
,
Oct 3 2016
Closing in lack of feedback. We need a more isolated reproduction case in order to proceed here. A fully-fledged complete application requiring additional servers is too much to ask from our side. |
||||
►
Sign in to add a comment |
||||
Comment 1 by cbiesin...@chromium.org
, Jun 16 2016