, Raymond Dans wrote:
> Scott wrote:
>
>> Subject: Re: [sipx-users] New CDR database design
>>
>> On Wed, 2010-02-03 at 13:43 -0600, Josh Patten wrote:
>>
>>> I am curious what the new CDR database design is going to look
>>> like/consist of.
...@list.sipfoundry.org
[mailto:sipx-users-boun...@list.sipfoundry.org] On Behalf Of Josh Patten
Sent: Wednesday, February 03, 2010 12:09 PM
To: Scott Lawrence
Cc: sipx-users@list.sipfoundry.org
Subject: Re: [sipx-users] New CDR database design
There is no way from the generated CDR's to follo
Scott wrote:
>Subject: Re: [sipx-users] New CDR database design
>
>On Wed, 2010-02-03 at 13:43 -0600, Josh Patten wrote:
>> I am curious what the new CDR database design is going to look
>> like/consist of. I am meeting with my programming team today to
>> discuss
There is no way from the generated CDR's to follow the call flow. There
is also no way to know how long a call actually lasted if it was
transferred or put on hold. This information exists in the Call State
Events table but doesn't transfer over to the cdrs table. I posted about
the ideas I had
On Wed, 2010-02-03 at 13:43 -0600, Josh Patten wrote:
> I am curious what the new CDR database design is going to look
> like/consist of. I am meeting with my programming team today to discuss
> writing a CDR parser and I would like to show them examples of what kind
> of data they can expect to
I am curious what the new CDR database design is going to look
like/consist of. I am meeting with my programming team today to discuss
writing a CDR parser and I would like to show them examples of what kind
of data they can expect to work with. As it currently stands it looks
like they will ha
