asterisk users - Sep 2004 - What about a higher level configuration language

Hi all.

I've been reading through Wi-Ki and at the extensions.conf file 
description (http://www.voip-info.org/wiki-Asterisk+config+extensions.conf)

The author says this:

"One day, someone is going to write a proper scripting language for 
Asterisk that can understand a simpler, easier (and more traditional) 
scripting syntax. All it would need to do is translate the "high
level"
scripting code into the "low level" stuff that is required here. But 
until then, we have to live with what we've got."

I just haven't use asterisk enough yet, so I wont be able to make the 
specifications, but I'm sure with the help of the community and if there 
are enough people needing/wating this, we can make a good language 
specification. Personally I can and will make the compiler from the 
higher level to current language, and even maybe vice-versa. Just need 
the specification of both languages and support of the comunity (if no 
one needs this it is not worthy).

Please, send oppinions and ideas about this.

RODOLFO


---
avast! Antivirus: Outbound message clean.
Virus Database (VPS): 0439-2, 24/09/2004
Tested on: 26/09/2004 15:04:00
avast! - copyright (c) 2000-2004 ALWIL Software.
http://www.avast.com

On Sun, 26 Sep 2004 15:03:58 +0200, Rodolfo Grave <rodolfograve@yahoo.es>
wrote:
> but I'm sure with the help of the community and if there
> are enough people needing/wating this, we can make a good language
> specification. Personally I can and will make the compiler from the
> higher level to current language, and even maybe vice-versa. Just need
> the specification of both languages and support of the comunity (if no
> one needs this it is not worthy).
If you want to build a strong house, you need a solid fundament. I
don't think the current configuration language is a good fundament to
build upon.

We would be well advised to first build that solid fundament before
thinking about higher level languages.

So how about a discussion to give Asterisk an XML based configuration as a base.

For backwards compatibility, the existing config language could then
sit on top of the XML as one alternative amongst others.

rgds
benjk

-- 
Sunrise Telephone Systems, 9F Shibuya Daikyo Bldg., 1-13-5 Shibuya,
Tokyo, Japan.

NB: Spam filters in place. Messages unrelated to the * mailing lists
may get trashed.

I see some discussion on "higher level config files" -- namely the
extensions.conf

I too, for several months, have been pondering the fact that priorities
are like "assembly language", or the line numbers in old BASIC
variants.

I've been thinking and investigating another extensions.conf language,
for which a compiler could be written to convert back to the normal
extensions.conf. The goal would be to get rid of priority numbers
altogether, enforce good programming style (code all the possibilities),
check the arguments to app calls, to make sure they are OK, and other
useful things.

My ideas run counter to a few of the examples provided, and I've not
quite "thunk" thru all the little issues yet, but it looks like a good
time to share at least some of my notes:



1. The new format will have macros, but with named arguments. That way,
we can verify the macro references.

2. The new format will use "blocks", like C, C++, and Java, with curly
brackets {}.

3. The new format will use labels, so Goto commands will go to a label,
not a priority number. Numbers should no longer appear anywhere in
Goto's. Contexts might/might not be necc, as labels could be global.

4. Applications and other commands that skip to new priority numbers
will have syntax, like labeled blocks, for each possibility. It will be
a syntax error to omit these. This forces the user to complete the
structure, and think about what to do in error conditions, so as not to
experience gross failure or strangeness when unexpected results are
encountered.

5. The start, timeout, illegal, etc. extensions will be given names. The
illegal, timeout, etc. blocks will be required for each context, at
least that have an extension.

Consider a current context format:

================================================================================[privacyManagerFailed]
exten => s,1,Background(tt-allbusy)
exten => s,2,Background(tt-somethingwrong)
exten => s,3,Background(tt-monkeysintro)
exten => s,4,Background(tt-monkeys)
exten => s,5,Background(tt-weasels)
exten => s,6,Hangup


[homeline]
exten => s,1,Answer
exten => s,2,SetVar,repeatcount=0
exten => s,3,Zapateller,nocallerid
exten => s,4,PrivacyManager
exten => s,105,Goto(privacyManagerFailed,s,1)
exten => s,5,GotoIf($[ "${CALLERIDNUM}" : "1"
]?callerid-bad|s|1:s|6)
exten => s,6,GotoIf($[ \"${CALLERIDNUM}\"  =
\"3078888888\" &
\"${CALLERIDNAME}\" : \"Privacy Manager\"
]?callerid-liar|s|1:s|7)
exten => s,7,System(/usr/local/bin/who-is-it ${CALLERIDNUM}
"${CALLERIDNAME}"&)
exten => s,8,GotoIf($[ \"${CALLERIDNUM}\" =
\"3077777777\" |
\"${CALLERIDNUM}\" = \"3076666666\" ]?s|9:s|10)
exten => s,9,SetMusicOnHold(mohlds)
exten => s,10,Background,homeline-intro1  ;; Script: Hello-- Welcome
blah blah...


================================================================================
A new way to put it:


================================================================================context
homeline
{
	start
	{
		Answer();
		repeatcount=0;
		Zapateller(nocallerid);
		PrivacyManager() Fail					{
					Background(tt-allbusy); 					Background(tt-somethingwrong);
					Background(tt-monkeysintro); 					Background(tt-monkeys);
					Background(tt-weasels);
					Hangup();
					};
		if $["${CALLERIDNUM}" : "1" ]
			callerid-bad;
		if $[ \"${CALLERIDNUM}\"  = \"3077545675\" &
\"${CALLERIDNAME}\" :
\"Privacy Manager\" ]
			callerid-liar;

		System(/usr/local/bin/who-is-it ${CALLERIDNUM}
"${CALLERIDNAME}"&)
Fail = {};

		if $[ \"${CALLERIDNUM}\" = \"3075274255\" |
\"${CALLERIDNUM}\" \"3077548154\" ]
		{
			SetMusicOnHold(mohrock);
		}
	play_it_again_sam:
		Background(murphy-homeline-intro1);

	}
1	{
	System(/usr/bin/play /var/lib/asterisk/sounds/call-for.gsm|0)
	System(/usr/bin/play
/var/spool/asterisk/voicemail/default/2/greet.wav&|0)
	Dial(Zap/3r1&Zap/5r1&Sip/sonya|35|mt) Unavailable={    // Ring the
interface, 20 seconds maximum
								Voicemail2(u2);         // If unavailable, send to voicemail w/
unavail announce
								Hangup;                 // If they press #, return to start
						  	    }
						Busy={
							Voicemail2(b2);          // If busy, send to voicemail w/ busy
announce
							Hangup;                  // If they press #, return to start
							};
	}

2   {
		Goto homeline_kids;
    }

3   {
		...

	}

4   {

	VoicemailMain2();
	Goto play_it_again_sam;
    }

	fax { Dial(Zap/4) Busy={} Unavailable= {};  }
	
	timeout 
	{
		repeatcount = $[${repeatcount} + 1];
		if $[ ${repeatcount} < 3] 
			play_it_again_sam;
		else
		{
			Hangup();
		}
	}
	invalid
	{
		Background(invalid);
		goto play_it_again_sam;
	}
		
}

In the above, start, timeout, invalid, and fax are all special extension
names. 

A number like 99, or a pattern would all serve as an extension name,
just as in the original format. In the above, 1,2,3,4 are all
pattern/extension names. 

All the applications and commands that would or could cause a
redirection in the flow of statements will have alternative, hard-wired
labels associated with them, (like "Busy" and "Unavailable"
in the dial
command) that you must supply either a label reference, a block of
{instructions;} of code, or a null or empty block of instructions {}.
Here is a list I made a while back of all the commands that played with
the priority:
	ChanIsAvail()  +101
	DBGet()         +101
        Dial            +101 (and +201, and +301, after privacy updates)
        EnumLookup()   +101
        CheckGroup()   +101
	HasVoicemail() +101
	SendImage()     +101   (and possible -1 return value)
	LookupBlacklist  +101 
	Macro()           --returns to next line after call
	OSPLookup()      +101
	OSPNext()         +101
	OSPFinish()       +100?
	ParkAndAnnounce()  --jumps
	PrivacyManager()   +101
	AddQueueMember()   +101
	RemoveQueueMember() +101
	SendText()           +101
	System()              +101, also -1 return poss.
	Transfer()            +101
	TXTLookup()    +101
	SendURL()       +101
	Voicemail[2]()   +101
	MailboxExists()   +101
	AgentMonitorOutgoing()  +101
Each path out of the application will have to be named, like "Busy",
"Unavailable", "Error", etc, and also the -1 return results
should be
caught and have a path name also, as with System(). (I had no idea there
is a "u" extension to handle -1 result codes?)

Null blocks on labeled alternative could yield a warning. Missing
alternatives generate syntax errors... This seems like a hassle, but
really, you don't want strange things to happen if you don't code for an
error condition, do you? Such complicates the syntax for the config
file, but pays back for it in forcing coders to be complete.

Each app/command should have its own entry in the grammar; that way, we
can verify the arguments and do a proper syntax check for each arg, with
clear diagnostics.

That's my two cents, direct from the notes I've been making over the
last months. I see some overlap with ideas already expressed... which is
good! I love serendipity.

I don't think that changing the extensions.conf is necessary. These
kinds of features could be provided as a "front end" set of tools for
configuring asterisk. A simple make in /etc/asterisk/, for instance,
could update extensions.conf from this new config language, and send
asterisk the "extensions reload" command, if there are no errors, or
somesuch.

murf




-- 
Steve Murphy <murf@e-tools.com>
Electronic Tools Company

> > I like the example provided above. Essentially it is starting to look
> > like a programming language more evolved than early 80s BASIC. If you
> > could add labels to the language where we could do something like
> > goto(context,exten,label), or similarly, if we could get functions
built
> > into it, we would have solved the need for macros.
> >
> as an old prog lang guy, i would recommend funcs, macros, but no
> labels/gotos.  ancient religious discussions omitted :-).
> 
Gotos are evil.

-- 
   _/   _/  _/_/_/_/  _/    _/  _/_/_/  _/    _/
  _/_/_/   _/_/      _/    _/    _/    _/_/  _/   K e v i n   W a l s h
 _/ _/    _/          _/ _/     _/    _/  _/_/    kevin@cursor.biz
_/   _/  _/_/_/_/      _/    _/_/_/  _/    _/