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

[Ross Beer (JIRA)]

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

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

Sean thank you for submitting a patch to fixed the 'party a' setting. After testing this still doesn't appear to set the outbound channel to 'party a' as the code appears to prefer the dialled channel to only ever be 'party b'.

The issue asterisk currently has with CDRs is that the 'party b' channel is often the chargeable call, however when a transfer occurs the CDR is ended too soon and therefore it is not possible to account for the whole call length as the following CDRs are corrupt and contain no data about the original calls. This is made worse if two outbound call legs are transfers to each other. This could be classed as a vulnerability in asterisk and present in FreePBX.

Therefore reading documentation the 'party a' feature should be the way around the above issue, if the 'b' channel is set as the master the CDR should continue until the 'b' channel is hung up instead of the 'a' channel which is the default behaviour.

> 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)