[asterisk-bugs] [JIRA] (ASTERISK-27153) AMI Newexten event returns wrong event parameters

[John Lagonikas (JIRA)]

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

John Lagonikas commented on ASTERISK-27153:
-------------------------------------------

I have attached a test program that exhibits the behavior. It's a console program, that runs in windows and requires .net 4.7 to run.

The program uses PortSip to create the test devices, and unfortunately we couldn't find a way to stop portsip from outputting all its logs to the console.

In order to run this, you need to:

1. create sip accounts for 3 phones, TestPhone1, 2 and 3. You may use any secret you want, you'll have to declare it in the config file in the next step.
2. edit the .config file, and set your environment parameters. You'll need to provide the asterisk version (major only), the IP address of the asterisk host (it will be used for both connecting to AMI and phone registration, port 5038 is assumed for AMI and 5060 for SIP), the IP address of the windows machine you're running the program from (the IP address which will listen to FastAGI requests, port 4573 is assumed), the secrets for the SIP phone registrations and an existing dialplan context under which all the necessary extensions will be registered (that's done automatically by the program).

Once the program is finished, it will display "Error: NewExten fields are invalid" if the app/appdata fields are wrong, or "Test completed successfully" if everything worked as expected, and wait for a key. In our tests, we always get the former as a response for asterisk versions 13 and 14, and the latter for 11 and back.

> AMI Newexten event returns wrong event parameters
> -------------------------------------------------
>
>                 Key: ASTERISK-27153
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27153
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/ManagerInterface
>    Affects Versions: 13.17.0, 14.6.0
>         Environment: CentOS 6 64Bit
>            Reporter: John Lagonikas
>            Assignee: Unassigned
>         Attachments: Debug.zip, full.txt
>
>
> We have detected that, in some rare cases, Newexten events contain wrong Application / AppData fields (i.e. Application / AppData do not correspond to what was actually executed, but rather display the values corresponding to the previous execution for that channel).
> Our test involves originating a call to TestPhone1, transferring that call to another asterisk via IAX2, then transferring the initial channel to TestPhone2 (local) and then transferring the call to an AGI application.
> The problematic Newexten events can be seen at lines 3162 and 5246 of the attached log file. The actual executions (with the correct app/appdata) can be seen at lines 3127 and 5199 respectively. You can see that the Newexten @5246 contains the app/appdata fields that should have been contained by the Newexten @3162 event.
> The same behavior is exhibited in both asterisk versions 13 and 14 (latest builds). The problem does not appear in asterisk versions 11 and back.
> The manager actions we executed (and which do not appear in the attached log file) are the following:
> Step 1:
> {noformat}
> action: Originate
> channel: Local/mboBCmtGYDJ5UWxcKxQSWDzQg2 at mb_all_calls
> context: mb_all_calls
> exten: mbsLGrALV2_n0eoXJHXMsMZKQ1
> priority: 1
> timeout: 20000
> callerid:  <5432>
> account: TestPhone1
> actionid: mboBCmtGYDJ5UWxcKxQSWDzQg2
> async: 1
> variable:
> {noformat}
> Step 2:
> {noformat}
> action: Redirect
> channel: SIP/TestPhone1-00000000
> extrachannel: 
> context: mb_all_calls
> exten: TestPhone2
> priority: 1
> actionid: @000000C3
> {noformat}
> Step 3:
> {noformat}
> action: Redirect
> channel: SIP/TestPhone1-00000000
> extrachannel: 
> context: mb_all_calls
> exten: mbuadBCmtGYDJ5UWxcKxQSWDzQg
> priority: 1
> actionid: @0000011C
> {noformat}
> All the extensions you see in the log file were registered by our software at the beginning of the test. Their full definition is as follows:
> {noformat}
> action: Command
> command: dialplan add extension "_mohBCmtGYDJ5UW[x]cK[x]QSWD[z]Qg.","1","MusicOnHold","${EXTEN:26}" into "mb_all_calls" replace
> actionid: @00000005
> {noformat}
> {noformat}
> action: Command
> command: dialplan add extension "_mboBCmtGYDJ5UW[x]cK[x]QSWD[z]Qg.","1","agi","agi://192.168.1.69:4573/4qqf0RiNsEezVRJatsHMLA" into "mb_all_calls" replace
> actionid: @00000008
> {noformat}
> {noformat}
> action: Command
> command: dialplan add extension "_mbuadBCmtGYDJ5UW[x]cK[x]QSWD[z]Qg","1","agi","agi://192.168.1.69:4573/hGGhXk7zlkKP-fKZXLtZgg" into "mb_all_calls" replace
> actionid: @0000000B
> {noformat}
> {noformat}
> action: Command
> command: dialplan add extension "_mbq1LQsysi-K0GJ0Pg6F2ctiA.","1","agi","agi://192.168.1.69:4573/1LQsysi-K0GJ0Pg6F2ctiA" into "mb_all_calls" replace
> actionid: @0000000E
> {noformat}
> {noformat}
> action: Command
> command: dialplan add extension "_mbsLGrALV2_[n]0eo[X]JH[X]MsM[Z]KQ.","1","Dial","IAX2/192.168.1.13/mbq1LQsysi-K0GJ0Pg6F2ctiA${EXTEN:25}@mb_all_calls" into "mb_all_calls" replace
> actionid: @00000011
> {noformat}
> {noformat}
> action: Command
> command: dialplan add extension "mbtestmoh","1","musiconhold","default" into "mb_all_calls" replace
> actionid: @00000028
> {noformat}
> {noformat}
> action: Command
> command: dialplan add extension "_TestPho[n]eX","1","dial","SIP/${EXTEN}" into "mb_all_calls" replace
> actionid: @0000002D
> {noformat}



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