On Friday 28 September 2007 10:56:19 Rilawich Ango wrote: > Thanks. > Actually, I want to have some information about the call transfer just > like to queue_log in queue. > According to your message, there is no such mechanism to associate the > call in call transfer. How about any variable that I can identify the > call which is made by call transfer? > As I know there is a variable ${BLINDTRANSFER} that will fill in a > value in blind transfer. However, I can't find any variable that will > fill in a attended transfer. Anyone can advise?
Hi, I have done this in dialplan logics. First i'm setting some global inherited variable Set(__call_id}=${UNIQUEID}) - that is unique for channel. That becomes call id for entire call - wherever it would gou - queues, transfers, etc. As it's inherited it is copied to newly created channels. Then in CDR's userfield i add ${call_id}, plus number that identifies call leg. This makes my CDR easilly linkable and trackable. Regards, Atis > > On 9/28/07, Alex Balashov <[EMAIL PROTECTED]> wrote: > > On Fri, 28 Sep 2007, Rilawich Ango wrote: > > > In CDR, I found that there are 3 records after doing call transfer. > > > However, 3 of them are individual record that is very difficult to > > > identify they are related to call transfer. My question is how to > > > identify the call with a clear flow, from CDR or by other means, is a > > > call transfer. > > > > Do they have a common criterion? If they do not have a common > > criterion, it is probably not logically possible to associate them. > > Asterisk is a back-to-back user agent, so it builds out distinct legs for > > every call with unique Call-IDs and dialogue tags. This makes it hard to > > meaningfully associate call flows like this inherently, unless you do > > state tracking in the software to make this possible. > > > > This has been an ongoing topic of discussion periodically on the > > Asterisk Developers' List (asterisk-dev). It seems there is considerable > > interest in reworking the CDR engine to account for this type of > > situation more meaningfully. You may wish to search the list archives > > for greater insight into what core developers are thinking, or to join > > the list and add your two cents to what you want to see from it. You're > > definitely not the first person to run into this or regard it as a > > serious impediment. :) > > > > Cheers, > > > > -- > > Alex Balashov > > _______________________________________________ > > Sign up now for AstriCon 2007! September 25-28th. > http://www.astricon.net/ > > --Bandwidth and Colocation Provided by http://www.api-digital.com-- > > asterisk-users mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-users -- Atis Lezdins VoIP Developer, IQ Labs Inc. [EMAIL PROTECTED] Skype: atis.lezdins Cell Phone: +371 28806004 Work phone: +1 800 7502835 _______________________________________________ Sign up now for AstriCon 2007! September 25-28th. http://www.astricon.net/ --Bandwidth and Colocation Provided by http://www.api-digital.com-- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users