[asterisk-bugs] [JIRA] (ASTERISK-16330) No CDRs after AMI Redirect

[Matt Jordan (JIRA)]

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

Matt Jordan commented on ASTERISK-16330:
----------------------------------------

I've confirmed that this is still a problem in Asterisk 11 using the AMI Redirect Action. Using the following dialplan:

{noformat}
[ Context 'contextB' created by 'pbx_config' ]
  's' =>            1. NoOp(I'm contextB)                         [pbx_config]
                    2. Set(CDR(accountcode)=B)                    [pbx_config]
                    3. Wait(3)                                    [pbx_config]
                    4. Answer()                                   [pbx_config]
                    5. PlayBack(silence/3)                        [pbx_config]
                    6. Hangup()                                   [pbx_config]

[ Context 'contextA' created by 'pbx_config' ]
  's' =>            1. NoOp(I'm contextA)                         [pbx_config]
                    2. Dial(Local/s at contextB/n)                   [pbx_config]

[ Context 'wait' created by 'pbx_config' ]
  's' =>            1. NoOp()                                     [pbx_config]
                    2. Wait(50000)                                [pbx_config]
{noformat}

I originated a Local channel into {{Local/s at wait}}, then performed an AMI Redirect on the resulting {{;2}} of the channel pair to {{s at contextA}}. This resulted in the following CDRs:

{noformat}
"","","s","wait","","Local/s at wait-00000000;1","","Echo","","2015-02-26 15:05:52","2015-02-26 15:06:16","2015-02-26 15:06:17",25,1,"ANSWERED","DOCUMENTATION","1424963152.0",""
"B","","s","contextB","","Local/s at contextB-00000001;2","","Hangup","","2015-02-26 15:06:13","2015-02-26 15:06:16","2015-02-26 15:06:20",7,4,"ANSWERED","DOCUMENTATION","1424963173.3",""
{noformat}

Note that there is no CDR for the {{Local/s at wait-00000000;2}} that Dialled {{Local/s at contextB-00000001;1}}.

Testing with Asterisk 13, however, this is no longer a problem. Using the same setup, I get the following CDRs:

{noformat}
"B","","s","contextB",""""" <>","Local/s at contextB-00000002;2","","Hangup","","2015-02-26 15:04:05","2015-02-26 15:04:08","2015-02-26 15:04:12",6,3,"ANSWERED","DOCUMENTATION","1424963045.5",""
"","","s","wait",""""" <>","Local/s at wait-00000001;1","","Echo","","2015-02-26 15:03:46","2015-02-26 15:04:08","2015-02-26 15:04:12",25,3,"ANSWERED","DOCUMENTATION","1424963026.2",""
"","","s","contextA",""""" <>","Local/s at wait-00000001;2","Local/s at contextB-00000002;1","Dial","Local/s at contextB/n","2015-02-26 15:03:46","2015-02-26 15:04:08","2015-02-26 15:04:12",25,3,"ANSWERED","DOCUMENTATION","1424963026.3",""
{noformat}

Note that here, we see the relationship between {{Local/s at wait-00000001;2}} and {{Local/s at contextB-00000002;1}}.

While this is a bug in Asterisk 11, CDRs - particularly in the interaction with channel masquerades (which is what occurs when the Redirect happens) - are *extremely* temperamental and prone to failure. Attempting to fix this code in 11 would certainly break CDRs in other masquerade scenarios, such as SIP initiated blind/attended transfers. The risk is extremely high that attempting to fix this issue in that branch would only cause additional problems.

Since this was fixed by the great CDR re-write in Asterisk 12, I'm going to close this issue out as Fixed in that version.

> No CDRs after AMI Redirect
> --------------------------
>
>                 Key: ASTERISK-16330
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-16330
>             Project: Asterisk
>          Issue Type: Bug
>          Components: CDR/General
>            Reporter: postkonform
>            Severity: Minor
>      Target Release: 12.0.0
>
>         Attachments: ZipZoneAsteriskDebugLog
>
>
> When using the Goto app no CDR is written if the call was answered. 
> If the call fails or is not answered a CDR is written.
> We use the AMI to check a self made prepaid deposit if enough credit is left. If so we use the Redirect action to redirect the channel to another context named initCall where a Dial app establishes the call, so we can not use the Gosub app where this problem does not occur (The Redirect action seems to use Goto). 
> We tested it without the AMI. In this case we used the Goto directly to send incoming calls to the initCall context and the same error occurs. If we use Gosub it does not occur. 
> Another interesting thing could be, that if we redirect to another context where a Playback app will be started a CDR is written (in our case this will happen if no credit is left) 
> The CDR is neither written to CSV nor to MySQL.
> *ADDITIONAL INFORMATION*
> {{extensions.conf:}}
> ...
> {noformat}
> [Sip-Out]
> exten => _.,1,Set(NR=${EXTEN})
> exten => _.,2,Wait(100)
> ;A Java program which listens on the AMI redirects to initCall if credit is
> ;left on the user deposit, otherwise it redirects to noCredit
> [initCall]
> exten => s,1,Dial(SIP/${NR},,M(Timeout))
> [macro-Timeout]
> exten => s,1,Set(TIMEOUT(absolute)=16)
> [noCredit]
> exten => s,1,Playback(demo-nogo)
> {noformat}
> ...
> We only modified sip.conf, extensions.conf, manager.conf and cdr_mysql.conf
> We are using asterisk-1.6.2.9, asterisk-addons-1.6.2.1 on centos-release-5-5.el5.centos.
> rpm -q centos-release uname -a:
> Linux voip 2.6.24-11-pve #1 SMP PREEMPT Fri May 14 09:28:08 CEST 2010 i686 i686 i386 GNU/Linux
> We also corresponded with a user in the german asterisk irc channel, which could easily reproduce the problem and agreed that this seems to be a bug in the Goto app.



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