asterisk users - Aug 2011 - 1.6.2.20 ${DIALSTATUS} disagrees with CDR(answered)

I am having a problem with ${DIALSTATUS} and )=CDR(disposition) disagreeing. 
Below is a dialplan snippet and the resulting CLI output.  This is running in an
'h' extension.

        Noop(DIALSTATUS=${DIALSTATUS})
        Noop(CDR(disposition)=${CDR(disposition)})

    -- Executing [h at pbxmax-dial-simple:1]
NoOp("SIP/msx_01-0000005b", "DIALSTATUS=ANSWER") in new
stack
    -- Executing [h at pbxmax-dial-simple:2]
NoOp("SIP/msx_01-0000005b", "CDR(disposition)=NO ANSWER") in
new stack

Unless I seriously misunderstand the CDR(disposition) function, this looks like
a bug to me.  Does any else have this issue?

On 14 August 2011 08:36, Eric Wieling <EWieling at nyigc.com>
wrote:
>
> I am having a problem with ${DIALSTATUS} and )=CDR(disposition)
disagreeing. ?Below is a dialplan snippet and the resulting CLI output. ?This is
running in an 'h' extension.
>
> ? ? ? ?Noop(DIALSTATUS=${DIALSTATUS})
> ? ? ? ?Noop(CDR(disposition)=${CDR(disposition)})
>
> ? ?-- Executing [h at pbxmax-dial-simple:1]
NoOp("SIP/msx_01-0000005b", "DIALSTATUS=ANSWER") in new
stack
> ? ?-- Executing [h at pbxmax-dial-simple:2]
NoOp("SIP/msx_01-0000005b", "CDR(disposition)=NO ANSWER") in
new stack
>
> Unless I seriously misunderstand the CDR(disposition) function, this looks
like a bug to me. ?Does any else have this issue?
>
What call events lead up to that? There is a case I encountered some
time ago where a blind-transfer can mess-up the CDR disposition. I
started to re-factor all of the CDR code to fix all of these issues,
but with 1.6 EOL, 1.8 etc etc, it needs revisiting.

As far as I know, 1.8/1.10 has the same issues.

Regards,
Steve