In my experience the first profile_index corresponds to the originate command and subsequent indices correspond to the various transfers. Here's an example from a real cdr (redacted) that has four indices. Note that they are in reverse order, so the most recent profile_index appears first in the xml file: <callflow dialplan="XML" profile_index="4"> <extension name="tod_example" number="4913"> ...snip... </extension> <caller_profile> <username></username> <dialplan>XML</dialplan> <caller_id_name>FreeSWITCH</caller_id_name> <ani></ani> <aniii></aniii> <caller_id_number>8005551212</caller_id_number> <network_addr></network_addr> <rdnis>person</rdnis> <destination_number>4913</destination_number> <uuid>7181f6d2-95dd-42ee-a589-544f575ebf9a</uuid> <source>src/switch_ivr_originate.c</source> <context>default</context> <chan_name>OpenZAP/1:1/5595551212</chan_name> <originatee> <originatee_caller_profile> <username></username> <dialplan>XML</dialplan> <caller_id_name>FreeSWITCH</caller_id_name> <ani></ani> <aniii></aniii> <caller_id_number></caller_id_number> <network_addr></network_addr> <rdnis>person</rdnis> <destination_number>4/a/1160</destination_number> <uuid>fee6d853-44c4-43cf-999f-32a5579e129c</uuid> <source>src/switch_ivr_originate.c</source> <context>default</context> <chan_name>OpenZAP/4:1/1160</chan_name> </originatee_caller_profile> </originatee> </caller_profile> <times> <created_time>1215550893566509</created_time> <profile_created_time>1215550957250480</profile_created_time> <progress_time>1215550893942396</progress_time> <progress_media_time>1215550895995423</progress_media_time> <answered_time>1215550904242447</answered_time> <hangup_time>1215550973271729</hangup_time> <transfer_time>0</transfer_time> </times> </callflow> <callflow dialplan="XML" profile_index="3"> <extension name="person" number="person" current_app="hangup"> ...snip... </extension> <caller_profile> <username></username> <dialplan>XML</dialplan> <caller_id_name>FreeSWITCH</caller_id_name> <ani></ani> <aniii></aniii> <caller_id_number>8005551212</caller_id_number> <network_addr></network_addr> <rdnis>825595551212</rdnis> <destination_number>person</destination_number> <uuid>7181f6d2-95dd-42ee-a589-544f575ebf9a</uuid> <source>src/switch_ivr_originate.c</source> <context>default</context> <chan_name>OpenZAP/1:1/5595551212</chan_name> </caller_profile> <times> <created_time>1215550893566509</created_time> <profile_created_time>1215550905873831</profile_created_time> <progress_time>1215550893942396</progress_time> <progress_media_time>1215550895995423</progress_media_time> <answered_time>1215550904242447</answered_time> <hangup_time>0</hangup_time> <transfer_time>1215550957250480</transfer_time> </times> </callflow> <callflow dialplan="XML" profile_index="2"> <extension name="tod_example" number="825595551212"> <application app_name="set" app_data="open=true"></application> ...snip... </extension> <caller_profile> <username></username> <dialplan>XML</dialplan> <caller_id_name>FreeSWITCH</caller_id_name> <ani></ani> <aniii></aniii> <caller_id_number>8005409011</caller_id_number> <network_addr></network_addr> <rdnis>1/a/5595551212</rdnis> <destination_number>825595551212</destination_number> <uuid>7181f6d2-95dd-42ee-a589-544f575ebf9a</uuid> <source>src/switch_ivr_originate.c</source> <context>default</context> <chan_name>OpenZAP/1:1/5595551212</chan_name> </caller_profile> <times> <created_time>1215550893566509</created_time> <profile_created_time>1215550895997527</profile_created_time> <progress_time>1215550893942396</progress_time> <progress_media_time>1215550895995423</progress_media_time> <answered_time>1215550904242447</answered_time> <hangup_time>0</hangup_time> <transfer_time>1215550905873831</transfer_time> </times> </callflow> <callflow profile_index="1"> <caller_profile> <username></username> <dialplan></dialplan> <caller_id_name>FreeSWITCH</caller_id_name> <ani></ani> <aniii></aniii> <caller_id_number>8005551212</caller_id_number> <network_addr></network_addr> <rdnis></rdnis> <destination_number>1/a/5595551212</destination_number> <uuid>7181f6d2-95dd-42ee-a589-544f575ebf9a</uuid> <source>src/switch_ivr_originate.c</source> <context>default</context> <chan_name>OpenZAP/1:1/5595551212</chan_name> </caller_profile> <times> <created_time>1215550893566509</created_time> <profile_created_time>1215550893566509</profile_created_time> <progress_time>1215550893942396</progress_time> <progress_media_time>1215550895995423</progress_media_time> <answered_time>0</answered_time> <hangup_time>0</hangup_time> <transfer_time>1215550895997527</transfer_time> </times> </callflow> </cdr> Notice how profile_index="1" doesn't have the extension tag, nor does it have a 'dialplan="XML"' property. In my setup this is the result of the originate command, in this case: originate openzap/1/a/5595551212 825595551212 A successful originate places the call into my "tod_example" extension (see profile_index="2") where it gets processed. It gets transferred a few more times which is why there are other profile_index values. BTW, an unsuccessful originate will have just the one profile_index unless "continue_on_fail=true". (Someone please confirm that - I don't use continue_on_fail at all.) If I have a USER_BUSY or UNALLOCATED result for my originate cmd then I simply have an xmlcdr with a single profile_index, plus the usual stuff like the <variables>. If the originate is successful then I have the various profile_index entries depending upon what happens to the call in my dialplan. For example, I don't ignore early media, so I get "successful" originate commands when I get ringing after I dial. I have a waitforanswer.js script that waits 30 secs and if no answer then it sets a channel variable and hangs up. Hope this helps... -MC ________________________________ From: freeswitch-users-bounces@lists.freeswitch.org [mailto:freeswitch-users-bounces@lists.freeswitch.org] On Behalf Of Anthony Minessale Sent: Wednesday, July 09, 2008 12:43 PM To: freeswitch-users@lists.freeswitch.org Subject: Re: [Freeswitch-users] XMLCDR Question: <callflow profile_index="x"> both cases are a transfer On Wed, Jul 9, 2008 at 2:33 PM, Joseph Bajin <josephbajin@gmail.com> wrote: Is there a way to tell what caused that new caller profile to happen? If it was a transfer or if it was an originate from a FSAPI? On Wed, Jul 9, 2008 at 3:10 PM, Anthony Minessale <anthony.minessale@gmail.com> wrote: every time a new caller profile is installed into a channel it will stack another callflow so each time it returns to the dialplan which is caused mainly by the transfer app or the originate FSAPI when it does an outbound call then transfers it to an extension. On Wed, Jul 9, 2008 at 1:53 PM, Michael Collins <mcollins@fcnetwork.com> wrote: I am experimenting with XML CDRs and I was curious about this part of the record. It seems that with each transfer to a different extension I'm getting a new callflow profile. That's good - I just want to make sure that my understanding of this is correct. Will a new callflow profile get generated for each successive transfer to a different extension? Also, are there other scenarios that generate a new callflow profile? Lastly, is there a way to force a new callflow profile to occur from within the dialplan? (That last one is just a curiosity, although it would help me handle some quirky CDR needs with the IVR that I'm working on.) Thanks! -MC P.S. - as per usual, any info provided here will go straight to the wiki! _______________________________________________ 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 -- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400 _______________________________________________ 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 -- --Joe "Success is easy if you think of it like Rust: It's inevitable if you keep at it. Guys claim there are magic moments, but that's just bullshit." --Fred Franzia (The famous wine guy) _______________________________________________ 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 -- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <mailto:MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com <mailto:PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <mailto:sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org <mailto:googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400