[asterisk-bugs] [JIRA] (ASTERISK-24208) Channels with CDR Information Remain Active Even After ConfBrige Is Ended

Tue Aug 26 15:33:29 CDT 2014

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

Rusty Newton edited comment on ASTERISK-24208 at 8/26/14 3:31 PM:
------------------------------------------------------------------

The screenshot I attached didn't show up, so I copied a portion of the CLI console output after running the "cdr set debug on" command here...

[Edit by Rusty - Trimmed excessive inline debug and added noformat tags]
 {noformat}
 0xb4582df4 - Created CDR for channel IAX2/vm1-16680
 0xb4582df4 - Transitioning CDR for IAX2/vm1-16680 from state NONE to Single
 0xb4582df4 - Set answered time to 1407807886.152873
 0xb4582df4 - Transitioning CDR for IAX2/vm1-16680 from state Single to Bridged
 0xb4582df4 - Party A IAX2/vm1-16680 has new Party B IAX2/vm17-23455
 0xb458327c - Created CDR for channel IAX2/vm1-16680
 0xb458327c - Transitioning CDR for IAX2/vm1-16680 from state NONE to Single
 0xb458327c - Set answered time to 1407807886.155718
 0xb458327c - Transitioning CDR for IAX2/vm1-16680 from state Single to Bridged
 0xb458327c - Party A IAX2/vm1-16680 has new Party B IAX2/vm17-23455
{noformat}

was (Author: fchin):
The screenshot I attached didn't show up, so I copied a portion of the CLI console output after running the "cdr set debug on" command here...

 0xb457f8f4 - Created CDR for channel IAX2/vm1-16680
 0xb457f8f4 - Transitioning CDR for IAX2/vm1-16680 from state NONE to Single
 0xb457f8f4 - Set answered time to 1407807886.111611
 0xb457f8f4 - Transitioning CDR for IAX2/vm1-16680 from state Single to Bridged
 0xb457f8f4 - Party A IAX2/vm1-16680 has new Party B IAX2/vm17-23455
 0xb457fba4 - Created CDR for channel IAX2/vm1-16680
 0xb457fba4 - Transitioning CDR for IAX2/vm1-16680 from state NONE to Single
 0xb457fba4 - Set answered time to 1407807886.114735
 0xb457fba4 - Transitioning CDR for IAX2/vm1-16680 from state Single to Bridged
 0xb457fba4 - Party A IAX2/vm1-16680 has new Party B IAX2/vm17-23455
 0xb458002c - Created CDR for channel IAX2/vm1-16680
 0xb458002c - Transitioning CDR for IAX2/vm1-16680 from state NONE to Single
 0xb458002c - Set answered time to 1407807886.118052
 0xb458002c - Transitioning CDR for IAX2/vm1-16680 from state Single to Bridged
 0xb458002c - Party A IAX2/vm1-16680 has new Party B IAX2/vm17-23455
 0xb45804b4 - Created CDR for channel IAX2/vm1-16680
 0xb45804b4 - Transitioning CDR for IAX2/vm1-16680 from state NONE to Single
 0xb45804b4 - Set answered time to 1407807886.120549
 0xb45804b4 - Transitioning CDR for IAX2/vm1-16680 from state Single to Bridged
 0xb45804b4 - Party A IAX2/vm1-16680 has new Party B IAX2/vm17-23455
 0xb458093c - Created CDR for channel IAX2/vm1-16680
 0xb458093c - Transitioning CDR for IAX2/vm1-16680 from state NONE to Single
 0xb458093c - Set answered time to 1407807886.124263
 0xb458093c - Transitioning CDR for IAX2/vm1-16680 from state Single to Bridged
 0xb458093c - Party A IAX2/vm1-16680 has new Party B IAX2/vm17-23455
 0xb4581574 - Created CDR for channel IAX2/vm1-16680
 0xb4581574 - Transitioning CDR for IAX2/vm1-16680 from state NONE to Single
 0xb4581574 - Set answered time to 1407807886.127040
 0xb4581574 - Transitioning CDR for IAX2/vm1-16680 from state Single to Bridged
 0xb4581574 - Party A IAX2/vm1-16680 has new Party B IAX2/vm17-23455
 0xb4580dc4 - Created CDR for channel IAX2/vm1-16680
 0xb4580dc4 - Transitioning CDR for IAX2/vm1-16680 from state NONE to Single
 0xb4580dc4 - Set answered time to 1407807886.130517
 0xb4580dc4 - Transitioning CDR for IAX2/vm1-16680 from state Single to Bridged
 0xb4580dc4 - Party A IAX2/vm1-16680 has new Party B IAX2/vm17-23455
 0xb458124c - Created CDR for channel IAX2/vm1-16680
 0xb458124c - Transitioning CDR for IAX2/vm1-16680 from state NONE to Single
 0xb458124c - Set answered time to 1407807886.134551
 0xb458124c - Transitioning CDR for IAX2/vm1-16680 from state Single to Bridged
 0xb458124c - Party A IAX2/vm1-16680 has new Party B IAX2/vm17-23455
 0xb4581bd4 - Created CDR for channel IAX2/vm1-16680
 0xb4581bd4 - Transitioning CDR for IAX2/vm1-16680 from state NONE to Single
 0xb4581bd4 - Set answered time to 1407807886.138653
 0xb4581bd4 - Transitioning CDR for IAX2/vm1-16680 from state Single to Bridged
 0xb4581bd4 - Party A IAX2/vm1-16680 has new Party B IAX2/vm17-23455
 0xb458205c - Created CDR for channel IAX2/vm1-16680
 0xb458205c - Transitioning CDR for IAX2/vm1-16680 from state NONE to Single
 0xb458205c - Set answered time to 1407807886.142713
 0xb458205c - Transitioning CDR for IAX2/vm1-16680 from state Single to Bridged
 0xb458205c - Party A IAX2/vm1-16680 has new Party B IAX2/vm17-23455
 0xb45824e4 - Created CDR for channel IAX2/vm1-16680
 0xb45824e4 - Transitioning CDR for IAX2/vm1-16680 from state NONE to Single
 0xb45824e4 - Set answered time to 1407807886.145505
 0xb45824e4 - Transitioning CDR for IAX2/vm1-16680 from state Single to Bridged
 0xb45824e4 - Party A IAX2/vm1-16680 has new Party B IAX2/vm17-23455
 0xb458296c - Created CDR for channel IAX2/vm1-16680
 0xb458296c - Transitioning CDR for IAX2/vm1-16680 from state NONE to Single
 0xb458296c - Set answered time to 1407807886.149228
 0xb458296c - Transitioning CDR for IAX2/vm1-16680 from state Single to Bridged
 0xb458296c - Party A IAX2/vm1-16680 has new Party B IAX2/vm17-23455
 0xb4582df4 - Created CDR for channel IAX2/vm1-16680
 0xb4582df4 - Transitioning CDR for IAX2/vm1-16680 from state NONE to Single
 0xb4582df4 - Set answered time to 1407807886.152873
 0xb4582df4 - Transitioning CDR for IAX2/vm1-16680 from state Single to Bridged
 0xb4582df4 - Party A IAX2/vm1-16680 has new Party B IAX2/vm17-23455
 0xb458327c - Created CDR for channel IAX2/vm1-16680
 0xb458327c - Transitioning CDR for IAX2/vm1-16680 from state NONE to Single
 0xb458327c - Set answered time to 1407807886.155718
 0xb458327c - Transitioning CDR for IAX2/vm1-16680 from state Single to Bridged
 0xb458327c - Party A IAX2/vm1-16680 has new Party B IAX2/vm17-23455

> Channels with CDR Information Remain Active Even After ConfBrige Is Ended
> -------------------------------------------------------------------------
>
>                 Key: ASTERISK-24208
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-24208
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Applications/app_confbridge
>    Affects Versions: 13.0.0-beta1
>         Environment: Ubuntu 10.04
>            Reporter: Frankie Chin
>            Assignee: Matt Jordan
>            Severity: Critical
>         Attachments: full, leaked_skewed.7z.001
>
>
> I have one Asterisk running on a physical Ubuntu machine, and 20 other Asterisks running on virtual Ubuntu machines. The virtual Asterisks are registered to the physical Asterisk using IAX. 
> AMI is used to originate calls to all the virtual Asterisks and join them into a conference bridge hosted in the physical Asterisk. Once all the participants join the conference, the physical Asterisk will be taking up close 90% of the CPU usage.
> The real concern is that.... even after ending the conference (using "confbridge kick [ID] all" CLI command), the channels with CDR information will still remain active (as indicated by the "cdr show active" command). Also, the physical Asterisk will still be taking 90% of the CPU usage. If I type the "cdr set debug on" in the CLI console, the screen will be loaded with seemingly endless loop of activities (Please see my comment).
> This issue was first found when I was using Asterisk Version 12. I just tested it using Version 13 Beta 1 and the problem persists. Note: If I only invite 10 virtual Asterisks into the conference, then everything seems to be very normal, i.e. CPU is around 1%, all the channels are cleared after the conference is ended. 
> The AMI Originate Action (for one virtual Asterisk):
> Action: Originate
> Channel: IAX2/vm1/1001
> Exten: 1
> Priority: 1
> Context: conference
> Async: true
> CallerID: AMI
> The dial plan at the physical asterisk looks like this:
> [conference]
> exten => 1,1,ConfBridge(1234,,,conf_menu)
> The dial plan at the virtual asterisk looks like this:
> [internal]
> exten => 1001,1,Answer
> exten => 1001,n,Wait(180)
> exten => 1001,n,Hangup()

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