[Freeswitch-users] Transfer CDRs: Problem scenario

[Faraz R. Khan]

Amazing! Why didnt I see that? :)

Beautiful CDRs in my mysql DB. Simplistic call panel with call tracing 
coming up in a few days!

Might want to enable that by default to auto-impress new comers!



Anthony Minessale wrote:
> 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 at emergen.biz 
> <mailto:faraz.khan at 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 at gmail.com
>     <mailto:anthony.minessale at 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 at lists.freeswitch.org
>     <mailto:Freeswitch-users at 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 <http://www.emergen.biz>
> 
> 
>     _______________________________________________
>     Freeswitch-users mailing list
>     Freeswitch-users at lists.freeswitch.org
>     <mailto:Freeswitch-users at 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 at hotmail.com 
> <mailto:MSN%3Aanthony_minessale at hotmail.com>
> GTALK/JABBER/PAYPAL:anthony.minessale at gmail.com 
> <mailto:PAYPAL%3Aanthony.minessale at gmail.com>
> IRC: irc.freenode.net <http://irc.freenode.net> #freeswitch
> 
> FreeSWITCH Developer Conference
> sip:888 at conference.freeswitch.org 
> <mailto:sip%3A888 at conference.freeswitch.org>
> iax:guest at conference.freeswitch.org/888 
> <http://iax:guest@conference.freeswitch.org/888>
> googletalk:conf+888 at conference.freeswitch.org 
> <mailto:googletalk%3Aconf%2B888 at conference.freeswitch.org>
> pstn:213-799-1400
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Freeswitch-users mailing list
> Freeswitch-users at 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