[asterisk-dev] Relating Monitor Recording to a Call Unique ID

[Steve Totaro]

Use the sipcallid, FTP, AMI, and FastAGI (I try to keep databases off of
PBXs,)

I have done the same thing and in this case, I used M$ SQL and the FastAGI
script/executable, was compiled and running on a Windows box.  It worked
perfectly). to store the names of the calls with a guid..  That is, if you
are using SIP.  Apologies for the top post.

Apologies for the top post, but today I feel like being a bad boy.

Steve Totaro

On Tue, Jun 15, 2010 at 9:02 AM, M Metzger <matt.metzger at gmail.com> wrote:

>
> Oh, I see. Is there a reliable way in which people can find an audio file
> relating to a call? If not by uniqueID, in some other way? Is there a way to
> inject a custom value into the monitor recording that relates it to the
> call? It would be just as good for me to place an external record id (of my
> own) into the recording filename. I just need to be able to find the
> recording tied to the call.
>
> Thanks,
>
> Matthew
>
>
>
>
> On Tue, Jun 15, 2010 at 7:55 AM, Dave Woolley <david.woolley at bts.co.uk>wrote:
>
>> Steve Totaro wrote:
>>
>> > How can I relate the Asterisk call initiating UniqueID to
>> > the monitor audio recording filename - with certainty? It to
>> > appears the monitor files are a collection of values, one part to
>> > of which seems to be a one-off of the Asterisk call originating to
>> > UniqueID. Do these relate the same every time. I cannot tell if to
>> > the monitor file will contain the call initiating UniqueID + 1 to
>> > every time or if this is an inconsistent process. Please let me to
>> > know. Also, please let me know if clarification is needed.
>>
>> You would need to look up the bridged peer at run time.  The unique-ID
>> is composed of the time, to the second, and a sequential integer.  The
>> time part might differ if the incoming and outgoing channels were
>> created across a second boundary, and the sequence number might differ
>> from being one greater if another channel creation intervened.  You
>> really need to treat this value as opaque.
>>
>> I'm not sure if this is more of a support question than a developer one.
>>
>> As this is a public list, the confidentiality part of the following
>> doesn't apply.
>> --
>> David Woolley
>> BTS Holdings Plc
>> Tel: +44 (0)20 8401 9000 Fax: +44 (0)20 8401 9100
>> http://www.bts.co.uk
>> _____________________________________________________________________
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-dev/attachments/20100615/99ccc672/attachment-0001.htm