I decided, for now, to take the short way out. That is, use ESL to track the events on the conference.<br><br>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.<br>
<br>Conference 123 is created on Sep 20, 2011 and has 20 members.<br><br>Same conference 123 is created on Sep 21, 2011 but now with 10 members.<br><br>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.<br>
<br>Since this patch adds stuff to the struct, I didn&#39;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&#39;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.<br>
<br>The patch is attached.<br><br>Thank you,<br clear="all">Joćo Mesquita<br>
<br><br><div class="gmail_quote">2010/12/25 Joćo Mesquita <span dir="ltr">&lt;<a href="mailto:jmesquita@freeswitch.org">jmesquita@freeswitch.org</a>&gt;</span><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<div>Hello you all. I hope you are all having a good holiday.</div><div><br></div><div>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.</div>

<div><br></div><div>1. Using ESL and the CUSTOM events to keep track of what happened when (I guess that&#39;s the most widely used)</div><div><br></div><div>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.</div>

<div><br></div><div>3. Make mod_conference spit it&#39;s own XML for each conference created so that we know what happens and can link offline to other cdr entities.</div><div><br></div><div>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.</div>

<div><br></div><font color="#888888"><br clear="all">Joćo Mesquita<br>
</font></blockquote></div><br>