The way I did it (but still dont understand completely) was as follows: What I am trying to do is have a web based panel which can 'follow through' calls. Scenario A: 1. Caller Extension 200 (me) calls my cell phone 2. Cell phone picks up, we talk for 10 seconds 3. I call extension 603, talk for 5 seconds and do a attended transfer 4. 603 talks to my cell phone and hangs up after 15 seconds I get 3 results XML_CDR curl posts (or 3 files if not using curl): CDR for Step 1 & 2 - this is treated like a separate call and has its own CDR. I am assuming (please correct me if Im wrong): sip_call_id points to the uuid of the call leg between the phone and freeswitch uuid in callflow/0/caller_profile/uuid is the first channel that was bridged to this call- which is the leg of the call going from freeswitch to the sip_pstn_gateway CDR for Step 3: This has the endpoint_disposition set to ATTENDED_TRANSFER. This is treated as a brand new call (which is correct). it has a different sip_call_id and a different callflow/0/caller_profile/uuid CDR for Step 4: This is generated after 603 hangs up. This is where I am confused. The sip_call_id is brand new (shouldn't it be the same as the uuid in Step 1? isn't this the same call?) This call has two callflows: callflow/0/caller_profile/uuid = uuid found in step 1 callflow/1/caller_profile_uuid = uuid found in step 2 questions: 1. What exactly does callflow mean? My understand is that its the channels that have been bridged to THIS channel (in order) 2. In the Last CDR thats generated, what do the "times" part of the tree contain? What time is freeswitch exactly calculating and how is it different from the time_stamps in the 'variables' part of the tree? I can contribute back a decently slick CDR panel and mysql DB if somebody can help me understand the XML output! :) Grey Man wrote:
On Mon, Jul 7, 2008 at 4:24 PM, Anthony Minessale <anthony.minessale@gmail.com> 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 Freeswitch-users@lists.freeswitch.org 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