asterisk users - May 2018 - Dial to FastAGI application appears as 1-second CDR - how do I fix?

In my application, I am using AMI to run an Originate command between a channel
and a dialplan application (NOT a context). In my case, the application I want
to invoke is FastAGI. The Originate AMI command works correctly, but Asterisk
generates a very
short (0-1s) duration for the CDR that results from this call, regardless of the
time spent running the FastAGI application. I want the CDR duration to reflect
the time spent in the entirety of the call, as is normal for ordinary calls.
What should I do? I
am running Asterisk 11.25.3 .

In article <3a005ff6-19a4-215b-4751-bee616ec74e6 at palosanto.com>,
Alex Villací­s Lasso <a_villacis at palosanto.com>
wrote:
> In my application, I am using AMI to run an Originate command between a
channel and a dialplan application (NOT a
> context). In my case, the application I want to invoke is FastAGI. The
Originate AMI command works correctly, but
> Asterisk generates a very 
> short (0-1s) duration for the CDR that results from this call, regardless
of the time spent running the FastAGI
> application. I want the CDR duration to reflect the time spent in the
entirety of the call, as is normal for ordinary
> calls. What should I do? I 
> am running Asterisk 11.25.3 .
Are you using Local channels as the target channel?

I found what I believe is an issue with CDR handling when masquerading Local
channels, when I ported
one of my old applications from Asterisk 1.2.32 to 11.25.3. It was recording an
incorrect CDR
for the setup part of the call, and none for the answered part. In 1.2.32 I was
getting two CDRs,
one for the setup part and another for the answered part.

I eventually tracked it down to ast_do_masquerade() in channel.c, and made the
following change,
which corrected the CDR behaviour back to the same as what Asterisk 1.2 had
done:

$ diff -u --show-c-function channel.c.orig channel.c
--- channel.c.orig      2017-09-19 17:03:38.000000000 +0100
+++ channel.c   2018-05-29 11:13:41.000000000 +0100
@@ -6864,7 +6864,9 @@ int ast_do_masquerade(struct ast_channel
        } exchange;
        struct ast_channel *clonechan, *chans[2];
        struct ast_channel *bridged;
+#ifdef I_THINK_THIS_IS_WRONG /* Tony Mountifield, 2018-03-29. Removing this
code fixes lost CDRs with masquerade */
        struct ast_cdr *cdr;
+#endif
        struct ast_datastore *xfer_ds;
        struct xfer_masquerade_ds *xfer_colp;
        struct ast_format rformat;
@@ -7035,10 +7037,12 @@ int ast_do_masquerade(struct ast_channel
        ast_channel_tech_pvt_set(original, ast_channel_tech_pvt(clonechan));
        ast_channel_tech_pvt_set(clonechan, t_pvt);

+#ifdef I_THINK_THIS_IS_WRONG /* Tony Mountifield, 2018-03-29. Removing this
code fixes lost CDRs with masquerade */
        /* Swap the cdrs */
        cdr = ast_channel_cdr(original);
        ast_channel_cdr_set(original, ast_channel_cdr(clonechan));
        ast_channel_cdr_set(clonechan, cdr);
+#endif

        /* Swap the alertpipes */
        ast_channel_internal_alertpipe_swap(original, clonechan);
$

I didn't research what version this change appeared in, nor whether it has
been subsequently fixed in
later versions of Asterisk. There was no point reporting it in Asterisk 11, as
that was out of LTS
by the time I discovered it.

So you could try making the above changes to channel.c and see if it improves
the CDRs for you.

Cheers
Tony

-- 
Tony Mountifield
Work: tony at softins.co.uk - http://www.softins.co.uk
Play: tony at mountifield.org - http://tony.mountifield.org

El 29/05/18 a las 05:24, Tony Mountifield escribió:
> In article <3a005ff6-19a4-215b-4751-bee616ec74e6 at palosanto.com>,
> Alex Villací­s Lasso <a_villacis at palosanto.com> wrote:
>> In my application, I am using AMI to run an Originate command between a
channel and a dialplan application (NOT a
>> context). In my case, the application I want to invoke is FastAGI. The
Originate AMI command works correctly, but
>> Asterisk generates a very
>> short (0-1s) duration for the CDR that results from this call,
regardless of the time spent running the FastAGI
>> application. I want the CDR duration to reflect the time spent in the
entirety of the call, as is normal for ordinary
>> calls. What should I do? I
>> am running Asterisk 11.25.3 .
> Are you using Local channels as the target channel?
Yes, this is the standard way my application works.
>
> I found what I believe is an issue with CDR handling when masquerading
Local channels, when I ported
> one of my old applications from Asterisk 1.2.32 to 11.25.3. It was
recording an incorrect CDR
> for the setup part of the call, and none for the answered part. In 1.2.32 I
was getting two CDRs,
> one for the setup part and another for the answered part.
>
> I eventually tracked it down to ast_do_masquerade() in channel.c, and made
the following change,
> which corrected the CDR behaviour back to the same as what Asterisk 1.2 had
done:
>
> $ diff -u --show-c-function channel.c.orig channel.c
> --- channel.c.orig      2017-09-19 17:03:38.000000000 +0100
> +++ channel.c   2018-05-29 11:13:41.000000000 +0100
> @@ -6864,7 +6864,9 @@ int ast_do_masquerade(struct ast_channel
>          } exchange;
>          struct ast_channel *clonechan, *chans[2];
>          struct ast_channel *bridged;
> +#ifdef I_THINK_THIS_IS_WRONG /* Tony Mountifield, 2018-03-29. Removing
this code fixes lost CDRs with masquerade */
>          struct ast_cdr *cdr;
> +#endif
>          struct ast_datastore *xfer_ds;
>          struct xfer_masquerade_ds *xfer_colp;
>          struct ast_format rformat;
> @@ -7035,10 +7037,12 @@ int ast_do_masquerade(struct ast_channel
>          ast_channel_tech_pvt_set(original,
ast_channel_tech_pvt(clonechan));
>          ast_channel_tech_pvt_set(clonechan, t_pvt);
>
> +#ifdef I_THINK_THIS_IS_WRONG /* Tony Mountifield, 2018-03-29. Removing
this code fixes lost CDRs with masquerade */
>          /* Swap the cdrs */
>          cdr = ast_channel_cdr(original);
>          ast_channel_cdr_set(original, ast_channel_cdr(clonechan));
>          ast_channel_cdr_set(clonechan, cdr);
> +#endif
>
>          /* Swap the alertpipes */
>          ast_channel_internal_alertpipe_swap(original, clonechan);
> $
>
> I didn't research what version this change appeared in, nor whether it
has been subsequently fixed in
> later versions of Asterisk. There was no point reporting it in Asterisk 11,
as that was out of LTS
> by the time I discovered it.
>
> So you could try making the above changes to channel.c and see if it
improves the CDRs for you.
>
> Cheers
> Tony
>
I will try doing this change and recompiling to see what happens.