Everything works but not ConfBridge video Chrome to Firefox - 17.1.0

Asterisk Asterisk WebRTC
1

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

[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

exten => video_conference,1,Answer()
same => n,ConfBridge(guest)
same => n,Hangup()

pjsip.conf

[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?

2

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:

*CLI> rtp set debug on

To enable it. And then

*CLI> rtp set debug off

To turn it off again.

3

On Chrome, I get two m=video lines:

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:

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?

4

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, 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.

5

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!

6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.