[asterisk-users] CDR Design

[Grey Man]

> On Fri, Dec 5, 2008 at 8:11 PM, Steve Murphy <murf at digium.com> wrote:
>
> Hmmm.  See your point. I can suppress these HOLD events, and any
> others I end up covering with a config file. Whether it's by default
> on or off, we can arrange as the majority, whatever that is,
> requests.
>
> In my current line of thinking, the HOLD period was output to
> help describe what was done with the channel. Whether folks
> on hold are charged the same as folks not on hold, that's a
> business decision.
>
> I personally cannot predict with any certainty what folks
> will be interested in billing or not billing. You seem pretty
> certain that HOLD information is useless to billing, but can you
> guarantee me that this info is useless in all possible billing
> situations?

No I can't but it would be the first I'd ever heard of anybody being
differently when they were on hold compared to a normal call. Putting
a call hold does not change the original call ends and the time on
those calls keeps ticking so I can guarantee you there a people like
me that want to bill the call besed on endpoints and whether the call
is on hold, listening to streaming radio, being sent a festival tts
message etc. is irrelevant.

> Well, if I take a UUID type field and tack it onto the end of the
> current LinkedID, will that do? I get something I can sort timewise
> and make a quick decision on; you get something that but once every
> billion-trillion-gazillion times, will be unique. And you can also
> tack a system id onto the end, or the begin for that matter, on the
> way to the database....

In my perfect World I'd change uniqueid to a UUID since that's what it
claims to falsely be. But as you say there are other ways a unique id
can be added and if needs be we could do it that way. I've being
trying to avoid a bunch of comma separated data in the UserField but
that's no big deal either way.

> maybe. But, you can do one-touch stuff via dtmf to asterisk, and
> do transfers that way. How this might reflect back into the sip
> protocal, I'm not certain right now. A sip device might not be
> able to tell what happened, but this is conjecture on my part.

No it doesn't. A SIP transfer is a striaght forward operation and the
only way to do one is with a REFER request. How you generate the REFER
request can be different such as DTMF or transfer button but the
effect is identical. When Asterisk processes the REFER request it is
going to end up initiaiting a call and for a blind transfer hanging
one up. That's it.

> I'll have to think on this. Perhaps an option to reduce everything
> to single per-chan cdrs. It'll be a ton easier to implement something
> like this by NOT storing the CDR on a channel.

In my life as a software engineer simple solutions tend to be the right ones.

Regards,

Greyman.