Sorry for the multiple posts but I am just trying to provide as much information so that somebody can shed light on it:
Problem scenario: 1. Inbound call from PSTN to IVR (9999) 2. caller dials 200 and gets to my extension 3. I do a Attended transfer to 204 4. 204 talks and hangs up. for this i only get TWO cdrs: 1. First CDR is the call i made to 204 and ends with ATTENDED_TRANSFER 2. The last CDR has the actual inbound PSTN call. However, this time callflow/0/call_profile/uuid links to a uuid which was NEVER logged by the CDR. I am guessing this was the UUID of the inbound PSTN call. What ends up happening is that I have two calls without a method of establishing a relationship with the earlier calls- since the first uuid mentioned in the callflow was never logged. If my understanding of the 'callflow' tree is completely flawed can someone point me in the right direction? I would love to have this call tracing feature! > Grey Man wrote: >> On Mon, Jul 7, 2008 at 4:24 PM, Anthony Minessale >> <[EMAIL PROTECTED]> wrote: >>> if you use mod_xml_cdr you will get 1 cdr report in it's own file per call. >>> >>> Each time the call is transferred it's documented and the call flow is >>> expanded so you should be satisfied with it. >>> >> Hi There, >> >> I was able to test transfer CDRs with freeswitch and encountered >> similar issues to those I've had with Asterisk >> (http://bugs.digium.com/view.php?id=11849). >> >> In Freeswitch's case the blind transfer CDR problem is the same as >> Asterisk's. If you call a billable destination through the server and >> then do a blind transfer (REFER) to another billable destination you >> get left with a call that has two billable legs but you will only get >> one CDR. >> >> With attended transfers Freeswitch generates a CDR for the first call >> leg when the transfer occurs and a CDR for the second call leg when >> the call ends except that the destination on the second call leg is >> incorrect and has been modified to be the callerid of the first >> caller. It should be generating the CDRs for both call legs when the >> call ends and not when the transfer occurs. I also got an extra CDR >> quite a while after the transferred call had hung up with a >> disposition of "RECOVERY_ON_TIMER_EXPIRE" with a destination >> corresponding to the second call leg. >> >> This whole transfer/CDR thing is very unsexy and a pain for developers >> but it's a critical thing for those of us that run businesses >> supplying telephony services. This one issue has cost the company I >> work for an amount into 4 figures. >> >> Regards, >> >> Greyman. >> >> _______________________________________________ >> Freeswitch-users mailing list >> [email protected] >> http://lists.freeswitch.org/mailman/listinfo/freeswitch-users >> UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users >> http://www.freeswitch.org >> > -- Faraz R Khan Chief Architect Emergen Consulting Pvt Ltd +92.21.529.0381 x200 www.emergen.biz _______________________________________________ Freeswitch-users mailing list [email protected] http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
