asterisk users - Jan 2009 - [Re: CDR Rewrite -- Questions to the users]

Benny--

Thanks for the response!  I've inserted comments in the following:

PS. Pardon the HTML format; my email editor splits lines at an
unadjustably
small number of columns, but in HTML, no line length limits, and better
looking examples!

On Tue, 2009-01-13 at 14:16 +0100, Benny Amorsen wrote: 
> Steve Murphy <murf at digium.com> writes:
> 
> > Which of the two would you see being useful to you?
> 
> "Leg based", as far as I can see, because that looks like the
only way
> to bill transfers differently depending on which end did the transfer.
> 
> Possibly "Simple" on the Asterisk systems where we forbid
transfers.
> 
> > Is there Yet Another CDR system you would like to see instead?
> > How would/should it work?
> 
> "Leg based" looks good.
> 
> > Will both fulfil the requirements of CALEA?
> 
> We're not yet operating in a jurisdiction where CALEA applies. It
> looks good enough for the jurisdictions we operate in, possibly apart
> from the transfer issues further down, but I am certainly not a
> lawyer.
> 
> > It's been proposed that we implement just the Simple 
> > CDR now, and it be introduced in some 1.6.x (or higher)
> > release.  In that release, the existing CDR system would be
> > deprecated, and in some "futurer" release the
"old" (now current)
> > CDR system would be dropped entirely. What do you
> > think? Are we high on drugs, or what?
> 
> I need this functionality for transfers, and I don't think
"Simple"
> provides it:
> 
> A calls B: A pays for the whole duration for A => B
> B transfers to C: B pays for B => C, A is still paying A => B
> 

Good Question: Can Simple CDRs be used in xfer situations?

Let's take a look.

In this particular situation, 3 channels are involved: A, B, and C.
Therefore,
you will get 3 CDRs.

     CDR1:  A -> B  start: e1a  ans: e2  end: e4   Party: B  disp: ANSW
linkedID: abc9
     CDR2:  A       start: e1   ans: e1  end: e6   Party: A  disp: ANSW
linkedID: abc9
     CDR3:  B -> C  start: e4   ans: e5  end: e6   Party: C  disp: ANSW
linkedid: abc9

CDR2 covers A (see the Party field),  CDR1 covers B, CDR3 covers C.

A's CDR could be used to bill A for his call in. It covers both the time
A spent
talking to B, and C. If you charge a different rate for A talking to B
vs C, then
you have some interesting SQL queries to make, I'll guess...

C's CDR records that B called C. It doesn't mention that A is doing all
the talking.

B's CDR records the call from A to B; this is the only one that seems a
little useless...

Is this enough? If this is all you had, could you make it work? If you
can't, 
would adding a field or two help?


> If it was A who transferred the call instead:
> 
> A calls B: A pays for the whole duration for A => B
> A transfers to C: A pays for A => C, and A is still paying A => B
> B and C get to talk for free, while A pays twice.
> 

In the SImple CDR world, here's what would be produced:

     CDR1:  A       start: e1   ans: e1  end: e4   Party: A  disp: ANSW
linkedID: abc9
     CDR2:  A -> B  start: e1a  ans: e2  end: e6   Party: B  disp: ANSW
linkedID: abc9
     CDR3:  A -> C  start: e4   ans: e5  end: e6   Party: C  disp: ANSW
linkedid: abc9

Here, A's total connection time is in CDR1; B with CDR2;  C with CDR3.

The call from B to C is in CDR3. A's transfer to C is in CDR3 (I just
corrected this
in the CDRfix2 document).

Again, is there enough info here for you to do what you need to do? If
not
what addition could be added to make it work?


> This should apply whether transfers are attended (soft), unattended
> (hard) or caused by SIP redirections before answering. Ideally it
> should also be possible to simulate SIP-like redirections in the
> dialplan with the same CDR behaviour.
> 

In the CDRfix2 doc, I outlined both the above blindxfer cases, and also
permutations
of attended xfers. Look them over, and see if what you need is possible
with this format,
and if not, is there something we can add that *would* make it
usable...?

murf

-- 
Steve Murphy <murf at digium.com>
Digium

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.digium.com/pipermail/asterisk-users/attachments/20090113/3e296574/attachment.htm
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3227 bytes
Desc: not available
Url :
http://lists.digium.com/pipermail/asterisk-users/attachments/20090113/3e296574/attachment.bin