Can Asterisk notify conference room participants when party leaves?

Hello,

I have many SIP clients connected to a conference room using the ConfBridge app. I want each client’s interface to show and update the list of current participants. I could of course keep a list of all participants as they check in and out using another service on the server (by letting each client send a message when it enters or leaves the room). However, if a participant is suddenly disconnected, they won’t be able to notify the server in order to update the participants list. Now since Asterisk will know that the participant was disconnected, I was wondering if Asterisk could send a message to the other participants telling them that one party was disconnected so they can update their list. I am aware that Asterisk provides events via AMI which can be pulled at anytime but this would require setting up a timer to pull such events and update the conference participants list accordingly. If Asterisk itself could notify the remaining participants when someone leaves it would be much more efficient.

Thanks

There is no mechanism to communicate with a client and give them this information built in. There is also no need to poll over AMI for the information though. If a connection is kept up then events[1][2] will be sent when people join or leave the conference. You are then free to communicate with the client however you wish.

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+ManagerEvent_ConfbridgeJoin
[2] https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+ManagerEvent_ConfbridgeLeave

Then how would I update the live list of participants displayed on each client when one party is suddenly disconnected? Because at any time I want all parties to know who is still in the room, permanently and dynamically.

If using SIP then there are mechanisms to determine that the remote side has gone away. There is rtptimeout which hangs the call up if media is not received after a period of time, or session timers which periodically send a SIP request and if no response is received then hangs the call up. When that occurs you would get a leave event.

When the leave event occurs, is it possible to let Asterisk send a notification message somewhere to another server and/or to conference room participants? Like a push, you know. Or will I necessarily have to pull that information myself from another server or from my clients directly in order to update the participants list on the client UI?

Thanks

If you maintain a constant connection to the AMI interface then you will get the event. There is no push mechanism otherwise.

1 Like

Is it possible to select which type of events will be sent from Asterisk via AMI? I mean in case I am only interested in specific events, such as the leave event you mentioned? Thank you so much!

You can add filters programatically[1] or via configuration file[2].

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+ManagerAction_Filter
[2] https://github.com/asterisk/asterisk/blob/master/configs/samples/manager.conf.sample#L94

1 Like

Hi again,

I connected to AMI and whitelisted only Confbridge related events but I have an issue. If a participant is disconnected from the Internet, it takes nearly half an hour for the ConfbridgeLeave event to be fired. Meanwhile, Asterisk is still listing the channel as being in the conference. Worse, if the participant joins again, it will appear twice inside the room!

Is there any other event I could monitor via AMI to tell that a participant was disconnected? Or maybe I could shorten timeout settings to fire the ConfbridgeLeave event earlier?

Thanks

ConfBridge isn’t responsible for knowing if a participant is gone or not in case they disconnect. It’s up to the channel driver (like chan_sip or chan_pjsip) to detect this and hang the channel up. The options I previously mentioned are the ones available.

This means that ConfbridgeList is not reliable for my purpose. As I said, a disconnected participant is still being listed. Alright then, do you think the channel driver (which is chan_sip in my case) could detect the disconnection quickly enough? Is there a timeout setting to determine how fast a peer disconnection could be detected? What would be the related event fired through AMI? And is there any way I could explicitly cause the disconnected peer to be removed from the conference room?

My goal again is to show an as accurate as possible and dynamic conference participants list on all connected clients.

Thanks

I’d urge you to look at the documentation for the options I listed previously, read what they do, and configure them as you need. To everything it would be as if the channel was hung up by the participant.

I don’t see which options specifically you are referring to. So far you mentioned:

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+ManagerEvent_ConfbridgeJoin
[2] https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+ManagerEvent_ConfbridgeLeave
[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+ManagerAction_Filter1
[2] https://github.com/asterisk/asterisk/blob/master/configs/samples/manager.conf.sample#L942

Nothing in manager.conf settings seems to help me detect or report that a participant is disconnected. I will check the AMI events again…

I posted:

If using SIP then there are mechanisms to determine that the remote side has gone away. There is rtptimeout which hangs the call up if media is not received after a period of time, or session timers which periodically send a SIP request and if no response is received then hangs the call up. When that occurs you would get a leave event.

Here’s a link for chan_sip for rtptimeout[1] and session timers[2]. Similar ones exist for PJSIP.

[1] https://github.com/asterisk/asterisk/blob/master/configs/samples/sip.conf.sample#L640
[2] https://github.com/asterisk/asterisk/blob/master/configs/samples/sip.conf.sample#L655

1 Like

I didn’t notice that rtptimeout was a setting in sip.conf, my bad.
Setting rtptimeout to a low value solved the problem. The leave event is being fired as expected now.

Many thanks for your patience and support, really! :smiley: