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