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

Frankie Chin (JIRA) noreply at issues.asterisk.org
Mon Aug 11 21:10:28 CDT 2014


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

Frankie Chin commented on ASTERISK-24208:
-----------------------------------------

The screenshot I attached didn't show up, so I copied 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
>            Severity: Critical
>
> 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 attached screen shot).
> 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.
> The AMI Originate Action:
> Action: Originate
> Channel: IAX2/vm0/1000
> Exten: 1000
> Priority: 1
> Context: conference
> Async: true
> CallerID: AMI
> The dial plan at the physical asterisk looks like this:
> [conference]
> exten => _XXXX,1,NoOp(CallerID: ${CALLERID(all)})
> exten => _XXXX,n,ConfBridge(${EXTEN},,,conf_menu)
> The dial plan at the virtual asterisk looks like this:
> [internal]
> exten => _1XXX,n,Answer
> exten => _1XXX,n,NoOp(CallerID: ${CALLERID(all)})
> exten => _1XXX,n,Wait(180)
> exten => _1XXX,n,Hangup()



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



More information about the asterisk-bugs mailing list