[Home]

Summary:ASTERISK-24795: AEL - When a call is dialed using a gosub to a different context using the switch/goto statement and the call is parked, recovering the call gives a wrong callerid
Reporter:Leandro Dardini (ldardini)Labels:
Date Opened:2015-02-15 12:10:22.000-0600Date Closed:
Priority:MinorRegression?
Status:Open/NewComponents:PBX/pbx_ael
Versions:11.12.0 12.8.1 13.2.0 Frequency of
Occurrence		Constant
Related
Issues:
Environment:CentOS 6 64 bitAttachments:( 0) fulldebug
Description:Using AEL language, If an extension calls a number XXX and then park the call, the number XXX being dialed is saved in the parking lot. When the call parked is recovered, the number XXX is transmitted to the calling extension using RPID. If the extension calls the number using a context reached using a gosub and in that context a switch statement is used, the number XXX is lost and being replaced by internal dialplan data, like SW_549_SIP or _X.

Probably the application breaking the RPID is the "Goto".

This bad behavior can be tested using this minimal diaplan:

{code}
context doDialing {
       _X. => {
           Set(a=5);
           switch (${a}) {
             case 1: NoOp(one);
                  break;
             case 2: NoOp(two);
                  break;
             case 3: NoOp(three);
                  break;
             case 4: NoOp(four);
                  break;
             case 5: NoOp(five);
                      break;
           }
           Dial(SIP/onlytest/998474638374);
       }

}

context internal {

   104 => {
      gosub(doDialing,104,1);
   }

   *7 => {
       Park();
   }

   *8 => {
       ParkedCall();
   }
}
{code}

And dialing from an extension in the "internal" context the number 104, then transferring to *7 and then recovering the call with *8

This is the output of the CLI during the call:

{code}
   -- Executing [104@authenticated:1] Gosub("SIP/110-DEVEL-00000016", "doDialing,104,1") in new stack
   -- Executing [104@doDialing:1] MSet("SIP/110-DEVEL-00000016", "~~EXTEN~~=104") in new stack
   -- Executing [104@doDialing:2] Set("SIP/110-DEVEL-00000016", "a=5") in new stack
   -- Executing [104@doDialing:3] Goto("SIP/110-DEVEL-00000016", "sw_4335_5,10") in new stack
   -- Goto (doDialing,sw_4335_5,10)
   -- Executing [sw_4335_5@doDialing:10] NoOp("SIP/110-DEVEL-00000016", "five") in new stack
   -- Executing [sw_4335_5@doDialing:11] Goto("SIP/110-DEVEL-00000016", "_X.,4") in new stack
   -- Goto (doDialing,_X.,4)
   -- Executing [_X.@doDialing:4] NoOp("SIP/110-DEVEL-00000016", "Finish switch_doDialing_4335") in new stack
   -- Executing [_X.@doDialing:5] Dial("SIP/110-DEVEL-00000016", "SIP/onlytest/998474638374") in new stack
{code}

When getting back the call with *8 the callerid connected appears to be "_X.".

This doesn't happen if the call is made without using the switch/goto statement. This doesn't happen if the call is made without using the gosub. This doesn't happen if the dialed number transmit RPID once reconnected.
Comments:By: Matt Jordan (mjordan) 2015-02-15 17:33:02.221-0600

We require a complete debug log to help triage the issue. This document will provide instructions on how to collect debugging logs from an Asterisk machine for the purpose of helping bug marshals troubleshoot an issue: https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information


By: Matt Jordan (mjordan) 2015-02-15 17:33:40.047-0600

Please use 13.2.0 to test this as well. A number of caller ID/parking related issues were fixed in the 13 branch, and as the 12 branch is in security fix only mode, you may be running into an issue that has been fixed.
By: Leandro Dardini (ldardini) 2015-02-28 13:21:57.505-0600

This is the complete debug log to help you triage the issue. The call has been done from extension 110-DEVEL, calling extension 104 that is routed to an external number using a gosub to another context using the goto statement. The call is then parked by dialing *7 and then recovered from parking lot with *8. The callerID shown is _X. instead of the dialed number.

If the external number is dialed directly, the callerID shown is correct.
By: Leandro Dardini (ldardini) 2015-03-11 06:46:06.366-0500

I have uploaded the fulldebug. I got report of it happening also on asterisk 11
By: Rusty Newton (rnewton) 2015-03-20 20:15:38.063-0500

Can you reproduce similar/same behavior without pbx_ael?
By: Richard Mudgett (rmudgett) 2015-03-20 21:16:10.072-0500

You could try the b() or o() dial options as a workaround.
By: Derek Bolichowski (derekb) 2015-03-28 21:57:38.987-0500

I am a client of the person who reported the issue.
We have tried using the "o" dialing option in extensions.ael. This does the opposite of what is required.

Ex: if I call 5195551111 from 5195552222 and park the call, upon pickup the caller ID shows 5195552222 as this is how "o" is defined -- use original caller ID in all contexts.

According to the developer, the "b" option will not work for this issue.

Would it help if I provided our extensions.ael for review?
By: Derek Bolichowski (derekb) 2015-03-28 21:58:51.574-0500

Tried "o", does not work as required.
By: Leandro Dardini (ldardini) 2015-03-29 03:23:57.629-0500

I have managed to "export" the config from AEL to .conf, by running a "dialplan show" and then translating the output to a valid .conf configuration:

{code}
[authenticated]
exten => *7,1,Park()                                    
exten => *8,1,ParkedCall()                              
exten => 104,1,gosub(doDialing,104,1)                    

[doDialing]
exten => sw_24463_,10, Goto(sw_24463_.,10)                      
exten => sw_24463_1,10, NoOp(one)                                
exten => sw_24463_1,11, Goto(_X.,4)                              
exten => sw_24463_2,10, NoOp(two)                                
exten => sw_24463_2,11, Goto(_X.,4)                              
exten => sw_24463_3,10, NoOp(three)                              
exten => sw_24463_3,11, Goto(_X.,4)                              
exten => sw_24463_4,10, NoOp(four)                                
exten => sw_24463_4,11, Goto(_X.,4)                              
exten => sw_24463_5,10, NoOp(five)                                
exten => sw_24463_5,11, Goto(_X.,4)                              
exten => _sw_24463_.,10, Goto(_X.,4)                              
exten => _X.,1, MSet(~~EXTEN~~=${EXTEN})                  
exten => _X.,2, Set(a=5)                                  
exten => _X.,3, Goto(sw_24463_${a},10)                    
exten => _X.,4, NoOp(Finish switch_doDialing_24463)        
exten => _X.,5, Dial(SIP/onlytest/998474638374)        
{code}

The result is the same, the callerID of the call coming out of the parking lot is _X.

I tried removing the MSet(~~EXTEN~~=${EXTEN}) that seems useless, but the problem happens the same.

I tried adding a exten => _X.,1,Set(CALLERID(num)=110) in place, but the problem happens the same, like if for parking lot callerID a different "internal stored" callerID is used.

If I try to dump all channel variables with exten => _X.,1, DumpChan(1)

I do not find the callerID then used as parking lot callerID, but it still pops out when recovering the call.

{code}
Dumping Info For Channel: SIP/110-DEVEL-0000000c:
================================================================================
Info:
Name=               SIP/110-DEVEL-0000000c
Type=               SIP
UniqueID=           srv01-1427617137.42
LinkedID=           srv01-1427617137.42
CallerIDNum=        110
CallerIDName=       Thomas Tran
ConnectedLineIDNum= (N/A)
ConnectedLineIDName=(N/A)
DNIDDigits=         104
RDNIS=              (N/A)
Parkinglot=         DEVEL
Language=           en
State=              Ring (4)
Rings=              0
NativeFormat=       (g729)
WriteFormat=        g729
ReadFormat=         g729
RawWriteFormat=     g729
RawReadFormat=      g729
WriteTranscode=     No
ReadTranscode=      No
1stFileDescriptor=  35
Framesin=           0
Framesout=          0
TimetoHangup=       0
ElapsedTime=        0h0m0s
BridgeID=           (Not bridged)
Context=            doDialing
Extension=          104
Priority=           1
CallGroup=
PickupGroup=
Application=        DumpChan
Data=               1
Blocking_in=        (Not Blocking)

Variables:
ARGC=0
SIPCALLID=bdd49da0-d73115af@192.168.2.16
SIPDOMAIN=demo.mirtapbx.com
SIPURI=sip:110-DEVEL@192.168.2.16:5062
{code}
By: Derek Bolichowski (derekb) 2015-04-01 16:41:38.197-0500

Is this still being actively worked on? Or does the status need to be changed?
By: Rusty Newton (rnewton) 2015-04-02 17:50:15.292-0500

An issue in the open state does not mean it is being actively worked on.

An open issue is waiting for a developer to take on the issue and begin investigation of the problem. I'm sending the issue back to triage as your recent comments regarding reproduction of the issue without use of pbx_ael requires that we look at it again.

I've attempted reproduction of the issue using your provided extensions.conf dialplan and a sip.conf of my own. I cannot reproduce the issue exactly. Using your dialplan in reproduction I can see that the CallerID for the called party's channel (let us say Channel B) is '_X.' from the very beginning and when recovering the party call it is it then expected to see '_X.' as the CallerID on Channel B.

The Party B peer that I am dialing does not have a sip.conf configured CallerID and does not send RPID or PAI to Asterisk. Therefore _X. is Asterisk's best guess (as it is the extension that did the Dial) and remains the CallerID for the Channel B the from the Dial onward through to finally recovery of the parked call. Of course, if you configure CallerID in sip.conf that would change this behavior.. but we don't have your sip.conf to see. I'm also curious what your trustrpid option is set to?

In your full debug log I don't see where the called party sends any RPID or PAI headers to Asterisk. Therefore I'm not sure why you would expect the Channel B CallerID information to change or update from the original _X. ?

By: Rusty Newton (rnewton) 2015-04-02 17:54:19.041-0500

Please use 'Enter Feedback' or 'Send Back' to make sure we see the response. Thanks!
By: Rusty Newton (rnewton) 2015-04-22 17:20:07.074-0500

If you guys can help us understand the issue better, or reproduce an issue then we can look into it further. At this point I'm not sure we have anywhere to go with it.
By: Richard Mudgett (rmudgett) 2015-04-22 19:25:33.099-0500

This is really a problem with AEL generating simply horrid dialplan.  Since the AEL exten is a pattern, the {{goto}} used to implement the AEL {{switch}} statement wipes out the original {{EXTEN}} value with {{_X.}}.  When the {{Dial}} creates the outgoing channel it tries to determine what the CallerID should be and the only information it has available is the dialing channel's {{EXTEN}} value.

You'll have to work around the problem by using another {{Gosub}} level that does the setup work before returning to do the {{Dial}}.
By: Derek Bolichowski (derekb) 2015-04-22 20:05:39.534-0500

I have a copy of the extensions.ael in question. Would it help if I posted it?
By: Richard Mudgett (rmudgett) 2015-04-23 11:11:44.890-0500

What is on the ticket adequately demonstrates what is happening so attaching your
AEL dialplan is not needed.  What I was suggesting as a workaround is this:
{noformat}
context doDialing {
 setup => {
   Set(a=5);
   switch (${a}) {
   case 1: NoOp(one);
     break;
   ....
   }
   Return;
 }
 _X. => {
   Gosub(doDialing,setup,1);
   Dial(SIP/onlytest/998474638374);
   ... post dial processing if the dial fails (busy, congestion, etc...)
   Return;
 }
}
{noformat}

Since I don't use AEL the above may work.
By: Rusty Newton (rnewton) 2015-04-27 11:14:36.869-0500

Opening this up as a pbx_ael issue. AEL is an extended support component so response times may reflect that.
By: Leandro Dardini (ldardini) 2016-05-21 07:02:21.988-0500

I have rewritten all my extensions.ael code (over 7000 rows) to not use the switch statement, working around the problem.