[asterisk-bugs] [JIRA] (ASTERISK-21697) Bridge API Enhancements - handle Local Channel Optimization in CDRs

Matt Jordan (JIRA) noreply at issues.asterisk.org
Wed Jul 3 14:27:03 CDT 2013


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

Matt Jordan commented on ASTERISK-21697:
----------------------------------------

After some discussion, this actually is a bad idea.

If we attempt to 'fix up' the Local channels in CDRs, we're inevitably going to remove some records. If we remove records, we're going to create a situation in which we've destroyed someone's CDR that they cared about.

Take, for example, the case of a Local channel origination that outbound dials two channels. In that situation, you will have:

|| Party A || Party B ||
| L;1 | foo |
| L;2 | bar |

Here, we can't really do anything: foo and bar are both dialed, and hence need to be Party B. When foo and bar get pushed into the same bridge one will inevitably become the party A and the other the party B. Removing these records will remove any information that occurred while the Local channel executed, so removing them isn't ideal either.

This feels fraught with peril.

As an aside, in Asterisk 11 and below, the optimization of local channels was not represented in the CDRs - so *not* doing anything here is more consistent with behavior today.
                
> Bridge API Enhancements - handle Local Channel Optimization in CDRs
> -------------------------------------------------------------------
>
>                 Key: ASTERISK-21697
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-21697
>             Project: Asterisk
>          Issue Type: Improvement
>          Components: CDR/General, Core/Bridging
>            Reporter: Matt Jordan
>            Assignee: Matt Jordan
>              Labels: Asterisk12
>
> When a Local Channel Optimization occurs, we have to update the affected CDR records accordingly. In particular, we have to:
> * For each record where a Local channel is the Party B, update the Party B information with the Party B where the other Local channel half is the Party A.
> ** If the Local channel half is the Party A, do nothing.
> ** If the other Local channel half is not a Party A, do nothing.
> * If we merged, remove any affected records.
> Consider the following scenarios:
> *Two Party Merge:*
> A <-> Local;1 <-> Local;2 <-> B
> *Scenario 1:*
> A,Local;1
> Local;2,B
> After the optimization and merge, we should have:
> A,B
> *Scenario 2*:
> A,Local;1
> B,Local;2
> After the optimization and merge, we should have:
> A,Local;1
> B,Local;2
> A,B
> *Scenario 3*:
> Local;1,A
> Local;2,B
> After the optimization and merge, we should have:
> Local;1,A
> Local;2,B
> A,B

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.asterisk.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



More information about the asterisk-bugs mailing list