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

[David Boyd]

On Mon, 2007-06-11 at 09:11 -0600, Steve Murphy 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?
> > 
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
> 
> asterisk-users mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-users


Murf, doesn't the first solution pretty much preclude the ability to
bill for additional content or application access? 

And do you foresee a manner in which you would be able to assign a cdr
event type in the dial plan to a given termination type, not only
predefined ones as you have shown?


This is not criticism just an attempt to understand, so if I have missed
some poignant piece of information,  please point me in the proper
direction.


Thanks,
Dave