> I decided, for now, to take the short way out. That is, use ESL to track the
> events on the conference.
>
> One problem that emerged while doing so was how to find unique instances of
> a certain conference. To make it clearer, let me make an example.
>
> Conference 123 is created on Sep 20, 2011 and has 20 members.
>
> Same conference 123 is created on Sep 21, 2011 but now with 10 members.
>
> Besides the obvious time difference, there was a problem identifying that
> the conferences are unique in memory in FreeSWITCH, more accurately, the
> same conference_obj. I came up with the idea then of adding one member to
> the struct. That member is a uuid for that conference and it is added to all
> events spit out by the module, so we know which conference is which
> uniquely.
>
> Since this patch adds stuff to the struct, I didn't want to just commit
> without approval, so I would like to kindly ask one of the core devs to take
> a look at it and give me the green light to commit it, if that's the case.
> Sorry for posting it here, but Jira has been out for most of the weekend. I
> will get it in there if it gets back online and this email has not been
> responded yet.
>
> The patch is attached.
>
> Thank you,
> Joćo Mesquita
>
>
> 2010/12/25 Joćo Mesquita <
jmesquita@freeswitch.org>
>>
>> Hello you all. I hope you are all having a good holiday.
>> I have been looking for the best way of tracking conference usage for
>> reporting purposes (basically answering the question: what happened and when
>> on conference nŗ X?) and I thought of the following alternatives that I
>> would like to discuss with you.
>> 1. Using ESL and the CUSTOM events to keep track of what happened when (I
>> guess that's the most widely used)
>> 2. Creating a new entry on switch_caller_profile, that would be filled by
>> the mod_conference module anytime something changes on the conference.
>> Something similar to what the origination_caller_profile does but that would
>> be manipulated by the mod_conference. This option could neatly integrate
>> with the xml cdrs but would mess a little more on the core. Not sure it is
>> desirable.
>> 3. Make mod_conference spit it's own XML for each conference created so
>> that we know what happens and can link offline to other cdr entities.
>> Or, maybe I am completely dumb and trying to do something that it is not
>> supposed to be done or forgetting some resource that is already available.
>>
>> Joćo Mesquita
>
>