[asterisk-bugs] [JIRA] (ASTERISK-29166) CDR_PROP, setting party_a, and expectations

Ross Beer (JIRA) noreply at issues.asterisk.org
Thu Jun 24 10:23:33 CDT 2021


    [ https://issues.asterisk.org/jira/browse/ASTERISK-29166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=255458#comment-255458 ] 

Ross Beer commented on ASTERISK-29166:
--------------------------------------

Revisiting this, could a CDR_PROP option be added to keep the CDR 'open' and accounting 'end' time based on the 'party_b' channel lifetime. Therefore only finalise the CDR once the 'party_b' channel has hung up. A lock would also be handy to not update any of the data within the CDR apart from 'end' time.

Having this feature would resolve issues with CDRs created when a call transfer happens and ends both of the potentially chargeable CDRs along time before the channels are hung up.

Looking at the code, not totally understanding the logic, if 'CDR_PROP(party_a)' was set on the outgoing channel should this be taken into consideration here:

{noformat}
/*!
 * \brief Check to see if a CDR needs to move to the finalized state because
 * its Party A hungup.
 */
static void cdr_object_check_party_a_hangup(struct cdr_object *cdr)
{
	if (ast_test_flag(&cdr->party_a.snapshot->softhangup_flags, AST_SOFTHANGUP_HANGUP_EXEC)
		&& is_cdr_flag_set(CDR_END_BEFORE_H_EXTEN)) {
		cdr_object_finalize(cdr);
	}

	if (ast_test_flag(&cdr->party_a.snapshot->flags, AST_FLAG_DEAD)
		&& cdr->fn_table != &finalized_state_fn_table) {
		cdr_object_transition_state(cdr, &finalized_state_fn_table);
	}
}
{noformat}

Could the above be modified to only call 'cdr_object_finalize(cdr);' if both channels are hung up?

> CDR_PROP, setting party_a, and expectations
> -------------------------------------------
>
>                 Key: ASTERISK-29166
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29166
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: CDR/General, Functions/func_cdr
>    Affects Versions: 16.14.1, 18.0.1
>            Reporter: Kevin Harwell
>            Severity: Trivial
>
> The [CDR_PROP|https://wiki.asterisk.org/wiki/display/AST/Asterisk+18+Function_CDR_PROP] function seemingly allows one to specify which channel is to be _party_a_. However in practice this does not seem to be the case. Or at least it allows picking in such a limited capacity to be of almost no use. 
> So this is kind of a two-parter:
> 1) Figure out the use case(s) for when _party_a_ can be set via the function, and actually effect a record. If found then update the documentation. If possible fix any bugs related to setting _party_a_ on a given channel.
> 2) Potentially make it so setting _party_a_ using the function overrides even the dialer/dialed.
> To the second part, that's more of a new feature and after some preliminary code perusal possibly quite invasive. As is, a dialing channel is always _party_a_ and the dialed channel is _party_b_. In order to override this behavior one would have to "swap" the _party_a_ and _party_b_ snapshots on the cdr structure. Finding the various places to do that is not trivial, and a basic swap probably has unforeseen circumstances (we are talking about CDRs here after all).
> As a side note, I put Asterisk 12.0.0. as an affected version since it seems like things have been this way since the rewrite.
> Current CDR "spec":
> https://wiki.asterisk.org/wiki/display/AST/Asterisk+12+CDR+Specification



--
This message was sent by Atlassian JIRA
(v6.2#6252)



More information about the asterisk-bugs mailing list