asterisk users - Mar 2019 - Does anyone know if there is a problem with the Chrome browser and asterisk cmp2k video

Using asterisk 16.1.1.

I'm setting up a test using the cmp2k (Cyber Mega Phone 2K Ultimate Dynamic
Edition).

I have noticed Chrome 72 had some issues with video streams.  I just upgraded to
Chrome 73 and see they still have some issues.  If I have 2 calls in a
confbridge with video set to none.  I then set the video source to a Chrome
browser and the Remote Video shown to both calls from Firefox and Chrome do not
update.  However, if I set the video source to the Firefox browser, my Remote
Video is accurate in both Firefox and Chrome.
I confirmed that asterisk is indicating the video source changed by looking at
the AMI BridgeVideoSourceUpdate event.

When I use the Firefox (65.0.2) browser I can set either call to be the video
source and the Remote Video updates accordingly.

Is this caused by Chrome's video sent to asterisk being some format which
asterisk can't use in the confbridge?  The endpoints for both Firefox and
Chrome calls are set to
disallow = all
allow = opus,ulaw,vp9,vp8,h264

Both calls use the same bridge and user settings.

[3]
type = bridge
language = en
internal_sample_rate = 0
mixing_interval = 20
record_file_append = no
max_members = 10
video_mode = none

[4]
type = user
admin = no
marked = no
startmuted = no
music_on_hold_when_empty = no
quiet = yes
wait_marked = no
end_marked = no
dsp_drop_silence = yes
dsp_silence_threshold = 2500
dsp_talking_threshold = 160
denoise = no
jitterbuffer = yes
talk_detection_events = yes
dtmf_passthrough = no
announce_user_count = no
announce_join_leave = no
announce_user_count_all = no
announce_only_user = no
send_events = no
echo_events = no
announce_join_leave_review = no

Have a great day!

Dan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20190313/557c5507/attachment.html>

On Wed, Mar 13, 2019 at 10:15 AM Dan Cropp <dan at amtelco.com> wrote:
> Using asterisk 16.1.1.
>
>
>
> I’m setting up a test using the cmp2k (Cyber Mega Phone 2K Ultimate
> Dynamic Edition).
>
>
>
> I have noticed Chrome 72 had some issues with video streams.  I just
> upgraded to Chrome 73 and see they still have some issues.  If I have 2
> calls in a confbridge with video set to none.  I then set the video source
> to a Chrome browser and the Remote Video shown to both calls from Firefox
> and Chrome do not update.  However, if I set the video source to the
> Firefox browser, my Remote Video is accurate in both Firefox and Chrome.
>
> I confirmed that asterisk is indicating the video source changed by
> looking at the AMI BridgeVideoSourceUpdate event.
>
>
>
> When I use the Firefox (65.0.2) browser I can set either call to be the
> video source and the Remote Video updates accordingly.
>
>
>
> Is this caused by Chrome’s video sent to asterisk being some format which
> asterisk can’t use in the confbridge?
>
The way I understand it is that video stream has changed, so the browser
needs some way to know that. Otherwise the decoder thinks it's invalid data
and drops it. In these cases either Asterisk needs to issue a renegotiation
(currently not supported), or the codec needs to contain video stream
information in their payload. I spoke with Joshua Colp about this some as
he's had some dealings with this and he had the following to say:

"Some codecs (such as VP8/V9) embed information about the video stream
within their payload. Asterisk does not currently rewrite this information,
so when a stream change occurs in Asterisk using the selective source
functionality this can cause the receiving side (the browser) to drop the
payload as it sees it as not being part of the existing stream. Different
browsers can behave differently, such as resetting the video decoder to handle
the new stream. Rewriting this information in the video payload is not
currently supported."

So you are probably seeing it work or not in Chrome vs Firefox due to
browser, and codec support of such occurrences.

   .... <snip config> ....


-- 
Kevin Harwell
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: https://digium.com & https://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20190314/6584faab/attachment.html>

Thank you Kevin.

Any idea if Google developers may decide to reset the decoder, per Joshua’s
experience?
Or perhaps asterisk developers would consider eventually add the rewrite support
in asterisk?

Always fun dealing with newer technology as it goes through several revisions.

Have a great day!

Dan

From: asterisk-users <asterisk-users-bounces at lists.digium.com> On
Behalf Of Kevin Harwell
Sent: Thursday, March 14, 2019 4:50 PM
To: Asterisk Users Mailing List - Non-Commercial Discussion <asterisk-users
at lists.digium.com>
Subject: Re: [asterisk-users] Does anyone know if there is a problem with the
Chrome browser and asterisk cmp2k video

On Wed, Mar 13, 2019 at 10:15 AM Dan Cropp <dan at amtelco.com<mailto:dan
at amtelco.com>> wrote:
Using asterisk 16.1.1.

I’m setting up a test using the cmp2k (Cyber Mega Phone 2K Ultimate Dynamic
Edition).

I have noticed Chrome 72 had some issues with video streams.  I just upgraded to
Chrome 73 and see they still have some issues.  If I have 2 calls in a
confbridge with video set to none.  I then set the video source to a Chrome
browser and the Remote Video shown to both calls from Firefox and Chrome do not
update.  However, if I set the video source to the Firefox browser, my Remote
Video is accurate in both Firefox and Chrome.
I confirmed that asterisk is indicating the video source changed by looking at
the AMI BridgeVideoSourceUpdate event.

When I use the Firefox (65.0.2) browser I can set either call to be the video
source and the Remote Video updates accordingly.

Is this caused by Chrome’s video sent to asterisk being some format which
asterisk can’t use in the confbridge?

The way I understand it is that video stream has changed, so the browser needs
some way to know that. Otherwise the decoder thinks it's invalid data and
drops it. In these cases either Asterisk needs to issue a renegotiation
(currently not supported), or the codec needs to contain video stream
information in their payload. I spoke with Joshua Colp about this some as
he's had some dealings with this and he had the following to say:

"Some codecs (such as VP8/V9) embed information about the video stream
within their payload. Asterisk does not currently rewrite this information, so
when a stream change occurs in Asterisk using the selective source functionality
this can cause the receiving side (the browser) to drop the payload as it sees
it as not being part of the existing stream. Different browsers can behave
differently, such as resetting the video decoder to handle the new stream.
Rewriting this information in the video payload is not currently
supported."

So you are probably seeing it work or not in Chrome vs Firefox due to browser,
and codec support of such occurrences.

   .... <snip config> ....

--
Kevin Harwell
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: https://digium.com & https://asterisk.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.digium.com/pipermail/asterisk-users/attachments/20190315/8d2bf107/attachment.html>