Re: [asterisk-users] extensions.conf vs. AEL
All this discussion is pointless. As pointless as the discussion of assembly versus high-level languages decades ago. Except most people rooting for "extension.conf" don't even have the technical and conceptual amplitude to understand what they are talking about... they just want some telephony system to make a quick buck, or save in their LD calls... A lot of Asterisk is technically and architecturally twisted, and "spaghettied", and with many redundant ways of doing the same thing (in different stages of obsolescence, incompleteness, and (un)documented). At least AEL is a step in the right direction (even though it has to adapt itself to the ugliness that exists below..) BarZ Steve Murphy wrote: > On Wed, 2007-10-03 at 09:33 -0600, Anthony Francis wrote: > >> Eric "ManxPower" Wieling wrote: >> Let us not forget that AEL cannot be stored in a database therefore rendering you unable to utilize realtime. >>> AEL converted into standard extensions.conf syntax in the dialplan. >>> >>> >>> >> Doesn't this render having used AEL pointless? >> >> > > Absolutely not! > > Reasons to use AEL: > > 1. Several semantic checks are done on the AEL that are NOT done if you > go straight to extensions.conf. We try to protect you... from yourself. > > 2. At least one security issue in USAGE is avoided by having AEL compile > the corresponding code; as to how many more issues will automatically be > handled via > AEL in the future, is impossible to say. We'll see. If you keep coding > via > extensions.conf, be prepared to make corrections... if you do it in AEL, > a restart of Asterisk will hopefully suffice, after AEL is updated. > > 3. Syntax errors are reported by AEL. It is pretty good at catching all > omissions > and commissions. Better than the extensions.conf parser is. For example, > I don't > know if we catch it now, but if you accidentally say "extem => 3,..." > instead of > "exten => 3,..." in extensions.conf, that line will silently be dropped. > Sure, we > could fix this, but to fix ALL possible problems will require an > expensive rewrite of the config file parser, from the ground up. > > 4. You are insulated against any mods to extensions.conf; like the > change to ',' instead of '|' in app arguments. No changes to AEL code > are necessary. > > 5. In extensions.conf, you have to feed your dialplan to asterisk to > find any problems. AEL provides the standalone parser, aelparse, so you > can correct any problems BEFORE feeding it to a living asterisk. > > 6. AEL is easier to read, IF you take advantage of the ability to use > tabs, etc. wisely. Especially for nested code. Staying away from goto as > much as possible, > and using the flow of control and looping statements will make your code > easier to read, compose, and maintain in the future. It means fewer bugs > in your code, > and overall this all means lower cost. And higher profits. > > 7. Repetitious entry of "extenname, priority," in your tabular > extensions.conf can lead to subtle errors that could be hard to find, > ESPECIALLY if you resort to using priority NUMBERS instead of "n". And, > if you ARE so foolish as to use just raw numbers, and you have to insert > or delete a line or two, you have to renumber > the remaining lines, and heaven help you if you make a simple error, and > accidentally skip a number. > > 8. Work flow. Since aelparse allows you to dump the compiled dialplan in > extensions.conf format, you can still use stuff like realtime. You can > use this output against machines that don't even have pbx_ael loaded, > then, and you should be able to use 1.4 compiled dialplans on 1.2 > machines, as long as you are careful about what apps you call, and how > you call them. > > 9. Easier to write code. Good Code. using Goto's in extensions.conf will > allow you to do anything you need to do, but it also results in > spaghetti style code. > While the original author might be able to decrypt it, and maintain it, > unless it's really well commented, the next guy to play with it, is > going to have a hard time. Following the flow of control thru spaghetti > can get your adrenalin flowing-- and side affects from strange cases and > leakage in the spaghetti can make some devilishly hard to solve > problems. > > Think of and treat extensions.conf like assembly code. > > Think of and treat AEL like a high(er) level language. For those who > never did the computer science thing, I have just one piece of advise, > and ignore this at your peril: your dialplan is a work of computer > programming. It's software. If you don't treat it that way, and use good > software methodologies, you'll pay your price. > > murf > > > > > > > ___ > --Bandwidth and Colocation Provided by http://www.api-digital.com-- > > asterisk-users mailing list > To UNSUBSCRIBE or update optio
Re: [asterisk-users] proposal: a new mailing list for asterisk 1.4, why not?
An equally unrealistic expectation would be to require that people write RELEVANT and specific Subjects. If your question relates to 1.4, put "1.4" somewhere in the Subject, or if it relates to unreleased trunk, specify it. So you can quickly filter out/in whatever your interests are. But as I said... it's an unrealistic expectation. BarZ S Kenneth Padgett wrote: No, it would be yet another list that people would have to subscribe to, and many of the questions/answers for one version are quite relevant to the other. Can't we just require everyone on this list to upgrade to v1.4? :) I'm sure in due time they will anyway. -Kenneth ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] weird undocumented extensions such as s-BUSY
Andrew Kohlsmith wrote: On Tuesday 23 January 2007 1:16 pm, Barzilai Spinak wrote: So, in sum. It's just an Asterisk "idiom" or "best(?) practice" that has become somewhat common. Every time I need to do the smallest thing in Asterisk I have to Google for 3 hours and read voip-info for the more hours, and then read old mailing list post for 3 more, until I can filter out *real information* from the background noise. Maybe it's just me... I don't settle with the first solution that "SeemsToWorkForNow, even though I have no idea Why or How" Ah... the wonders of Early 21st Century Web Fashion and documenting everything in big lumps of Little-Ultra-Hyper-Linked-Wiki-pages with contradictory and obsolete info Hopefully it will end some day and the world will come back to its senses. After you're done hyperventilating, feel free to contribute documentation which you find is meaningful, current and insightful. Too much heat here to be hyperventilating :-) Open-source in general is very much a "get your hands dirty" kind of software experience. This means that you are expected to play around, experiment, and ask good questions, ALL without throwing a little tantrum as you just did. I have been getting my hands dirty for years with many kinds of OSS. What I was trying to experess by my hyperventilation is that: a) There has been a trend in the past 2-4 years of thinking that Wikiing mounts and mounts and mounts of hyperventilated (err.. linked) "recipes" and general babbling amounts to "documentation". b) The Asterisk project in particular is worst than most OSS I've seen in this respect. Maybe "aided" by the fact that most people producing said "documentation" seem to be of the not-so technical kind and just are eager to make a quick buck by selling cheap long distance calls, so at best they just rehash someone else's recipe with a comment along the lines of "this worked for me!". All this on an OSS project which has a multi-million dollar company behind it... I'm not complaining, I'm just hyperventilating some frustrations. If you want current manuals, completely stable software and someone to yell at when your system breaks, Digium offers that, too. It's called Asterisk Business Edition. I don't want the impossible "current manuals" as much as a current and comprehensive documentation of the architecture without all the noise from obsoleted/deprecated entities and contradictions from one wiki page to the next one touching a related concept. Otherwise, dig in, experiment and try to leave the place a little cleaner than you left it.. Cleaning... I should start with my own office :-) Believe me,. I've tried many times to comb through all voip-info.org and compiling something sensible for myself as many times I've abandoned the effort out of frustration... I don't even know where to start! It's not a matter of cleaning up, but a matter of doing it cleanly the first time. I'll keep trying though and then i'll contribute it ok.. it's finally raining now!!! done hyperventilating BarZ ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] weird undocumented extensions such as s-BUSY
So, in sum. It's just an Asterisk "idiom" or "best(?) practice" that has become somewhat common. Every time I need to do the smallest thing in Asterisk I have to Google for 3 hours and read voip-info for the more hours, and then read old mailing list post for 3 more, until I can filter out *real information* from the background noise. Maybe it's just me... I don't settle with the first solution that "SeemsToWorkForNow, even though I have no idea Why or How" Ah... the wonders of Early 21st Century Web Fashion and documenting everything in big lumps of Little-Ultra-Hyper-Linked-Wiki-pages with contradictory and obsolete info Hopefully it will end some day and the world will come back to its senses. BarZ ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] weird undocumented extensions such as s-BUSY
I've seen several examples that use extensions such as; s-BUSY s-NOANSWER etc... It's more or less evident what they do, but I've searched for some FORMAL documentation everywhere and have found nothing. Do they work for anything else than "s-"? (I think I've seen other examples, but can't find them now) Are they standard in any way? What are the allowed values after the dash? In which version were they introduced? etc... (please no replies explaining me how "s-BUSY" matches when the start extension is set busy or trivial explanations like that) BarZ ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] How to limit IAX calls
Aaah... I'll try that...
A simple variable would be so much easier... :-)
BarZ
Jonathan k. Creasy wrote:
A demonstration:
exten => _X.,1,Set(GROUP()=${CALLERID(num))
exten => _X.,n,Set(CDR(AccountCode)=${CALLERID(num))
exten => _X.,n,GotoIf($[${GROUP_COUNT(${CALLERID(num))} > 2]?103)
exten => _X.,n,Macro(trunk,${EXTEN},residential)
exten => _X.,n,Hangup
exten => _X.,103,Playback(allison7/all-circuits-busy-now)
exten => _X.,n,Hangup
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Marco Mouta
Sent: Friday, January 19, 2007 6:55 AM
To: Asterisk Users Mailing List - Non-Commercial Discussion
Subject: Re: [asterisk-users] How to limit IAX calls
Take a look on:
Dialplan applications:
GetGroupMatchCount([EMAIL PROTECTED])
SetGroup([EMAIL PROTECTED])
Using this two applications you can deploy a max calls control inside
your dialplan!
check this too: http://www.voip-info.org/wiki/view/Asterisk+cmd+SetGroup
Hope it helps
On 1/19/07, Barzilai Spinak <[EMAIL PROTECTED]> wrote:
The SIP channels have a "call-limit" parameter (which is badly
documented and I haven't tested yet)
How can I have the same behaviour for IAX channels? I can't see anything
related to it.
Ah, I'm using Asterisk 1.2.13... maybe there is something in the 1.4
versions... but I can't change to 1.4 right now because of MFC/R2
BarZ
___
___
--Bandwidth and Colocation provided by Easynews.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
___
--Bandwidth and Colocation provided by Easynews.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] How to limit IAX calls
The SIP channels have a "call-limit" parameter (which is badly documented and I haven't tested yet) How can I have the same behaviour for IAX channels? I can't see anything related to it. Ah, I'm using Asterisk 1.2.13... maybe there is something in the 1.4 versions... but I can't change to 1.4 right now because of MFC/R2 BarZ ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] no unicall on 1.4
Last week I spent a couple of nights understanding and modifying libmfcr2. After a few hours, the almost comment-free code starts to make sense (although I would have done many things differently). As far as I understand it, most (affected/complaining) people are mostly interested in the MFC/R2 aspect of Underwood's libraries so they can have their R2 E1 cards working under Asterisk. This is most of the world (not just third world countries). libmfcr2 depends on spandsp (DSP processing), and libunicall (call management). The part that *actually* interfaces with Asterisk is the "chan_unicall". So, *I think* there's no need to maintain and adapt the full stack, but only the "chan_unicall" because MAYBE the Asterisk channel API changed (a little, a lot???) from 1.2.x to 1.4.x. Maybe a little debugging of libmfcr2 also... With enough time I could help, but I'm trying to move away from telephony right now... I have other projects and areas of interest... Now, the two unanswered questions: 1) Why is Steve stopping support for Asterisk? I understand he may be fed up with Asterisk... but probably he can fix it or half-fix it for 1.4 in a couple of days, then the rest of us can debug it. 2) Why is it that Digium never gave a damn about E1/MFC/R2 and we have to use these hybrid combinations of libraries? BarZ Moises Silva wrote: On 1/3/07, Anton Krall <[EMAIL PROTECTED]> wrote: And probably wont be as Steve Underwood explained to me that he is now supporting openpbx and has stopped support for unicall on asterisk 1.4 Can anybody at digium confirm? Is unicall going to be left out of 1.4? This has nothing to do with Digium, it has to do with anybody wanting to code the version for 1.4, AFAIK Steve never worked for Digium and Digium never distributed Unicall driver. Porting Unicall to 1.4 is in my TODO since 1 month ago, may be this month I will have the time to give a look at the code and try to make it work on 1.4, if somebody else cant do it before. Regards. ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] 1.4 and unicall
I asked the same a while ago, without any kind of conclusive answer. But you have to consider that these are special dates I just spent all night studying/modifying mfcr2.c to my needs but I've never looked at the unicall code or the asterisk channel API. With respect to MFC/R2, and according to what it saw, it seems fairly complete on the incoming part of the protocol, but the outgoing logic is kind of crude. I wonder if Steve Underwood is still actively working on it. BarZ Anton Krall wrote: No update on unicall and 1.4? |-Original Message- |From: [EMAIL PROTECTED] [mailto:asterisk-users- |[EMAIL PROTECTED] On Behalf Of Anton Krall |Sent: Tuesday, December 26, 2006 6:15 AM |To: asterisk-users@lists.digium.com |Subject: [asterisk-users] 1.4 and unicall | |Guys, anybody knows if 1.4 has support for unicall or if/which version of |unicall will compile on it? | | |___ |--Bandwidth and Colocation provided by Easynews.com -- | |asterisk-users mailing list |To UNSUBSCRIBE or update options visit: | http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Unicall's MFCR2 with Asterisk 1.4
It would be great if the original author (Steve Underwood?) could do it :-) I want to try 1.4 so I can have AEL2 support, mainly, but I also need MFC/R2 for E1's. Yes.. I can patch AEL2 into 1.2 but why all the hassle? I haven't studied the code and I know almost nothing about the Asterisk channel API, and much less how it might have changed from 1.2 to 1.4. Well.. maybe next week I'll give it a try after I come back from my trip. These libraries should be natively included into Asterisk, as at least half of the world uses E1... BarZ Moises Silva wrote: Yes, you are right, as I said, you need to adapt chan_unicall.c to the 1.4 * version, it should not be hard, let me know if you have problems and may be i will be able to help you. Kind Regards On 11/4/06, Barzilai Spinak <[EMAIL PROTECTED]> wrote: Yea. but is the current chan_unicall.c compatible with Asterisk 1.4? I don't know how much the channel API changed from 1.2 to 1.4. The patch for the Makefile I guess I could fix it by hand BarZ Moises Silva wrote: > libunicall, spandsp, libmfcr2 are independent from Asterisk version, > the only thing you need to adapt for each Asterisk version is > chan_unicall.c > > Best Regards > > On 11/3/06, Barzilai Spinak <[EMAIL PROTECTED]> wrote: >> Is there any way to compile Unicall's libraries (mfcr2, spandsp, >> chan_unicall, etc) for Asterisk 1.4? >> >> BarZ ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Unicall's MFCR2 with Asterisk 1.4
Yea. but is the current chan_unicall.c compatible with Asterisk 1.4? I don't know how much the channel API changed from 1.2 to 1.4. The patch for the Makefile I guess I could fix it by hand BarZ Moises Silva wrote: libunicall, spandsp, libmfcr2 are independent from Asterisk version, the only thing you need to adapt for each Asterisk version is chan_unicall.c Best Regards On 11/3/06, Barzilai Spinak <[EMAIL PROTECTED]> wrote: Is there any way to compile Unicall's libraries (mfcr2, spandsp, chan_unicall, etc) for Asterisk 1.4? BarZ ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
[asterisk-users] Unicall's MFCR2 with Asterisk 1.4
Is there any way to compile Unicall's libraries (mfcr2, spandsp, chan_unicall, etc) for Asterisk 1.4? BarZ ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
Re: [asterisk-users] Unicall stack, right versions?
Thank you Steve. About the configs in Asterisk... I confess that I'm new to the code so I still need to read more. I didn't know about ast_config() About the hardcodedness of the countries... that seems to be the "problem". Everything is too oriented to "my country works like this with this telephone company". When in fact, what I'm using is not even to connect it to a the telephone company of my country but to some other machine which has an old Call Center implementation with some other modification of the MF R2 sequence. It doesn't relate specifically to any country. Yes, they are all similar, and being able to specify the number of ANI and DNIS/DID is sometimes all you need, that's why I could make it work. There's some truth in your statement that opening the configuration to external files may get some people into trouble. On the other hand, what I see is a strange mix of: a) If you're doing telephony stuff you should know what you're doing b) Most people using Unicall (Asterisk for that matter) have very little idea of what they are doing and why (copying and pasting configs from here and there). So, where's the sweet spot? :-) I can spend 1 hour reading the source code and finally knowing how to change it to my needs. (For example, adding a new "country") Should I need to? Can people from the (b) set do it? Is it scalable? What is more of a support nightmare? Please take all this as constructive comments. I really appreciate your work and if I had to do it from the start it would take me months longer!!! A real question that should go in a different mail, but what the check: Let's say I have two E1 spans, but one needs to talk CountryFooVersion, and the other needs CountryBarVersion (yes, both on the same machine and in the same "country", maybe different number of digits for ANI). How would I go about configing that? Thanks BarZ Steve Underwood wrote: Barzilai wrote: Last night I started compiling all the components of the Unicall stack. So far I've been able to successfully do a "testcall". A couple of questions: 1) If you download the "snapshot" libraries, a funcion that used to be called "dtmf_put" now has been changed to "dtmf_tx_put", however the client code from the other library (I forget which one atm) still uses the old name so I had to fix it. Don't use the snapshots. If you use the latest releases this won't happen. 2) the Makefile patch for the Asterisk channel seems to be for the 1.1.x versions of Asterisk. In the snapshots there's a patch that seems to be for the 1.2.x versions but I haven't tried it yet. Does it work as is or do I have to "patch the patch"? for Asterisk 1.2.9? There hasn't been a need to update the software for some time. The 1.1.x directory works fine with 1.2.x. I should have changed that. Sorry. In sum, what is the most up-to-date AND stable combination of libraries for the Unicall stack? The latest release is, well, the latest release. P.S. 1: A lot of Unicall seems to be hardcoded in the .h and .c files, like the countries and how they behave... I *might* attempt to do something more flexible if I have time *and* brush up my C which I haven't used much in the last 4 years. Bad idea. Its like that for a reason. The present arrangements make support much much simpler. Things like Dialogic, where R2 is alsmost completely configured in config files still end up hard coding a few things. Those config files cause support trouble, though. In my code the variations needed within countries are already allowed for. The whole Unicall scheme is being heavily reworked right now, to separate out the hardware specific elements into their own modules. Hard coded support for countries is something I won't be changing, though. P.S. 2: A lot of behavior in the Asterisk ecosystem seems to be replicated over and over in the different parts of the code, for example the reading of configuration files, which each programmer does in their own way. How about some generalized configuration code module? Maybe this question is better for the dev list. Chaos seems to be the Asterisk way. :-) Steve ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users ___ --Bandwidth and Colocation provided by Easynews.com -- asterisk-users mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
