[asterisk-users] CDR on transfers of called ZAP channel

[Steve Murphy]

Gunnar--

CDR generation that covers transfers is an "umimplemented" feature in
Asterisk, in any version.

I have been working on a solution, but unfortunately, my solution is
radical enough that I dare not apply it to 1.2 or even 1.4. It will most
likely break every working implementation of billing that has been built
on Asterisk by end users/developers. Unpleasant visions of angry mobs of
developers armed with baseball bats, who want nothing more than to drag
me out of my home and "share" their pain and frustration over my
fixes..... you get the idea.

Actually, I have TWO solutions! One, is to modify the current CDR
engine, the other is to provide an entirely different solution that is
single-event driven, kinda along the lines of manager events, but more
streamlined for CDR billing purposes.

The first solution somewhat reorganizes CDRS by no longer posting them
to the backend db's when a hangup occurs. Rather, it will post them when
a bridge between channels is "finished", or "ends". Since a Local
channel acts as a sort of bridge, I think I will have to do the same
thing there. I'm in the middle of it now. I spent/wasted a good amount
of time generating extra CDR's that would describe time in different
parts of a transfer, but as I traveled further down that road, I see
that this will only make things unnecessarily complex. So, I'm not going
to do it. What this means is that a CDR will get generated for each
chunk of a conversation involved in a transfer, but these pieces will
not tell you much about how the chunks relate to each other. The channel
originating the conversation will be the "source", and the channel
originally connected to will be the "destination". Time spent in 3-way
conferences, music on hold, etc. etc. will most likely not be available.
My theory is that, in most cases, it won't matter. All you REALLY want
to know is who to bill, and for how much time. If a transfer occurs, it
involves someone "internally" dialing another party. This second
"conversation", will generate another CDR, and the guy who dialed it
will be assigned that call, even if he hung up before the call was
answered (blind xfer).  For example, picture this: a switch in Modesto
gets a call from Sacramento, and extension 151 gets this call, and dials
Shanghai, and blind transfers the Sacramento call to Shanghai, and then
Sacramento and Shanghai talk for an hour. Two CDR's will be generated.
One will cover the incoming call from Sacramento, and will be little
over an hour. The other CDR that will come out will say 151 dialed
Shanghai and talked an hour. That's it.

The second solution, the event-based one, will generate an event record
for each significant event in the life of each channel. So, "START"
events when a channel is born; "ANSWER" events when someone answers a
call; "END" events when somebody hangs up. There will also be "Park",
and "Transfer", and "MOH", and "3-WAY", Conference-Join", and several
others. Just enough information will be included with each event to
thread together billable sequences. Along with each event record will be
the time the event happened, and channel info. This approach will be
very much more fine-grained, and allow you to do fancy things like
figure out that Sacramento was the only person talking to Shanghai, and
allow you to bill the call to the guy/gal in Sacramento. Trouble with
this approach is that threading together the event records is a
non-trivial operation! But I hope to provide some tools that will make
this easier to do.

So, the bad news is: you will not see any solutions for this problem, in
1.2, or 1.4. the CDR "fix" (first solution) will most likely end up in
1.6, the event-based solution will probably not be available until 1.8
or 1.10; we shall see.

murf


On Mon, 2007-06-11 at 14:26 +0200, Gunnar Schaller wrote:
> Hello list,
> I have a problem with called ZAP channels making an attended-transfer
> or blind-xfer. Signalling at the phones is ok, but the CDR of Asterisk
> is wrong.
> At the moment there is a bristuffed Asterisk 1.2.18 running with
> bristuff-0.3.0-PRE-1y-g. Here is my dialplan, I simplified it a bit:
> 
> [default]
> exten => 0123456789,1,Macro(dialpstn,${EXTEN})
> 
> [macro-dialpstn]
> exten => s,1,Set(TRANSFER_CONTEXT=transfer)
> exten => s,2,Set(FORWARD_CONTEXT=transfer)
> exten => s,3,Set(CIDNUMORIG=${CALLERID(num)}) ; save callerid-num
> exten => s,4,Set(CALLERID(num)=98765) ; dial out using msn 98765
> exten => s,5,Dial(Zap/g1/${ARG1}|30|t)
> 
> exten => h,1,Set(CALLERID(num)=${CIDNUMORIG}) restore callerid-num for
> CDR
> 
> [transfer]
> exten => _X.,1,Set(CALLERID(all)="External" <0123456789>)
> exten => _X.,1,Dial(SIP/${EXTEN})
> 
> 
> So I call 0123456789 with SIP phone 10. The callee dials *1 20 for
> attended transfer and SIP phone 20 (I have *1 for attended transfer in
> features.conf). The called SIP-phone shows the caller-information I
> set in context "transfer". But the CDR is wrong, it has 98765 in MySQL
> field src. So it seems I can't overwrite the ${CALLERID(num)} for cdr,
> but for the called channel.
> Anybody who can explain that? Or any solution for called Zap channels
> making an attended transfer?
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3239 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20070611/a6aa6d1e/smime.bin