Try enabling b legs in the xml_cdr<br><br><param name="log-b-leg" value="true"/><br><br><br><br><br><br><div class="gmail_quote">On Wed, Jul 9, 2008 at 9:35 AM, Faraz R. Khan <<a href="mailto:faraz.khan@emergen.biz">faraz.khan@emergen.biz</a>> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Sorry for the multiple posts but I am just trying to provide as much<br>
information so that somebody can shed light on it:<br>
<br>
Problem scenario:<br>
<br>
1. Inbound call from PSTN to IVR (9999)<br>
2. caller dials 200 and gets to my extension<br>
3. I do a Attended transfer to 204<br>
4. 204 talks and hangs up.<br>
<br>
<br>
for this i only get TWO cdrs:<br>
<br>
1. First CDR is the call i made to 204 and ends with ATTENDED_TRANSFER<br>
2. The last CDR has the actual inbound PSTN call. However, this time<br>
callflow/0/call_profile/uuid links to a uuid which was NEVER logged by<br>
the CDR. I am guessing this was the UUID of the inbound PSTN call.<br>
<br>
What ends up happening is that I have two calls without a method of<br>
establishing a relationship with the earlier calls- since the first uuid<br>
mentioned in the callflow was never logged.<br>
<br>
If my understanding of the 'callflow' tree is completely flawed can<br>
someone point me in the right direction? I would love to have this call<br>
tracing feature!<br>
<br>
> Grey Man wrote:<br>
>> On Mon, Jul 7, 2008 at 4:24 PM, Anthony Minessale<br>
>> <<a href="mailto:anthony.minessale@gmail.com">anthony.minessale@gmail.com</a>> wrote:<br>
>>> if you use mod_xml_cdr you will get 1 cdr report in it's own file per call.<br>
>>><br>
>>> Each time the call is transferred it's documented and the call flow is<br>
>>> expanded so you should be satisfied with it.<br>
>>><br>
>> Hi There,<br>
>><br>
>> I was able to test transfer CDRs with freeswitch and encountered<br>
>> similar issues to those I've had with Asterisk<br>
>> (<a href="http://bugs.digium.com/view.php?id=11849" target="_blank">http://bugs.digium.com/view.php?id=11849</a>).<br>
>><br>
>> In Freeswitch's case the blind transfer CDR problem is the same as<br>
>> Asterisk's. If you call a billable destination through the server and<br>
>> then do a blind transfer (REFER) to another billable destination you<br>
>> get left with a call that has two billable legs but you will only get<br>
>> one CDR.<br>
>><br>
>> With attended transfers Freeswitch generates a CDR for the first call<br>
>> leg when the transfer occurs and a CDR for the second call leg when<br>
>> the call ends except that the destination on the second call leg is<br>
>> incorrect and has been modified to be the callerid of the first<br>
>> caller. It should be generating the CDRs for both call legs when the<br>
>> call ends and not when the transfer occurs. I also got an extra CDR<br>
>> quite a while after the transferred call had hung up with a<br>
>> disposition of "RECOVERY_ON_TIMER_EXPIRE" with a destination<br>
>> corresponding to the second call leg.<br>
>><br>
>> This whole transfer/CDR thing is very unsexy and a pain for developers<br>
>> but it's a critical thing for those of us that run businesses<br>
>> supplying telephony services. This one issue has cost the company I<br>
>> work for an amount into 4 figures.<br>
>><br>
>> Regards,<br>
>><br>
>> Greyman.<br>
>><br>
>> _______________________________________________<br>
>> Freeswitch-users mailing list<br>
>> <a href="mailto:Freeswitch-users@lists.freeswitch.org">Freeswitch-users@lists.freeswitch.org</a><br>
>> <a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
>> UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
>> <a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
>><br>
><br>
<br>
--<br>
Faraz R Khan<br>
Chief Architect<br>
Emergen Consulting Pvt Ltd<br>
+92.21.529.0381 x200<br>
<a href="http://www.emergen.biz" target="_blank">www.emergen.biz</a><br>
<br>
<br>
_______________________________________________<br>
Freeswitch-users mailing list<br>
<a href="mailto:Freeswitch-users@lists.freeswitch.org">Freeswitch-users@lists.freeswitch.org</a><br>
<a href="http://lists.freeswitch.org/mailman/listinfo/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/listinfo/freeswitch-users</a><br>
UNSUBSCRIBE:<a href="http://lists.freeswitch.org/mailman/options/freeswitch-users" target="_blank">http://lists.freeswitch.org/mailman/options/freeswitch-users</a><br>
<a href="http://www.freeswitch.org" target="_blank">http://www.freeswitch.org</a><br>
</blockquote></div><br><br clear="all"><br>-- <br>Anthony Minessale II<br><br>FreeSWITCH <a href="http://www.freeswitch.org/">http://www.freeswitch.org/</a><br>ClueCon <a href="http://www.cluecon.com/">http://www.cluecon.com/</a><br>
<br>AIM: anthm<br><a href="mailto:MSN%3Aanthony_minessale@hotmail.com">MSN:anthony_minessale@hotmail.com</a><br>GTALK/JABBER/<a href="mailto:PAYPAL%3Aanthony.minessale@gmail.com">PAYPAL:anthony.minessale@gmail.com</a><br>
IRC: <a href="http://irc.freenode.net">irc.freenode.net</a> #freeswitch<br><br>FreeSWITCH Developer Conference<br><a href="mailto:sip%3A888@conference.freeswitch.org">sip:888@conference.freeswitch.org</a><br><a href="http://iax:guest@conference.freeswitch.org/888">iax:guest@conference.freeswitch.org/888</a><br>
<a href="mailto:googletalk%3Aconf%2B888@conference.freeswitch.org">googletalk:conf+888@conference.freeswitch.org</a><br>pstn:213-799-1400