Nick, <br><br>You might take a look at the CDR generator proposal I've written, I cover<br>the uniqueID issues in there, I think, to your satisfaction, so channels,<br>call trees, and individual CDR's can all be uniquely referenced via DB queries. <br>
Guids, and multi-system unique ID's are also discussed.<br><br>Right now, I'm in negotiations with sverre in private emails, about how we<br>can/will frame CDRs for various transfer situations. I'm trying to fully<br>
understand his needs.<br><br>The prototype proposal still needs work, but the current issue is fetchable<br>from subversion, at: <a href="http://svn.digium.com/svn/asterisk/team/murf/RFCs">http://svn.digium.com/svn/asterisk/team/murf/RFCs</a><br>
<br>There are PDF and source .doc files in that dir.<br><br>I would LOVE to get more input. The more ways of looking at it, the better<br>the final result. Basically, for all those for whom "Simple CDRs" are simply<br>
not workable, I need to understand the variety of different usages, to better<br>formulate a generic mechanism that will service everyone. I'd love to get paid<br>to do it, it would definitely go faster that way, but that's another discussion!<br>
<br>murf<br><br><br><div class="gmail_quote">On Thu, Aug 27, 2009 at 10:12 AM, Nick Lewis <span dir="ltr"><<a href="mailto:Nick.Lewis@atltelecom.com">Nick.Lewis@atltelecom.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
>Is that really a problem, though? There was no suggestion that the OP<br>
needed<br>
>the ID prior to the record being posted, just that he needed a unique<br>
ID per<br>
>record.<br>
<br>
</div>Needed in dial plan at same time as cdr posted e.g.<br>
<br>
Exten => s,n,StopMixMonitor()<br>
exten => s,n,ResetCDR(w)<br>
exten => s,n,MixMonitor(call${CDR(linkedid)}part${CDR(seq)}.wav)<br>
<br>
OP<br>
<div class="im"><br>
_____________________________________________________________________<br>
This message has been checked for all known viruses by Star Internet delivered through the MessageLabs Virus Control Centre.<br>
_____________________________________________________________________<br>
Disclaimer of Liability<br>
ATL Telecom Ltd shall not be held liable for any improper or incorrect use of the information described and/or contained herein and assumes no responsibility for anyones use of the information. In no event shall ATL Telecom Ltd be liable for any direct, indirect, incidental, special, exemplary, or consequential damages (including, but not limited to, procurement or substitute goods or services; loss of use, data, or profits; or business interruption) however caused and on any theory of liability, whether in contract, strict liability, or tort (including negligence or otherwise) arising in any way out of the use of this system, even if advised of the possibility of such damage.<br>
<br>
Registered Office: ATL Telecom Ltd, Fountain Lane, St. Mellons Cardiff, CF3 0FB<br>
Registered in Wales Number 4335781<br>
<br>
All goods and services supplied by ATL Telecom Ltd are supplied subject to ATL Telecom Ltd standard terms and conditions, available upon request.<br>
<br>
_______________________________________________<br>
</div><div><div></div><div class="h5">--Bandwidth and Colocation Provided by <a href="http://www.api-digital.com--" target="_blank">http://www.api-digital.com--</a><br>
<br>
AstriCon 2009 - October 13 - 15 Phoenix, Arizona<br>
Register Now: <a href="http://www.astricon.net" target="_blank">http://www.astricon.net</a><br>
<br>
asterisk-dev mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
<a href="http://lists.digium.com/mailman/listinfo/asterisk-dev" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Steve Murphy<br>ParseTree Corp<br><br>