Hi Duvid
Thanks for your suggestion, yes, that is one way of achieving it.
However, our application layer is currently stateless.
This allows us to have mulitple instances of it for HA, and also avoids any issues with stale state.
We currently implement some custom features which do require holding conference state, and we are storing this on FreeSWITCH in the call sessions associated with the conference, which is obviously not ideal and becoming unwieldy as we develop more features.
Therefore being able to store state on the conference object would be really helpful to us.
Regards
Phil





From: Duvid Rottenberg <adrottenberg@gmail.com>
Subject: Re: [Freeswitch-users] Custom variables for mod_conference
Date: 28 May 2014 16:15:36 BST
To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org>
Reply-To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org>


I have some similar features, and I accomplish that by storing the Conference-Unique-ID in my application and use that as a key to store the state in my application instead of in Freeswitch.

Duvid Rottenberg 


On Wed, May 28, 2014 at 5:03 AM, Phil Dunks <phil.dunks@netdev.co.uk> wrote:

Hi Michael

Thanks for looking at this - I have submitted a patch in FS-6559.

Let me explain the reason that the feature would be useful to us.

We have an application layer that provides customer specific conference features via mod_conference. 

We wish to further develop this to provide potential features such as : 

Questions and Answers : guests in lecture mode press some dtmf to indicate they wish to ask a question, and the chair presses some dtmf to manage the queue and unmute the questioner. 

Chair greeting : the chair can record a personal greeting message which is played to guests when they join. 

Security Passcode : the chair can dynamically set a further PIN on the conference instance via DTMF. 

Chair privacy : a chair can invoke privacy via some DTMF so all guests are put on hold, and only chairs can speak. 

And others. 

All of these features will require us to store state relevant to the conference instance. 

It would make life a lot easier if we could store this state as custom variables on the conference object via the mod_conference api. 

Best Regards

Phil