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

[Gunnar Schaller]

Hello Steve,
Thank you for the detailed answer. The first solution you mentioned
seems to be good enough for me. So I have to wait for Asterisk 1.6.
That's bad, but I have to wait.
My hope was a way with Asterisk 1.2 (or 1.4) and CDR-functions like
ForkCDR or with some local channels. I worked on a mobile-integration
solution. In Switzerland you can have "Team Unlimited", that's a
mobile option. Free calls from fixed company lines to the employees
mobile. It's like DECT phones, but not limited to DECT base stations
:-)
But without correct CDR I have to review the whole plan.

Thanks for your help,
Gunnar



Monday, June 11, 2007, 5:11:18 PM, you wrote:

> 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?
>>