Re: [asterisk-users] Originate with label?
On Monday 29 August 2022 at 17:00:23, Mark Murawski wrote:
> On 8/29/22 09:30, Antony Stone wrote:
> > It is, although there are ways I think it can be improved - I'm wondering
> > how best to go about proposing these.
> >
> > The most obvious for now are:
> > - please can "a=1;" be converted to use Set() instead of MSet()
> > (especially since MSet is officially deprecated)?
>
> Currently being discussed! We can definitely continue talking about the
> pros and cons of adding an option for this or maybe finding another way
> altogether.
Yes, it would useful to implement "backward compatibility" options for AEL,
just as exist for whatever "non-AEL" is called.
Some equivalent of [general] in extensions.conf might be good?
> > - same thing for for (;;)
>
> I see that for (;;) produces an empty MSet().
No, no - I didn't literally mean "(;;)", I meant this as an abbreviation for
the generic format of the for() syntax.
> Definitely this can be cleaned up. Thanks for bringing this up. In the
> meantime you can use while (1)
True; that works for literally "for(;;)", but I think I've never bothered to
use that :)
I meant it wouod be good to use Set() instead of MSet() for the first and third
parts of "for (one; two; three);"
> > - please can gosub be added, to convert into Gosub() (matching goto
> > converting to Goto())?
> I agree that AEL keyword 'gosub' should exist. That's been one of my
> todo items. From not only a consistency perspective, but from a syntax
> checking perspective it would benefit from reporting whether or not your
> gosub destination exists or not, just like goto will complain that the
> destination doesn't exist when the context/extension/priority used is
> not valid.
Sounds good.
> The '&' syntax does use GoSub under the hood, and not the deprecated
> Macro().
Yes, agreed.
> And I'm not sure what you mean by redundant parameters? When you use AEL
> 'macro' to define a '& destination', it uses the positional parameters that
> are passed in as ARG1/ARG2/etc that are inherent in using GoSub and converts
> them to more friendly named-parameters (as defined in the macro definition).
That's precisely what I mean :)
If you use Gosub(), you can reference your parameters as ARG1/2/3/etc, but if
you use &, you end up with several "MSet(xxx=${ARG1});" etc at the start of
your subroutine.
These, in my opinion, are redundant,
> This is why there's always a group of MSet's generated when using AEL
> 'macro'.
See above :)
> If you don't want these extra MSets, then feel free to define a straight up
> context to GoSub into and you can do your own parameter processing using
> ARG1/ARG2/etc
I do.
I just wish there were a gosub in AEL mapping to Gosub() to match goto mapping
to Goto().
> > - it would be great if the redundant NoOp()s which get created by if ..
> > else, while ... and for(;;) could be (maybe optionally?) removed from
> > the resultant dialplan code - otherwise you end up with lots of added
> > commands such as NoOp(Finish if_if_fromTrunk_208_209); in the output.
>
> They aren't redundant specifically, they were left in there (not by me)
> for debugging/tracing purposes.
Hence my "maybe optionally" suggestion.
> But for the casual user, I agree they are mysterious and not very useful. My
> idea to address this is to instead report on the actual if condition to
> assist with tracing/troubleshooting.
I'd prefer to see an option in extensions.ael to say whether you want them at
all or not.
> This is a mockup of what the new-style if/else processor would output
>
> 26. NoOp(AEL IF("\${DIALSTATUS}" == "BUSY") --
> extensions.ael:1405)
> 27. GotoIf($["${DIALSTATUS}" == "BUSY"]?28:30)
> 28. Set(voiceMailOptions=b)
> 29. Goto(32)
> 30. NoOp(AEL ELSE -- extensions.ael:1409)
> 31. Set(voiceMailOptions=u)
> 31. NoOp(AEL END ELSE -- extensions.ael:1410)
> 32. NoOp(AEL END IF("\${DIALSTATUS}" == "BUSY") --
> extensions.ael:1411)
> 33. NoOp(DoStuff)
I would disagree with *any* extra NoOp()s being included in the resultant
output unless the user has asked for them.
Let the code simply express what the user wrote and not add anything
(especially stuff which will end up in a verbose log) which doesn't correspond
to the original input (unless necessary for the logic to work).
> My idea is that the 'if' block would be preceded by outputting the
> logical condition we're about to check, along with the original ael line
> number, and then at the end of the if block, we would get an associated
> END IF with the original ael line number. This would enable the ability
> to quickly locate the code where conditions are being used and also be
> able to look at the logs and see why your code is doing what it's doing
> without a lot of extra verbosity and without needing a
[asterisk-users] Forward incoming call to recipients.
Hey, all. I'd like to forward an incoming call (e.g., to an on-call rotation number), out to multiple recipients, BUT only hand the call over to whoever answers _and acknowledges_ (e.g., "Press any key..."), 'cause I don't want it just going to their mailbox. I've thought of a number of ways to try to make this happen, but surely, something like this must be fairly common, and I'm guessing someone's already got The Right Way(tm) to make it happen. Any suggestions? Thanks! -Ken -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Originate with label?
On 8/29/22 14:00, aster...@phreaknet.org wrote:
This is a mockup of what the new-style if/else processor would output
26. NoOp(AEL IF("\${DIALSTATUS}" == "BUSY") --
extensions.ael:1405)
27. GotoIf($["${DIALSTATUS}" == "BUSY"]?28:30)
28. Set(voiceMailOptions=b)
29. Goto(32)
30. NoOp(AEL ELSE -- extensions.ael:1409)
31. Set(voiceMailOptions=u)
31. NoOp(AEL END ELSE -- extensions.ael:1410)
32. NoOp(AEL END IF("\${DIALSTATUS}" == "BUSY")
-- extensions.ael:1411)
33. NoOp(DoStuff)
Why all the GotoIfs? Why not just use the If/EndIf applications
(assuming they get merged)? Much cleaner syntax:
If($["${DIALSTATUS}"="BUSY"])
Set(voiceMailOptions=b)
Else()
Set(voiceMailOptions=u)
EndIf()
NA
That's definitely very doable. If/Else/Endif was not available at the
time AEL was created. This would be much cleaner code generation as well.
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
Check out the new Asterisk community forum at: https://community.asterisk.org/
New to Asterisk? Start here:
https://wiki.asterisk.org/wiki/display/AST/Getting+Started
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Originate with label?
On 8/29/22 09:30, Antony Stone wrote:
It is, although there are ways I think it can be improved - I'm wondering how
best to go about proposing these.
The most obvious for now are:
- please can "a=1;" be converted to use Set() instead of MSet() (especially
since MSet is officially deprecated)?
Currently being discussed! We can definitely continue talking about the
pros and cons of adding an option for this or maybe finding another way
altogether.
- same thing for for (;;)
I see that for (;;) produces an empty MSet(). Definitely this can be
cleaned up. Thanks for bringing this up. In the meantime you can use
while (1)
- please can gosub be added, to convert into Gosub() (matching goto
converting to Goto())? The & syntax is completely different from the rest of
the language, and also creates redundant assignments at the start of the
subroutine for parsing the parameters. Now that macros are deprecated in
favour of subroutines, it makes sense, I think, to make gosub a part of AEL.
I agree that AEL keyword 'gosub' should exist. That's been one of my
todo items. From not only a consistency perspective, but from a syntax
checking perspective it would benefit from reporting whether or not your
gosub destination exists or not, just like goto will complain that the
destination doesn't exist when the context/extension/priority used is
not valid.
The '&' syntax does use GoSub under the hood, and not the deprecated
Macro(). And I'm not sure what you mean by redundant parameters? When
you use AEL 'macro' to define a '& destination', it uses the positional
parameters that are passed in as ARG1/ARG2/etc that are inherent in
using GoSub and converts them to more friendly named-parameters (as
defined in the macro definition). This is why there's always a group of
MSet's generated when using AEL 'macro'. If you don't want these extra
MSets, then feel free to define a straight up context to GoSub into and
you can do your own parameter processing using ARG1/ARG2/etc
- it would be great if the redundant NoOp()s which get created by if .. else,
while ... and for(;;) could be (maybe optionally?) removed from the resultant
dialplan code - otherwise you end up with lots of added commands such as
NoOp(Finish if_if_fromTrunk_208_209); in the output.
They aren't redundant specifically, they were left in there (not by me)
for debugging/tracing purposes. But for the casual user, I agree they
are mysterious and not very useful. My idea to address this is to
instead report on the actual if condition to assist with
tracing/troubleshooting.
This is a mockup of what the new-style if/else processor would output
26. NoOp(AEL IF("\${DIALSTATUS}" == "BUSY") --
extensions.ael:1405)
27. GotoIf($["${DIALSTATUS}" == "BUSY"]?28:30)
28. Set(voiceMailOptions=b)
29. Goto(32)
30. NoOp(AEL ELSE -- extensions.ael:1409)
31. Set(voiceMailOptions=u)
31. NoOp(AEL END ELSE -- extensions.ael:1410)
32. NoOp(AEL END IF("\${DIALSTATUS}" == "BUSY") --
extensions.ael:1411)
33. NoOp(DoStuff)
My idea is that the 'if' block would be preceded by outputting the
logical condition we're about to check, along with the original ael line
number, and then at the end of the if block, we would get an associated
END IF with the original ael line number. This would enable the ability
to quickly locate the code where conditions are being used and also be
able to look at the logs and see why your code is doing what it's doing
without a lot of extra verbosity and without needing a lot of work to
find which ael-lines are running.
- finally, it would be good if the documentation could be clear about whether
the extensions.conf [general] section can be substituted using AEL. I haven't
yet worked out whether this is possible or not.
[general] section options are not available in ael... currently there's
no mechanism to support that sort of thing.
bracket items like [general] aren't supported in the AEL parser. and
some of the options don't even make sense and/or apply to AEL like
static/writeprotect
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
Check out the new Asterisk community forum at: https://community.asterisk.org/
New to Asterisk? Start here:
https://wiki.asterisk.org/wiki/display/AST/Getting+Started
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Originate with label?
On Monday 29 August 2022 at 16:19:17, Mark Murawski wrote: > On 8/29/22 10:15, Antony Stone wrote: > >> But! What specific reason do you have for wanting Set() instead of > >> MSet() for all assignments that can't be otherwise just written as an > >> in-line Set() instead? > > > > I *am* currently writing inline Set() everywhere, but surely the syntax > > "a=1;" instead of "Set(a=1);" is supposed to be one of the advantages of > > AEL over standard Asterisk dialplan language? > > Hi Antony, > > Right... using a=1; one advantage of using AEL, so you don't have to > type Set() everywhere... but what I'm trying to get at is... and my > original question is: what specific situation prevents you from using > a=1; style syntax? Why are you feeling the need to use Set(a=1) instead > of a=1. What are specific examples where the 'straight-assignment' > isn't working for you? I don't have any examples where MSet() ends up doing something I do not want, but going by the documentation saying "avoid its use if possible", that's what I prefer to do. > Note: Make sure to use 'Reply All'.. I typically do a list reply and > direct reply. Okay, replying to you as well this time, but please don't do the same back to me (see sig). Antony. -- If the human brain were so simple that we could understand it, we'd be so simple that we couldn't. Please reply to the list; please *don't* CC me. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Originate with label?
On 8/29/22 10:15, Antony Stone wrote: But! What specific reason do you have for wanting Set() instead of MSet() for all assignments that can't be otherwise just written as an in-line Set() instead? I *am* currently writing inline Set() everywhere, but surely the syntax "a=1;" instead of "Set(a=1);" is supposed to be one of the advantages of AEL over standard Asterisk dialplan language? Hi Antony, Right... using a=1; one advantage of using AEL, so you don't have to type Set() everywhere... but what I'm trying to get at is... and my original question is: what specific situation prevents you from using a=1; style syntax? Why are you feeling the need to use Set(a=1) instead of a=1. What are specific examples where the 'straight-assignment' isn't working for you? Note: Make sure to use 'Reply All'.. I typically do a list reply and direct reply. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Originate with label?
On 8/29/22 09:53, Antony Stone wrote:
On Monday 29 August 2022 at 15:35:09, Joshua C. Colp wrote:
MSet is not deprecated.
https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Application_MSet
includes the sentence "MSet behaves in a similar fashion to the way Set worked
in 1.2/1.4 and is thus prone to doing things that you may not expect." and
ends with "Avoid its use if possible."
So, that may not mean "officially deprecated", but it still strongly suggests to
me that it's undesirable for AEL to convert all assignments into MSet instead
of Set (allowing the user to explicitly write MSet if that's what's desired).
Antony.
Some users of AEL might rely on the 'odd behavior' of MSet (the most
obvious of which is the removal of quotes). This would definitely have
to be an option if all conversions were to use Set instead of MSet.
But! What specific reason do you have for wanting Set() instead of
MSet() for all assignments that can't be otherwise just written as an
in-line Set() instead?
Also.. if you specifically want to use Set(), there's nothing preventing
you from just using Set()
The assignment (ex: a=1) style shortcut is mostly useful for math-based
operations. such as making nice syntactic sugar for something like:
a = ${a} + 1
You can of course accomplish math operations a traditional Set() by
using traditional $[] syntax. So for the intended purposes it's pretty
much a shortcut for simple assignments or math. Anything else, you
would need to call Set() directly.
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
Check out the new Asterisk community forum at: https://community.asterisk.org/
New to Asterisk? Start here:
https://wiki.asterisk.org/wiki/display/AST/Getting+Started
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Originate with label?
On Mon, Aug 29, 2022 at 10:53 AM Antony Stone < antony.st...@asterisk.open.source.it> wrote: > On Monday 29 August 2022 at 15:35:09, Joshua C. Colp wrote: > > > MSet is not deprecated. > > https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Application_MSet > includes the sentence "MSet behaves in a similar fashion to the way Set > worked > in 1.2/1.4 and is thus prone to doing things that you may not expect." and > ends with "Avoid its use if possible." > > So, that may not mean "officially deprecated", but it still strongly > suggests to > me that it's undesirable for AEL to convert all assignments into MSet > instead > of Set (allowing the user to explicitly write MSet if that's what's > desired). > Sure, but even with that it's not "unofficially deprecated". It's sound reasoning, however, that because of the behavior of MSet then switching could be a good idea. -- Joshua C. Colp Asterisk Project Lead Sangoma Technologies Check us out at www.sangoma.com and www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Originate with label?
On Monday 29 August 2022 at 15:35:09, Joshua C. Colp wrote: > MSet is not deprecated. https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Application_MSet includes the sentence "MSet behaves in a similar fashion to the way Set worked in 1.2/1.4 and is thus prone to doing things that you may not expect." and ends with "Avoid its use if possible." So, that may not mean "officially deprecated", but it still strongly suggests to me that it's undesirable for AEL to convert all assignments into MSet instead of Set (allowing the user to explicitly write MSet if that's what's desired). Antony. -- Atheism is a non-prophet-making organisation. Please reply to the list; please *don't* CC me. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Originate with label?
On Mon, Aug 29, 2022 at 10:30 AM Antony Stone < antony.st...@asterisk.open.source.it> wrote: > On Monday 29 August 2022 at 14:51:27, Mark Murawski wrote: > > > On 8/29/22 08:48, Mark Murawski wrote: > > > > > > Hi Antony, > > > > > > I love to hear about AEL use-cases. I'm happy that AEL is working out > > > for you. > > It is, although there are ways I think it can be improved - I'm wondering > how > best to go about proposing these. > > The most obvious for now are: > > - please can "a=1;" be converted to use Set() instead of MSet() > (especially > since MSet is officially deprecated)? > MSet is not deprecated. -- Joshua C. Colp Asterisk Project Lead Sangoma Technologies Check us out at www.sangoma.com and www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Check out the new Asterisk community forum at: https://community.asterisk.org/ New to Asterisk? Start here: https://wiki.asterisk.org/wiki/display/AST/Getting+Started asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Originate with label?
On Monday 29 August 2022 at 14:51:27, Mark Murawski wrote:
> On 8/29/22 08:48, Mark Murawski wrote:
> >
> > Hi Antony,
> >
> > I love to hear about AEL use-cases. I'm happy that AEL is working out
> > for you.
It is, although there are ways I think it can be improved - I'm wondering how
best to go about proposing these.
The most obvious for now are:
- please can "a=1;" be converted to use Set() instead of MSet() (especially
since MSet is officially deprecated)?
- same thing for for (;;)
- please can gosub be added, to convert into Gosub() (matching goto
converting to Goto())? The & syntax is completely different from the rest of
the language, and also creates redundant assignments at the start of the
subroutine for parsing the parameters. Now that macros are deprecated in
favour of subroutines, it makes sense, I think, to make gosub a part of AEL.
- it would be great if the redundant NoOp()s which get created by if .. else,
while ... and for(;;) could be (maybe optionally?) removed from the resultant
dialplan code - otherwise you end up with lots of added commands such as
NoOp(Finish if_if_fromTrunk_208_209); in the output.
- finally, it would be good if the documentation could be clear about whether
the extensions.conf [general] section can be substituted using AEL. I haven't
yet worked out whether this is possible or not.
> > Without modifying the code for Originate(), you can do this while
> > staying purely in AEL
> > Here's your workaround:
> >
> > context something {
> > s => {
> > Originate(Local/${Dest}@Dialout,exten,${CONTEXT},GotoLabel,1,,v(GotoExten
> > =${EXTEN}^GotoLabel=LabelName)); }
> >
> > GotoLabel => {
> > goto ${CONTEXT}, ${GotoExten}, ${GotoLabel};
> > }
> > }
Right, I had wondered about using the v option. Thanks for the suggestion.
In the meantime I came up with:
Originate(Local/${Dest}@Dialout,exten,${CONTEXT},Orig${EXTEN},1);
_OrigX. => goto ${EXTEN:4},target;
> And, additionally. You really *should* be breaking down components into
> their own macros or extension blocks. Adding labels to jump into the
> middle of an extension is typically a sign that you've outgrown your
> overall design.
Oh, I already have plenty of contexts and a fair number of extensions. I'm
not writing the entire dialplan in one context :)
There's a good reason why I need to jump to another location in the same
context once the Originate has completed.
> It's much. much. much easier to build a system up from different
> contexts,extensions and use goto/gosub and make your system more modular
> instead of having one-giant-context with one-giant-extension that tries
> to do everything.
Very much agreed.
Antony.
--
I conclude that there are two ways of constructing a software design: One way
is to make it so simple that there are _obviously_ no deficiencies, and the
other way is to make it so complicated that there are no _obvious_
deficiencies.
- C A R Hoare
Please reply to the list;
please *don't* CC me.
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
Check out the new Asterisk community forum at: https://community.asterisk.org/
New to Asterisk? Start here:
https://wiki.asterisk.org/wiki/display/AST/Getting+Started
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] [External] I think there may be a bug in 18.14.0 ${GEOLOC_PROFILE(profile_precedence)}, seems to always return prefer_incoming
Thank you for the explanation George.
This makes it very easy to know if the Geo Location is the configured or an
incoming value.
Dan
From: asterisk-users On Behalf Of
George Joseph
Sent: Thursday, August 25, 2022 7:21 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [External] [asterisk-users] I think there may be a bug in 18.14.0
${GEOLOC_PROFILE(profile_precedence)}, seems to always return prefer_incoming
On Wed, Aug 24, 2022 at 7:51 AM George Joseph
mailto:gjos...@sangoma.com>> wrote:
Yeah, that's weird. I opened an issue for this...
https://issues.asterisk.org/jira/browse/ASTERISK-30190
OK, It's actually not weird :)
Let's say the configured profile is set to discard_config or prefer_incoming
and there actually is an incoming profile. In this situation, by the time you
reach the dialplan, we've already discarded the configured profile in favor of
the incoming one so profile_precedence is going to be what's on the incoming
one which will always be prefer_incoming. Is that going to be an issue?
BTW, there still is a bug where effective_location will be blank in this same
situation and there are patches up on Gerrit that fix that and a few other bugs.
On Tue, Aug 23, 2022 at 2:47 PM Dan Cropp
mailto:d...@amtelco.com>> wrote:
Running into a problem when retrieving the profile_precedence in the
extensions.conf
Creating a very basic geolocation.conf to allow passing through geolocation
values for outbound.
[discard_config]
type = profile
profile_precedence = discard_config
[discard_incoming]
type = profile
profile_precedence = discard_incoming
[prefer_config]
type = profile
profile_precedence = prefer_config
[prefer_incoming]
type = profile
profile_precedence = prefer_incoming
I have tried setting the pjsip.conf geoloc_incoming_call_profile to all four of
these profiles for inbound call testing. The discard_incoming correctly blocks
the geo location information. Other 3 pass the geo location values through
[192.168.33.31]
type = endpoint
context = IS
transport = transport1
aors = 192.168.33.31
accountcode = 20
dtmf_mode = inband
device_state_busy_at = 1600
moh_passthrough = no
identify_by = username,ip,header
disallow = all
allow = ulaw
acl = acl1
geoloc_incoming_call_profile = prefer_config
geoloc_outgoing_call_profile = prefer_config
When I have the following line in the extensions.conf, it’s retrieving the
GEOLOC_PROFILE(profile_precedence) to the variable, but it’s being set to
prefer_incoming even when it should be discard_config or prefer_config.
same => n,Set(MY__GEO_PROFILE_PRECEDENCE=${GEOLOC_PROFILE(profile_precedence)})
Dan
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
Check out the new Asterisk community forum at: https://community.asterisk.org/
New to Asterisk? Start here:
https://wiki.asterisk.org/wiki/display/AST/Getting+Started
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
Check out the new Asterisk community forum at: https://community.asterisk.org/
New to Asterisk? Start here:
https://wiki.asterisk.org/wiki/display/AST/Getting+Started
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Originate with label?
On 8/29/22 08:48, Mark Murawski wrote:
On 8/29/22 08:31, Antony Stone wrote:
Hi.
https://wiki.asterisk.org/wiki/display/AST/Asterisk+16+Application_Originate
I need to use Originate() in a dialplan, pointing to another location
in the
same extension of the same context, so for example:
Originate(Local/${Dest}@Dialout,exten,${CONTEXT},${EXTEN},158);
I don't seem to be able to substitute the priority 158 with a label -
is this
deliberate or is this a bug?
If it is deliberate, is there any workaround which would enable me to
use
Originate when the dialplan is written in AEL, which makes it not
possible for
me to define priority numbers?
(Alternatively, is there a way to define priority numbers in AEL?)
I'd prefer the first solution - being able to use Originate with a
label as the
target - as it's neater and more generic.
Thanks,
Antony.
Hi Anthony,
I love to hear about AEL use-cases. I'm happy that AEL is working out
for you.
Without modifying the code for Originate(), you can do this while
staying purely in AEL
Here's your workaround:
context something {
s => {
Originate(Local/${Dest}@Dialout,exten,${CONTEXT},GotoLabel,1,,v(GotoExten=${EXTEN}^GotoLabel=LabelName));
}
GotoLabel => {
goto ${CONTEXT}, ${GotoExten}, ${GotoLabel};
}
}
And, additionally. You really *should* be breaking down components into
their own macros or extension blocks. Adding labels to jump into the
middle of an extension is typically a sign that you've outgrown your
overall design.
It's much. much. much easier to build a system up from different
contexts,extensions and use goto/gosub and make your system more modular
instead of having one-giant-context with one-giant-extension that tries
to do everything.
Hope this helps!
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
Check out the new Asterisk community forum at: https://community.asterisk.org/
New to Asterisk? Start here:
https://wiki.asterisk.org/wiki/display/AST/Getting+Started
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Originate with label?
On 8/29/22 08:31, Antony Stone wrote:
Hi.
https://wiki.asterisk.org/wiki/display/AST/Asterisk+16+Application_Originate
I need to use Originate() in a dialplan, pointing to another location in the
same extension of the same context, so for example:
Originate(Local/${Dest}@Dialout,exten,${CONTEXT},${EXTEN},158);
I don't seem to be able to substitute the priority 158 with a label - is this
deliberate or is this a bug?
If it is deliberate, is there any workaround which would enable me to use
Originate when the dialplan is written in AEL, which makes it not possible for
me to define priority numbers?
(Alternatively, is there a way to define priority numbers in AEL?)
I'd prefer the first solution - being able to use Originate with a label as the
target - as it's neater and more generic.
Thanks,
Antony.
Hi Anthony,
I love to hear about AEL use-cases. I'm happy that AEL is working out
for you.
Without modifying the code for Originate(), you can do this while
staying purely in AEL
Here's your workaround:
context something {
s => {
Originate(Local/${Dest}@Dialout,exten,${CONTEXT},GotoLabel,1,,v(GotoExten=${EXTEN}^GotoLabel=LabelName));
}
GotoLabel => {
goto ${CONTEXT}, ${GotoExten}, ${GotoLabel};
}
}
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
Check out the new Asterisk community forum at: https://community.asterisk.org/
New to Asterisk? Start here:
https://wiki.asterisk.org/wiki/display/AST/Getting+Started
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Originate with label?
Hi.
https://wiki.asterisk.org/wiki/display/AST/Asterisk+16+Application_Originate
I need to use Originate() in a dialplan, pointing to another location in the
same extension of the same context, so for example:
Originate(Local/${Dest}@Dialout,exten,${CONTEXT},${EXTEN},158);
I don't seem to be able to substitute the priority 158 with a label - is this
deliberate or is this a bug?
If it is deliberate, is there any workaround which would enable me to use
Originate when the dialplan is written in AEL, which makes it not possible for
me to define priority numbers?
(Alternatively, is there a way to define priority numbers in AEL?)
I'd prefer the first solution - being able to use Originate with a label as the
target - as it's neater and more generic.
Thanks,
Antony.
--
"this restriction will not apply in the event of the occurrence (certified by
the United States Centers for Disease Control or successor body) of a
widespread viral infection transmitted via bites or contact with bodily fluids
that causes human corpses to reanimate and seek to consume living human flesh,
blood, brain or nerve tissue and is likely to result in the fall of organized
civilization."
- https://aws.amazon.com/service-terms/ paragraph 42.10
Please reply to the list;
please *don't* CC me.
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
Check out the new Asterisk community forum at: https://community.asterisk.org/
New to Asterisk? Start here:
https://wiki.asterisk.org/wiki/display/AST/Getting+Started
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
