Experiencing What I Think Are Issues With The Confbridge ‘video_mode = Follow_talker’ And Also The Talk Detection

Home » Asterisk Users » Experiencing What I Think Are Issues With The Confbridge ‘video_mode = Follow_talker’ And Also The Talk Detection
Asterisk Users 1 Comment

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.

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: ^M
ConnectedLineNum: ^M
ConnectedLineName: ^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

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.

[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: ^M
ConnectedLineNum: ^M
ConnectedLineName: ^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

One thought on - Experiencing What I Think Are Issues With The Confbridge ‘video_mode = Follow_talker’ And Also The Talk Detection

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

    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.

    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:

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

    Thanks!