<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
I agree with Freddi and would like to add that a field indicating the<br>
order of the outgoing legs would be very useful. For billing purposes<br>
one could benefit very much if one new the order of the providers <br>
that were called in a specific call.<br>
<br>
Freddi Hansen wrote:
<blockquote cite="mid:492C94A3.806@danovation.dk" type="cite">
<blockquote type="cite">
<pre wrap="">To me the obvious answer is to provide a CDR for every call leg so for
</pre>
<blockquote type="cite">
<pre wrap="">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 weighed up I think people would vote to have accurate CDRs
ahead of anything else and if single legs are the best way to do that
then it's the way it should be done.
In addition with single leg CDRs it will solve the dilemna about
acommodating every possible call scenario that I know has caused you a
lot of consternation over the last 18 months.
Sure it's a change from the current situation so maybe needs to use
the standard apporach of a configuration setting to opt in initially
before becoming the default in the subsequent major release.
</pre>
</blockquote>
<pre wrap="">
OK, Greyman, your logic is solid. If we provide a CDR implementation
that just generates the individual call legs, and ties them together via
the linkedid
(see team/group/newcdr), then both camps should be able to derive the
info
they need for billing, via hopefully not-overly-complex SQL queries to a
backend db.
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. But, pardon if I make it available via the CEL domain come
implementation time.
It should take me a week to rehash my document; perhaps longer (I'm in
bugfix mode, and this borderline development work); in the meantime,
those with decided CDR needs might make their wishes known, if they do
not think this approach will work. Speak now, or forever hold your
peace; or forever complain... or whatever.
If this is particularly distressing to you, perhaps your fears might be
slightly assuaged when you read the details...
</pre>
</blockquote>
<pre wrap=""><!---->I was part of a team that did design a multiservice billing system about
15 years ago and the solution people seems to agree on here (and me to)
looks pretty much the same i.e one call may consist of several calls
legs. In addition to the linkedid it would be nice to have an indication
in the cdr that tells us that 'this is the lastone on this linked id'.
Our experience was that we shouldn't for load reasons work with cdr's
in the immidiate multileg format in the DB. So we did collect cdr's in a
tmp DB until we got the the record with end marker set. We would then
produce our final cdr for the actual service, store it in billing col.
and delete it from the multileg col. When a new service is created we
only have to make a the new customized cdr, we don't have to touch the
generation of the multileg format.
Freddi
_______________________________________________
-- Bandwidth and Colocation Provided by <a class="moz-txt-link-freetext" href="http://www.api-digital.com">http://www.api-digital.com</a> --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
<a class="moz-txt-link-freetext" href="http://lists.digium.com/mailman/listinfo/asterisk-users">http://lists.digium.com/mailman/listinfo/asterisk-users</a>
</pre>
</blockquote>
<br>
</body>
</html>