Try enabling b legs in the xml_cdr <param name="log-b-leg" value="true"/> On Wed, Jul 9, 2008 at 9:35 AM, Faraz R. Khan <faraz.khan@emergen.biz> wrote:
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 <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
_______________________________________________ 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 <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400