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 <[EMAIL PROTECTED]> 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 > >> <[EMAIL PROTECTED]> 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 > >> [email protected] > >> 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 > [email protected] > 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:[EMAIL PROTECTED] <[EMAIL PROTECTED]> GTALK/JABBER/PAYPAL:[EMAIL PROTECTED]<[EMAIL PROTECTED]> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:[EMAIL PROTECTED] <[EMAIL PROTECTED]> iax:[EMAIL PROTECTED]/888 googletalk:[EMAIL PROTECTED]<[EMAIL PROTECTED]> pstn:213-799-1400
_______________________________________________ Freeswitch-users mailing list [email protected] http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
