[asterisk-dev] [Code Review] 3866: Ensure that arbitrary header order of AMI Userevent Action results in same information being transmitted in the ensuing AMI event.

Mark Michelson reviewboard at asterisk.org
Thu Aug 7 14:33:02 CDT 2014


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3866/
-----------------------------------------------------------

(Updated Aug. 7, 2014, 2:33 p.m.)


Status
------

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
-------

Committed in revision 5386


Bugs: ASTERISK-24124
    https://issues.asterisk.org/jira/browse/ASTERISK-24124


Repository: testsuite


Description
-------

In Asterisk trunk, we introduced a regression in the AMI UserEvent command. A code change was made that assumed that the first header being processed in the command was the "Action:" header, and that this header should not be emitted by Asterisk in the following UserEvent. This assumption does not hold true, and can result in lost information in the UserEvent sent by Asterisk. The fix for this is a two-line change in manager.c that has been provided by John Hardin. The fix is so small it does not warrant review on its own. Since there was a regression though, having a test to verify this does not happen again is useful.

This sends the same UserEvent command to Asterisk using several permutations of the headers. We ensure that each results in the same information being sent in the AMI UserEvent that Asterisk emits.


Diffs
-----

  /asterisk/trunk/tests/manager/userevent/test-config.yaml PRE-CREATION 
  /asterisk/trunk/tests/manager/userevent/event.py PRE-CREATION 
  /asterisk/trunk/tests/manager/tests.yaml 5154 

Diff: https://reviewboard.asterisk.org/r/3866/diff/


Testing
-------

I can confirm that this test does not pass with current trunk, but with the patch applied, the test passes successfully.


Thanks,

Mark Michelson

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140807/e3405b0a/attachment.html>


More information about the asterisk-dev mailing list