[asterisk-dev] Re: asterisk-dev Digest, Vol 24, Issue 84

Sun Jul 30 13:02:48 MST 2006

I believe that is by design.  Technially, a Macro definition is NOT a 
context, but rather, a definition space.

So, technically, it cannot accept digits, since it's not a context.  Only a 
context can accept digits, hence, sending it back to the context from which 
it was called.

I'm not 100% on this, but I believe this is right.

It all boils down to:  A Macro, i.e. [macro1] is NOT a context, but merely a 
namespace to define a macro.  Since it's a namespace, and not a context, it 
can't accept digits like a context would.

I do not believe a Macro will do what you are attempting.  You'll have to 
define your menus inside a context.

----- Original Message ----- 
From: "Dovid B - Asterisk Dev." <AsteriskDev at Dovid.net>
To: <asterisk-dev at lists.digium.com>
Sent: Sunday, July 30, 2006 2:33 PM
Subject: [asterisk-dev] Re: asterisk-dev Digest, Vol 24, Issue 84

> This issue is a known issue and I posted it on the bug tracker and I was 
> told on there that I should post on here first and see if anyone is 
> willing to do it for money (first option was to develop it myself but I 
> cant code well).
>
> Dovid
>
>>
>> Message: 7
>> Date: Sun, 30 Jul 2006 09:58:00 -0500
>> From: Steven <critch at basesys.com>
>> Subject: Re: [asterisk-dev] Asterisk functinality
>> To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
>> Cc: david at david.net
>> Message-ID: <1154271481.575.21.camel at bedroom.comcast.net>
>> Content-Type: text/plain
>>
>> This is not s developer question. Unless you have a reproducable bug in
>> code and can point out exactly why it is a bug, or are discussing
>> something that needs to be coded, you should not post to the developer
>> list.
>>
>> Your question is about how to use asterisk. This means you are an
>> Asterisk user and your questions belong on the asterisk-user list.
>>
>> On Sun, 2006-07-30 at 08:34 -0400, Dovid B - Asterisk Dev. wrote:
>>> At the time I can not offer a lot of money for this feature. Tried to
>>> make a bounty on voip-info but I can't seem too (been up for a few
>>> days now). I am offering $35.00 for this. Here is what I orig. put on
>>> bug tracker.
>>>
>>> I was trying to make the following macro that would allow a user to
>>> make a
>>> menu selection. As of now when I use it and make a selection when a
>>> digit
>>> is pressed it goes to the context that sent it to the macro and it
>>> looks
>>> for that digit in that context (the one that sent the call to the
>>> macro):
>>>
>>> Exten => 123,1,Macro(voice-file,open,s,1,closed,s,1)
>>>
>>> [macro-a]
>>> exten => s,1,Set(TIMEOUT(response)=5)
>>> exten => s,2,Background(${ARG1})
>>>
>>> exten => 1,1,Goto(${ARG2},${ARG3},${ARG4})
>>>
>>> exten => 2,1,Goto(${ARG5},${ARG6},${ARG7})
>>>
>>>
>>> Please reply to dovid _AT_ dovid _DOT_ net
>>> _______________________________________________
>>> --Bandwidth and Colocation provided by Easynews.com --
>>>
>>> asterisk-dev mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>>
>>
>> ------------------------------
>>
>> Message: 8
>> Date: Sun, 30 Jul 2006 17:27:54 +0300
>> From: Tzafrir Cohen <tzafrir.cohen at xorcom.com>
>> Subject: Re: [asterisk-dev] automatic "ztcfg" for analog cards
>> To: Asterisk Developers Mailing List <asterisk-dev at lists.digium.com>
>> Message-ID: <20060730142754.GB25503 at xorcom.com>
>> Content-Type: text/plain; charset=us-ascii
>>
>> On Sun, Jul 30, 2006 at 09:53:01AM -0500, Steven wrote:
>>> On Sun, 2006-07-30 at 10:54 +0300, Tzafrir Cohen wrote:
>>> > Hi
>>> >
>>> > I said before that ztcfg should not be necessary for analog cards...
>>> > So here is http://bugs.digium.com/view.php?id=7613 to implement it.
>>> >
>>> > This patch generlly does two things:
>>> >
>>> > 1. Moves almost all the functionality of the ioctl ZT_CHANCONFIG to a
>>> > separate function.
>>> >
>>> > 2. Calls that function from the end of zt_register for each channel if
>>> > exactly one of the following two conditions hold:
>>> >
>>> > * The channel is capable of fxoks signalling
>>> > * The channel is capable of fxsks signalling
>>> >
>>> > In such a case the channel is probably an analog channel. This seems 
>>> > to
>>> > also hold for TDM400P/2400P cards: slots with no modules have both
>>> > capabilities whereas slots with a certain module have just one 
>>> > specific
>>> > capability.
>>>
>>> Those signalling choices are also available for T1 spans.
>>
>> Yes. Both of them. Hence it should not be affecte. I did ask for
>> examples where this breaks.
>>
>> Maybe it should be further tweaked. Maybe there should be some sort of
>> blacklist or whitelist of availble capabilities or driver names, or the
>> driver should provide an extra field in struct zt_span.
>>
>> This is why I asked for inputs from others.
>>
>>>
>>> > I consider KS a very sane default. If one needs LS or GS, ztcfg can
>>> > always be used. But for most people this would just work. You'd just
>>> > have to set the coutry on zaptel.conf, and that can never fail.
>>>
>>> So this shortcut is for those on the lower end of the zaptel deployment
>>> scale
>>
>> And making their life much easier with no price for you (have you
>> noticed the extra module variable (run-time settable) that configures
>> this behaviour meaningless to you?
>>
>>> and yet does nothing for the rest except put more lines of code
>>> into the drivers that potentially could have a bug now or later.
>>
>> IMHO the current behaviour of automatic run of ztcfg on modprobe is
>> buggier, as it generates false "modprobe errors".
>>
>> This now, along with a few other small patches I wrote, makes Zaptel
>> hardware truely hotpluggable. There may be other ways of implementing
>> it, but they seem more complicated.
>>
>> Any decent method for auto-configuring zaptel channels/spans on
>> connection requires some exposure of spans information. Note the zero
>> replies I got to my previous post. As it seems now, that will be a major
>> change and will happen some time in the distant future.
>>
>> This is a simple patch that Just Works and is small enough to add to our
>> distro even if upstream does not like it.
>>
>> -- 
>> Tzafrir Cohen         sip:tzafrir at local.xorcom.com
>> icq#16849755          iax:tzafrir at local.xorcom.com
>> +972-50-7952406          jabber:tzafrir at jabber.org
>> tzafrir.cohen at xorcom.com     http://www.xorcom.com
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> --Bandwidth and Colocation provided by Easynews.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>>
>> End of asterisk-dev Digest, Vol 24, Issue 84
>> ********************************************
>>
>>
>
> _______________________________________________
> --Bandwidth and Colocation provided by Easynews.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
> 