[asterisk-bugs] [JIRA] (ASTERISK-27307) AMI Action 'Command' only returns the last line

[Ramon Peek (JIRA)]

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

Ramon Peek edited comment on ASTERISK-27307 at 10/3/17 10:30 PM:
-----------------------------------------------------------------

Found the cause to be in our own application.
Sorry, for the inconvenience.
But before we close the issue, one last question;

Our code first translates the AMI messages to a Python dictionary before dumping it into our debugger.
In this translate process, it uses everything before the ":" marker as the key name, and all behind as the value.
Because the key name is "Output", and is always the same, it get's overwritten thus resulting in only the last value to be shown.
However, this translation code already contained some special code (which I was unaware of) that handles "Unformatted Responses".
The previous unformatted responses where then converted to "line0:", "line1:", and so on. (which explains why you saw these in my first comment.)
I can adjust our code to do the same, for these new messages resolving the issue on our side.

But is it correct in assuming that ALL AMI responses containing lines starting with: "Output :" can be compared to the output of the old "Unformatted Responses"?
And are these "Output" headers always send as the last headers of the messages?

 


was (Author: ramonpeek):
Found the cause to be in our own application.
Sorry, for the inconvenience.
But before we close the issue, one last question;

Our code first translates the AMI messages to a Python dictionary before dumping it into our debugger.
In this translate process, it uses everything before the ":" marker as the key name, and all behind as the value.
Because the key name is "Output", and is always the same, it get's overwritten thus resulting in only the last value to be shown.
However, this translation code already contained some special code (which I was unaware of) that handles "Unformatted Responses".
The previous unformatted responses where then converted to "line0:", "line1:", and so on. (which explains why you saw these in my first comment.)
I can adjust our code to do the same, for these new messages resolving the issue on our side.

But is it correct in assuming theta ALL AMI responses containing lines starting with: "Output :" can be compared to the output of the old "Unformatted Responses"?
And are these "Output" headers always send as the last headers of the messages?

 

> AMI Action 'Command' only returns the last line
> -----------------------------------------------
>
>                 Key: ASTERISK-27307
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27307
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/ManagerInterface
>    Affects Versions: 14.0.0, 15.0.0-rc1
>         Environment: CentOS 6.8 
>            Reporter: Ramon Peek
>            Assignee: Unassigned
>            Severity: Minor
>         Attachments: AMI-command-action-patch_v14.diff
>
>
> The AMI Action 'Command' only returns the last line from the output of a CLI command.
> This is the case since the launch of Asterisk 14, which is described on the Asterisk Wiki as;
> "The Command action now sends the output from the CLI command as a series of Output headers for each line instead of as a block of text with the --END COMMAND-- delimiter to match the output from other actions."
> https://wiki.asterisk.org/wiki/display/AST/Upgrading+to+Asterisk+14
> As a result we are no longer getting a useful response if the CLI command executed contains multiple lines, like 'core show channels' or 'sip show channels'
> In these cases only the last line of the CLI Command is then reported on the "Output header" 
> The WiKi mentions; "a series of Output headers for each line"
> But clearly that doesn't happen, we only get a single "output header".
> I've written a simple patch that reverts this change.
> Even though this works for me at the moment, reverting the change is a step backwards and likely not the correct way to continue.
> I'd like to write a correct solution to the problem, but this requires me to know more about the reasons behind the original change.
> However, I could not find the actual change anywhere in the ChangeLog or here on Jira. 
> Some assistance is appreciated.



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