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 that
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 missing ones
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
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 to try and
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 could be
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. We can use
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 closed. If so, then the
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
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
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 single
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 D, or
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.
/Benny
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's
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
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
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
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
17 matches
Mail list logo
