[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=237892#comment-237892 ] 

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

[~bford] I'm Antonis' associate and responsible for the above tests, so I'll pick up the conversation from now on.

The test that exhibits the problem is part of a series of unit tests for our .Net asterisk libraries. We needed a mechanism to hook on channels created by the originate action before receiving the originate response event, hence the mangled extension numbers and the FastAGI call.

The detailed sequence of actions is this:

1. Originate a call from extension A (Local/A at context) to extension B (see the originate action in the original post). 
2. Extension A is handled by a FastAGI application that simply executes a dial (Local/TestPhone1 at mb_all_calls/n) command (on the Local/A;2 channel) to the originator's phone (TestPhone1).
3. Wait for the call to be bridged (and originateresponse to arrive with success)
4. Extension B is called (by the Local/A;1 channel), which performs the IAX2 dial to a designated extension on the other server.
5. After the call is bridged, any redirect action performed on the SIP/TestPhone1 channel will produce a newexten event with the wrong app/appdata fields.

Please note that we have changed step 2 to dial directly to SIP (instead of Local) and step 4 to dial a local SIP channel with the same results. It appears that the combination of originate action and FastAGI "EXEC DIAL" are the cause of the problem. Also, please note that the problem appears when a redirect action is performed on the originator's SIP channel (the one that was created by the originate action and FastAGI exec dial).

We'll try to perform the above scenario using PJSIP to call TestPhone1 and see what happens. This might take a while since our code does not handle PJSIP channels yet and we need to implement that.

Apart from that, if with the above clarifications you still can't reproduce the problem, I can provide you with an executable file that encapsulates the test and reproduces the problem.

> 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: Antonis Psaras
>            Assignee: Benjamin Keith Ford
>         Attachments: 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}
> {noformat}
> action: Command
> command: dialplan remove extension "_mboBCmtGYDJ5UW[x]cK[x]QSWD[z]Qg."@"mb_all_calls" "1"
> actionid: @00000163
> {noformat}
> {noformat}
> action: Command
> command: dialplan remove extension "_mbuadBCmtGYDJ5UW[x]cK[x]QSWD[z]Qg"@"mb_all_calls" "1"
> actionid: @00000166
> {noformat}
> {noformat}
> action: Command
> command: dialplan remove extension "_mbq1LQsysi-K0GJ0Pg6F2ctiA."@"mb_all_calls" "1"
> actionid: @00000169
> {noformat}
> {noformat}
> action: Command
> command: dialplan remove extension "_mbsLGrALV2_[n]0eo[X]JH[X]MsM[Z]KQ."@"mb_all_calls" "1"
> actionid: @0000016C
> {noformat}
> {noformat}
> action: Command
> command: dialplan remove extension "_mohBCmtGYDJ5UW[x]cK[x]QSWD[z]Qg."@"mb_all_calls" "1"
> actionid: @0000016F
> {noformat}



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