# Everything works but not ConfBridge video Chrome to Firefox - 17.1.0 **URL:** \ **Category:** Asterisk WebRTC\ **Created:** [January 22, 2020, 1:56pm UTC](https://community.asterisk.org/t/everything-works-but-not-confbridge-video-chrome-to-firefox-17-1-0/82400 "2020-01-22T13:56:43Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![deltahoney](https://avatars.discourse-cdn.com/v4/letter/d/7ab992/32.png) [@deltahoney](https://community.asterisk.org/u/deltahoney)\ **Post date:** [January 22, 2020, 1:56pm UTC](https://community.asterisk.org/t/everything-works-but-not-confbridge-video-chrome-to-firefox-17-1-0/82400/1 "2020-01-22T13:56:43Z")
I am having this issue using Cyber Mega Phone 2k on a Confbridge, calling the endpoint `video_conference` as configured below. When there are only Chrome or Safari participants, everything is ok. When there are only Firefox participants, everything is ok. If webkit (Chrome or Safari) and Firefox users are mixed, everything looks fine on the webkit browser, while Firefox is stuck on “waiting for video”. The issue happens only when using ConfBridge. Calling between Firefox and webkit works fine, StreamEcho works fine (well, of course). I am using Asterisk 17.1.0 on Ubuntu 18.04.3 and running tests with all peers from localhost, on a Mac. I am using a stun server but not a turn. confbridge.conf ```auto [general] [default_bridge] type=bridge video_mode=sfu [default_user] type=user music_on_hold_when_empty=yes music_on_hold_class=default dsp_drop_silence=yes denoise=yes ``` extensions.conf ```auto exten => video_conference,1,Answer() same => n,ConfBridge(guest) same => n,Hangup() ``` pjsip.conf ```auto [guest] type=endpoint context=default direct_media=no allow=!all,opus,ulaw,vp8,h264 aors=guest max_audio_streams=30 max_video_streams=30 webrtc=yes dtls_auto_generate_cert=yes ``` Am I doing something wrong or is this an Asterisk issue? ---
**Author:** ![kharwell](https://sea1.discourse-cdn.com/asterisk/user_avatar/community.asterisk.org/kharwell/32/1924_2.png) [@kharwell](https://community.asterisk.org/u/kharwell)\ **Post date:** [January 23, 2020, 12:13am UTC](https://community.asterisk.org/t/everything-works-but-not-confbridge-video-chrome-to-firefox-17-1-0/82400/2 "2020-01-23T00:13:49Z")
I used the configuration given here, and initially did receive the "waiting for video” message, but after a period of time it went away and video was as expected. Check the SDP’s and make sure the audio/video addresses and ports are what you’d expect. You can then double check and make sure Asterisk is sending and receiving to/from those addresses/ports with the correct audio/video codecs using rtp debugging: ```auto *CLI> rtp set debug on ``` To enable it. And then ```auto *CLI> rtp set debug off ``` To turn it off again. ---
**Author:** ![deltahoney](https://avatars.discourse-cdn.com/v4/letter/d/7ab992/32.png) [@deltahoney](https://community.asterisk.org/u/deltahoney)\ **Post date:** [January 23, 2020, 9:03am UTC](https://community.asterisk.org/t/everything-works-but-not-confbridge-video-chrome-to-firefox-17-1-0/82400/3 "2020-01-23T09:03:28Z")
On Chrome, I get two `m=video` lines: ```auto m=video 64201 UDP/TLS/RTP/SAVPF 102 96 c=IN IP4 192.168.1.110 m=video 9 UDP/TLS/RTP/SAVPF 102 96 c=IN IP4 0.0.0.0 ``` On Firefox: ```auto m=video 9 UDP/TLS/RTP/SAVPF 126 120 c=IN IP4 0.0.0.0 m=video 9 UDP/TLS/RTP/SAVPF 120 c=IN IP4 0.0.0.0 ``` rtp debug shows packets but on different ports. To add more details, I installed Asterisk from source code, enabling codec opus (which works). Then I ran both `make samples` and `make config`. Do you think this is an Asterisk configuration issue or a routing issue? ---
**Author:** ![deltahoney](https://avatars.discourse-cdn.com/v4/letter/d/7ab992/32.png) [@deltahoney](https://community.asterisk.org/u/deltahoney)\ **Post date:** [January 23, 2020, 9:27am UTC](https://community.asterisk.org/t/everything-works-but-not-confbridge-video-chrome-to-firefox-17-1-0/82400/4 "2020-01-23T09:27:03Z")
Update: removing h264 from allowed codecs solved the issue. I am still investigating why. Interestingly, the `m=video` lines are still the same and the rtp debug is still the same. I found this on an [MDN page](https://developer.mozilla.org/en-US/docs/Web/Media/Formats/WebRTC_codecs#supported-foot-1), it may be a hint, although I am on a Mac: > Firefox for Android 68 and later do not support AVC (H.264) anymore. This is due to a change in Google Play store requirements that prevent Firefox from downloading and installing the OpenH264 codec needed to handle H.264 in WebRTC connections. ---
**Author:** ![deltahoney](https://avatars.discourse-cdn.com/v4/letter/d/7ab992/32.png) [@deltahoney](https://community.asterisk.org/u/deltahoney)\ **Post date:** [January 23, 2020, 9:44am UTC](https://community.asterisk.org/t/everything-works-but-not-confbridge-video-chrome-to-firefox-17-1-0/82400/5 "2020-01-23T09:44:38Z")
I personally checked and there is the Cisco H.264 plugin enabled in Firefox by default, can’t find the same for Chrome (remember: on a Mac). I have no idea why H.264 doesn’t work in this case, but I am removing it anyway: I need to support Firefox for Android too. Thank you for your response @kharwell, have a nice day! ---
**Author:** ![system](https://global.discourse-cdn.com/asterisk/original/2X/4/475d0c889911cfb84ac4881ad6df8b523e3f9105.png) [@system](https://community.asterisk.org/u/system)\ **Post date:** [February 22, 2020, 9:44am UTC](https://community.asterisk.org/t/everything-works-but-not-confbridge-video-chrome-to-firefox-17-1-0/82400/6 "2020-02-22T09:44:42Z")
Closed on February 22, 2020, 9:44am UTC This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.