On Mon, Dec 1, 2008 at 7:57 PM, Philipp Kempgen
<[EMAIL PROTECTED]> wrote:
> JD schrieb:
>
>> As to the idea of piping to a deamon via socket or dbus: how would
>> asterisk behave if the daemon froze or worse, it lagged?
I have implemented something similar with the Dial command. We had a
customer
JD schrieb:
> As to the idea of piping to a deamon via socket or dbus: how would
> asterisk behave if the daemon froze or worse, it lagged?
Asterisk could write the CEL events to the database and either
on every event or after some kind of final event send a signal
to the socket, i.e. write a by
Daniel Hazelbaker wrote:
> On Dec 1, 2008, at 9:07 AM, JD wrote:
>
>
>> Steve Murphy wrote:
>>
>>> Freddi--
>>>
>>> Very interesting. Brian Degenhardt had some code we just gave some
>>> thought
>>> to, wherein we determine if the last channel involved in a linkedID
>>> set
>>> has been c
On Dec 1, 2008, at 9:07 AM, JD wrote:
> Steve Murphy wrote:
>>
>> Freddi--
>>
>> Very interesting. Brian Degenhardt had some code we just gave some
>> thought
>> to, wherein we determine if the last channel involved in a linkedID
>> set
>> has been closed. If so, then the entire set is finished
JD schrieb:
> Steve Murphy wrote:
>> Brian Degenhardt had some code we just gave some
>> thought
>> to, wherein we determine if the last channel involved in a linkedID set
>> has been closed. If so, then the entire set is finished. We can use this
>> facility to get you a closing attribute, that c
Steve Murphy wrote:
> On Wed, 2008-11-26 at 01:13 +0100, Freddi Hansen wrote:
>
>>> To me the obvious answer is to provide a CDR for every call leg so for
>>>
A calling B via Asterisk there would be two CDRs produced. It's far
far easier to disregard the unwanted CDRs than it is
Just seconding Freddi's idea - as it makes perfect sense. Otherwise we
could quite easily start testing a call that hasn't actually finished
yet.
___
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To
On Wed, 2008-11-26 at 01:13 +0100, Freddi Hansen wrote:
> >
> > To me the obvious answer is to provide a CDR for every call leg so for
> > > A calling B via Asterisk there would be two CDRs produced. It's far
> > > far easier to disregard the unwanted CDRs than it is to try and
> > > generate the m
I agree with Freddi and would like to add that a field indicating the
order of the outgoing legs would be very useful. For billing purposes
one could benefit very much if one new the order of the providers
that were called in a specific call.
Freddi Hansen wrote:
To me the obvious answer is to p
>
> To me the obvious answer is to provide a CDR for every call leg so for
> > A calling B via Asterisk there would be two CDRs produced. It's far
> > far easier to disregard the unwanted CDRs than it is to try and
> > generate the missing ones and in some cases it's virtually impossible.
> > If it
Steve Murphy <[EMAIL PROTECTED]> writes:
> I'll modify my RFC to reflect this line of thinking. Yes, it is a
> bit of shift. And, yes, the implementation will make this new
> approach optional, and not default.
I believe the whole approach is sound and I just want to voice my
support for it.
/B
On Tue, 2008-11-25 at 08:06 +, Grey Man wrote:
> >On Mon, Nov 24, 2008 at 6:56 PM, Steve Murphy <[EMAIL PROTECTED]> wrote:
> > For the moment, let's not worry about the implementation. Let's
> > get consensus on the spec first. In the scenario, where A calls B,
> > B xfers A to C, C xfers A to
>On Mon, Nov 24, 2008 at 6:56 PM, Steve Murphy <[EMAIL PROTECTED]> wrote:
> For the moment, let's not worry about the implementation. Let's
> get consensus on the spec first. In the scenario, where A calls B,
> B xfers A to C, C xfers A to D, or some such similar scenario,
> half the world wants a
If we only implement A->D cdr we lose information.
On the other hand, if we implement all 3 CDRs for one call we can
either use this info or ignore it and act like its not there. The first way
is prohibiting for some users. The second one can match any scenario
with none to little effort.
Steve M
On Sat, 2008-11-22 at 04:02 +, Grey Man wrote:
> I've taken the liberty of starting a new thread to discuss the design
> of the Asterisk CDR mechanism. The discussion has been kindly
> initiated by murf putting together a proposal:
> http://svn.digium.com/svn/asterisk/team/murf/RFCs.
>
> After
I've taken the liberty of starting a new thread to discuss the design
of the Asterisk CDR mechanism. The discussion has been kindly
initiated by murf putting together a proposal:
http://svn.digium.com/svn/asterisk/team/murf/RFCs.
After reading the proposal I still don't think it's the right way to
I've taken the liberty of starting a new thread to discuss the design
of the Asterisk CDR mechanism. The discussion has been kindly
initiated by murf putting together a proposal:
http://svn.digium.com/svn/asterisk/team/murf/RFCs.
After reading the proposal I still don't think it's the right way to
17 matches
Mail list logo
