AEL Macro - Dial() - Extension ~~s~~ on display RPID

Asterisk Asterisk Dialplan
1

Hi all

Summary: (asterisk 16.7.0, chan_pjsip, send_rpid=yes)

  • originating call from internal endpoint using Dial() application from within a macro has the channel variable “Extension: ~~s~~”
    – This in turn sets the phones display to s as the number dialed and adds to the phones history so a “redial” will fail for example.

EVEN the ael macro EXAMPLE here has the same symptom.

Home - Asterisk Documentation

setting send_rpid=no negates the symptom as one would expect.
But we need this on for transfers and callpark pickup etc.

Extensive testing shows this only happes when dialing within the macro
If I “goto” out of the macro (yikes)… to make the dial it will send the rpid as expected

Am i not supposed to Dial from Macro’s by design in AEL?

Home - Asterisk Documentation
“Think of a macro as a combination of a context with one nameless extension…”

Specifically

Remote-Party-ID: <sip:~~s~~@PBX-IPADDR>;party=called;privacy=off;screen=no

Via: SIP/2.0/UDP ENDPOINT-IPADDR:5060;rport=5060;received=ENDPOINT-IPADDR;branch=z9hG4bK1491402405
Call-ID: 1330286282-5060-51@BA.CA.C.IA
From: "5000" <sip:5000@PBX-IPADDR>;tag=1215047196
To: <sip:5001@PBX-IPADDR>;tag=23374986-8fd3-4273-ae6c-f45c81cb9b51
CSeq: 451 INVITE
Server: ..<>..
Contact: <sip:PBX-IPADDR:5060>
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Remote-Party-ID: <sip:~~s~~@PBX-IPADDR>;party=called;privacy=off;screen=no
Content-Length:  0

AEL MACRO

macro std-exten( ext , dev ) {
    Dial(${dev}/${ext},20);
    switch(${DIALSTATUS}) {
        case BUSY:
            Voicemail(${ext},b);
            break;
        default:
            Voicemail(${ext},u);
    }
    catch a {
        VoiceMailMain(${ext});
        return;
    }
}


context example {
    _5XXX => &std-exten(${EXTEN},"PJSIP");

DumpChan();
- from inside the macro
Dumping Info For Channel: PJSIP/5001-000000a3:
==============================================================================
Extension=          ~~s~~


DumpChan();
- Before calling the Macro... extension is correct.
Dumping Info For Channel: PJSIP/5001-000000a3:
==============================================================================
Extension=         5001
2

AEL macro is not really a macro, internally it is implemented as Gosub, if I remember correctly. One way to mitigate this behavior would be to set caller ID explicitly as soon as you enter the macro. Or add a predial handler and set it there.

3

Thanks for the reply… Yep understand macro in ael. (it’s good)
I just finished testing predial that and was coming here to post an update… :slight_smile:

Home - Asterisk Documentation
b( context^exten^priority ) - Before initiating an outgoing call, Gosub to the specified location using the newly created channel. The Gosub will be executed for each destination channel.

even though it’s a context in the dial plan it behaves like a macro with a return and $ARG1

testing shows that using the above argument b() then setting the callerid

set(CALLERID(num)=1234);

sets both PAI and RPID in the new channel.

THIS WORKED


context set-rpid-pai {
  s => {
    set(CALLERID(num)=${ARG1});
    dumpchan();
    Return;
  }
}

macro ael-std-exten-ael( ext , dev ) {
	
	Dial(PJSIP/${ext},,b(set-rpid-pai^s^1(${ext})));
	
	return;
}

I guess this is the only way to do it if Dialing within the macro???
As long as I’m doing what’s expected and i’m not missing something then i’m good with it.

Appreciate any feedback. Thanks.

4

So perhaps my use of AEL Macros should not include dialing where possible. ?

The fact that it is a combination of a context with one nameless extension creates a challenge any time you need to reference the channels extension. eg: call Pickup() -

Workaround

SET(GLOBAL(PICKUPMARK)=${EXTEN:2});
Pickup(${EXTEN:2}@PICKUPMARK);

I like the concept of Sub Routine (function style) programming returning to the same line of code and continuing. So I was leaning to it over a dialplan flow of goto contexts. I can achieve the same result with “goto” anyway so it’s not a problem.

I have had plenty of sucess using AEL Dialing Macro’s for calling out SIP trunks which didn’t inherit any issues for extension as it’s different use case scenario.

Questions:

  • I’m still very curious about the AEL Dial macro example here though as i don’t think it’s actually that good for some cases (ie this post)

https://wiki.asterisk.org/wiki/display/AST/AEL+Macros

  • Nevertheless, is it best practice to use contexts and not implement macros like this for such reasons in AEL?

Comments welcome.

5

I don’t know what best or recommended practice is, but to me it seems easiest to use normal context instead of macro and Gosub to it. That is what AEL does internally anyway, but this way you’d have more control.

context ael-std-exten-ael {
    _X. => {
        Dial(PJSIP/${EXTEN});
        return;
    }
}
6

Thanks for your input niksa

gosub seems to function but I cant find any great explanation online for this WARNING as soon as I have a gosub in AEL.
Came across this WARNING ages ago so i moved to the macro implementation which has brought me to this post.

*CLI> ael reload
WARNING[2098]: ael/pval.c:2525 check_pval_item: Warning: file /etc/asterisk/extensions.ael, line 140-140: application call to Gosub affects flow of control, and needs to be re-written using AEL if, while, goto, etc. keywords instead!

So in summary using gosub() instead of &macro() keeps the EXTEN in tact.
Though has this WARNING when loading the AEL config.

7

The warning is there because AEL has its own flow control mechanisms, and using Gosub directly prevents AEL compiler from detecting potential problems. It’s just a warning, though. Using Gosub is unlikely to cause problems, and even if it does, you’ll be able to correct them. If you still want to avoid the warning, go with setting the caller ID in predial handler.

1 Like
8

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.