[asterisk-users] Experiencing what I think are issues with the confbridge 'video_mode = follow_talker' and also the talk detection

[Kevin Harwell]

On Wed, Mar 13, 2019 at 1:24 PM Dan Cropp <dan at amtelco.com> wrote:

> Running a test using asterisk 16.1.1 and two PCs with Firefox browsers.
> I’m running the cmp2k demo.
>
>
>
> I place calls into the same asterisk and using AMI answer the calls and
> then add them into the same confbridge.
>
> Video mode is configured to follow_talker.  However, the Remote Video
> displayed to both browsers is always the video of the opposite call.  It’s
> not following whoever talked last.  I have the talk_detection_events
> enabled and looking at the event it seems asterisk isn’t always detecting
> the talking correctly.
>

If Asterisk is not always detecting the talking then it might be that you
need to adjust the dsp_talking_threshold and/or dsp_silence_threshold
settings. I'm not sure why the video is not switching unless it's the same
thing as the other problem you ran into and the browsers aren't handling
the streams swapping.


>
>
> Next question….
>
>
>
> If asterisk is reporting channel PJSIP/webrtc_client1-0000000e is talking,
> shouldn’t the confbridge follow_talker setting change this confbridge
> VideoSource to be the Uniqueid of this channel?
>
>
>
> Event: ConfbridgeTalking^M
>
> Privilege: call,all^M
>
> Conference: Bridge2^M
>
> BridgeUniqueid: ea6e7cb6-cc86-413e-885c-b0a25be887ee^M
>
> BridgeType: base^M
>
> BridgeTechnology: softmix^M
>
> BridgeCreator: ConfBridge^M
>
> BridgeName: Bridge2^M
>
> BridgeNumChannels: 3^M
>
> BridgeVideoSourceMode: talker^M
>
> BridgeVideoSource: 1552492132.33^M
>
> Channel: PJSIP/webrtc_client1-0000000e^M
>
> ChannelState: 6^M
>
> ChannelStateDesc: Up^M
>
> CallerIDNum: webrtc_client1^M
>
> CallerIDName: <unknown>^M
>
> ConnectedLineNum: <unknown>^M
>
> ConnectedLineName: <unknown>^M
>
> Language: en^M
>
> AccountCode: 19^M
>
> Context: ABC^M
>
> Exten: 55555^M
>
> Priority: 14^M
>
> Uniqueid: 1552492117.32^M
>
> Linkedid: 1552492117.32^M
>
> TalkingStatus: on^M
>
> Admin: No^M
>

While the follow_talker setting initiates the "switching" process I'd
expect most of the time the Id's to be different here. When talking is
detected, and when this event is dispatched can differ from when the video
source actually changes. When the video source changes you should see a
BridgeVideoSourceUpdate event. I'd suspect that usually it'd follow the
ConfbridgeTalking event in most cases.



> Last question….
>
>
>
> I see times where it seems the talk detection seems to become stuck for a
> channel.  I see this event happening and the confbridge videosource becomes
> this channel’s uniqueid.  I have not talked into this PC/browser’s mic in
> hours.  Literally went to lunch and it seems stuck in the TalkingStatus: on
> state.
>
> I have hundreds of ConfbridgeTalking events for the other channel (on and
> off) over the next several hours, but that channel’s TalkingStatus seems
> stuck.
>

I am unsure what could cause this unless there is some kind of ambient
noise that is being detected and your thresholds need to be adjusted.
Otherwise it sounds like a bug to me. If this is happening consistently and
your settings seem good then I'd suggest opening a ticket on the issue
tracker [1]. Please attach (as *.txt files) a full asterisk debug log [2]
(debug and verbose set to at least 5, and sip/pjsip debugging), along with
the AMI log, and relevant configurations.


[03/13 10:49:00.595] DEBUG[49360] manager.c: Examining AMI event:
>
> Event: ConfbridgeTalking^M
>
> Privilege: call,all^M
>
> Conference: OpBridge2^M
>
> BridgeUniqueid: ea6e7cb6-cc86-413e-885c-b0a25be887ee^M
>
> BridgeType: base^M
>
> BridgeTechnology: softmix^M
>
> BridgeCreator: ConfBridge^M
>
> BridgeName: OpBridge2^M
>
> BridgeNumChannels: 2^M
>
> BridgeVideoSourceMode: talker^M
>
> BridgeVideoSource: 1552492132.33^M
>
> Channel: PJSIP/webrtc_client1-0000000f^M
>
> ChannelState: 6^M
>
> ChannelStateDesc: Up^M
>
> CallerIDNum: webrtc_client1^M
>
> CallerIDName: <unknown>^M
>
> ConnectedLineNum: <unknown>^M
>
> ConnectedLineName: <unknown>^M
>
> Language: en^M
>
> AccountCode: 19^M
>
> Context: ABC^M
>
> Exten: 4444^M
>
> Priority: 14^M
>
> Uniqueid: 1552492132.33^M
>
> Linkedid: 1552492132.33^M
>
> TalkingStatus: on^M
>
> Admin: No^M
>
>
>
>
>
> The templates I’m using are
>
>
>
> Action: SetVar
>
> ActionID: C173
>
> Channel: PJSIP/webrtc_client1-0000000f
>
> Variable: CONFBRIDGE(bridge,template)
>
> Value: 2
>
>
>
> Action: SetVar
>
> ActionID: C174
>
> Channel: PJSIP/webrtc_client1-0000000f
>
> Variable: CONFBRIDGE(user,template)
>
> Value: 4
>
>
>
> Action: SetVar
>
> ActionID: C176
>
> Channel: PJSIP/webrtc_client1-0000000e
>
> Variable: CONFBRIDGE(bridge,template)
>
> Value: 2
>
>
>
> Action: SetVar
>
> ActionID: C177
>
> Channel: PJSIP/webrtc_client1-0000000e
>
> Variable: CONFBRIDGE(user,template)
>
> Value: 4
>
>
>
> [2]
>
> type = bridge
>
> language = en
>
> internal_sample_rate = 0
>
> mixing_interval = 20
>
> record_file_append = no
>
> max_members = 10
>
> video_mode = follow_talker
>
>
>
> [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
> --
>
>

[1] https://issues.asterisk.org/
[2] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

Thanks!

-- 
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/c871a12a/attachment.html>