How to tell if there is a transfer from CDR?

Is there any way to know if a call was transferred from reading the
CDR? Any relation in fields like UNIQUEID? Something that can be
scripted to make a special report?

5 Responses to “How to tell if there is a transfer from CDR?”

  1. C F said:

    Sep 04, 10 at 10:53 pm

    Last time I analyzed this (I believe back in 1.2) there was no way of
    telling. However a blind transfered call would generate 2 CDR
    recoreds:
    1. For the part of the call with the transferrer and transfered.
    2. For the part of the call with the transferee and transfered.
    The call duration for the 2nd record would include the time of the 1st
    record as well. So if part one took 20 seconds and part 2 40 seconds,
    then the 2nd record would have 60 seconds as billable.
    The only workaround was to check the BLINDTRANSFER var and reset cdr
    if it was populated.

    Please members of this list, I would love to hear more input as I’m
    sure this has changed. Also I would not be surprised that I’m wrong in
    my analysis as more than 4 years has passed since and I might have
    forgotten.

    TIA

  2. Nic Colledge said:

    Sep 05, 10 at 8:12 am

    Hi,
    I use CEL or Call Event Logging in 1.8 to get a more concise picture of what happened in a call. We use it for a bunch of stuff including billing attended and unattended transfers differently.
    If you are thinking of upgrading, it’s worth a try.
    Nic.

  3. "Bryant Zimmerman" said:

    Sep 05, 10 at 4:39 pm

    On blind transfers I believe the two cdr’s have the same unique id . On attended transfers there is no real way I have found to address this issue. CDR’s with transfers really suck the way they are right now. On blind transfers you can do some flagging of the second CDR by checking in your dialing contexts to confirm it is a blind transfer ${BLINDTRANSFER}. On attended transfers you are just out of luck. You have to sort them out with CDR’s. This cost us some money with inbound toll free calls because we did not know this occurred this way for some time.

    Bryant

  4. "Bryant Zimmerman" said:

    Sep 05, 10 at 4:51 pm

    Nic

    How stable is 1.8 really? It sounds like you are running it in production is this the case? CDR Transfer issues and rfc2833 DTMF issues are hitting us hard with 1.6.2.x. We want to move as soon as 1.8 is stable enough.

    Thanks
    Bryant

  5. Nic Colledge said:

    Sep 05, 10 at 8:28 pm

    Bryant,

    We have been using a pre-1.8 trunk version of asterisk that has been pretty stable for us. We have a fairly small user base currently and decided to take the risk with a trunk version after some testing basically because of the availability of CEL as it lets us do a bunch of things we couldn’t do with 1.6 CDR.

    I have briefly tested the beta3 of 1.8 and it seemed ok but were holding off for the release version (with a if it ain’t broke don’t fix it mentality).

    In our environment and my limited experience 1.8 is shaping up to be a great release (Great work guys, thanks to everyone working on asterisk!) I recommend you fire it up somewhere to test and see if you still have the issues, CEL can be pretty verbose and confusing at first but it does give you a lot more information about what happened during a call and when. On the other hand you may see it working and decide it’s not for you.

    As for DTMF we only have a few IVR Menu style interfaces that don’t currently see much use so I can’t really give a definitive answer, but we have not had any problems with it.

    Worst case scenario, you test it and find some problems. I can’t speak for the developers, but while it’s in beta, now’s the time to find them!

    Regards,
    Nic.

    href=”mailto:asterisk-users-bounces@lists.digium.com”>asterisk-users-bounces@lists.digium.com [mailto:asterisk-users-bounces@lists.digium.com] On Behalf Of Bryant Zimmerman
    Sent: 05 September 2010 21:51

    Nic

    How stable is 1.8 really? It sounds like you are running it in production is this the case? CDR Transfer issues and rfc2833 DTMF issues are hitting us hard with 1.6.2.x. We want to move as soon as 1.8 is stable enough.

    Thanks
    Bryant
    ________________________________
    Hi,
    I use CEL or Call Event Logging in 1.8 to get a more concise picture of what happened in a call. We use it for a bunch of stuff including billing attended and unattended transfers differently.
    If you are thinking of upgrading, it’s worth a try.
    Nic.