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">

...snip...

</extension>

<caller_profile>

<caller_id_name>FreeSWITCH</caller_id_name>

<caller_id_number>8005551212</caller_id_number>

<network_addr></network_addr>

<rdnis>person</rdnis>

<destination_number>4913</destination_number>

<source>src/switch_ivr_originate.c</source>

<context>default</context>

<chan_name>OpenZAP/1:1/5595551212</chan_name>

<originatee_caller_profile>

<caller_id_name>FreeSWITCH</caller_id_name>

<caller_id_number></caller_id_number>

<network_addr></network_addr>

<rdnis>person</rdnis>

<destination_number>4/a/1160</destination_number>

<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">

...snip...

</extension>

<caller_profile>

<caller_id_name>FreeSWITCH</caller_id_name>

<caller_id_number>8005551212</caller_id_number>

<network_addr></network_addr>

<destination_number>person</destination_number>

<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">

...snip...

</extension>

<caller_profile>

<caller_id_name>FreeSWITCH</caller_id_name>

<caller_id_number>8005409011</caller_id_number>

<network_addr></network_addr>

<destination_number>825595551212</destination_number>

<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>

<caller_id_name>FreeSWITCH</caller_id_name>

<caller_id_number>8005551212</caller_id_number>

<network_addr></network_addr>

<destination_number>1/a/5595551212</destination_number>

<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
GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com
IRC: irc.freenode.net #freeswitch

FreeSWITCH Developer Conference
sip:888@conference.freeswitch.org
iax:guest@conference.freeswitch.org/888
googletalk:conf+888@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