Re: Yate looses registration to external SIP accounts

How to enable registrations to Yate using domain name instead of IP

Need Assistance to configure Yate for SIP-H323 Proxy Setup

Embedded scripting proposal

Hi people!

We decided to introduce embedded scripting in Yate as a more powerful 
alternative to regexroute and external modules. We want to know your 
questions, opinions and improvement suggestions.

The reason to introduce scripting in Yate is to be able to perform complex 
routing and IVR like functions without the drawback of running an external 
interpreter. A script running in an external interpreter is slower to start, 
has more overhead processing the messages and cannot use all functionality of 
Yate. While regexroute can do arbitrary message processing it cannot keep a 
context associated with each call and the language itself is very weak.

We are choosing the Javascript language. It is simple enough to be used by 
beginners and basic functionality can be extended by experts. Moreover, there 
are several implementation libraries suitable for embedding.

We plan for the script instances to sit besides the controlled call legs just 
like pbxassist does now. The script will be able to control the call flow and 
route the call to various destinations.

A set of (Javascript) expressions will select which instruction block to 
instantiate for each incoming call, much like we do now in regexroute. Once an 
instance is created all further interaction will occur in that context.

// optional, reserved for future compatibility
language javascript

// include another file containing Javascript code
library "/path/to/library.js"

// declare a function we are going to use
function isAuth() {
	return username != "";
}

// send international calls of authenticated users directly to a gateway
// in this case there is no instruction block, just a route
called.match(/^00/) && isAuth()  ::  "sip/sip:" + called + 
" <at> gateway.xyz"

// unauthenticated callers are not allowed to call outside
called.length >= 4 && !isAuth() :: { error("noauth"); }

// secondary dialer, also declare it as a function
called == "1234" ::
secondary_dialer()
{
	answer();
	play("/path/to/prompt_file.au");
}

// alternative for the above
function secondary_dialer2() { answer(); play("/path/to/prompt_file.au"); }
called == "1235" :: { secondary_dialer2(); }

// match and use a global variable shared between all instances
getGlobal("chans_used") < 30 ::
{
	setGlobal("chans_used",getGlobal("chans_used")+1);
	...
}

// handling of later messages
called == "123456" :: {

	function onAnswer() {
		...
	}

	function onHangup() {
		...
	}

	// this code is executed on entering the block
	ring("tone/ring");
	sleep(1);
	answer();
	...
}

// include another scripting file with similar syntax
include "/path/to/next_script_control";

Paul

Re: Embedded scripting proposal

Re: Embedded scripting proposal

Re: Need Assistance to configure Yate for SIP-H323 Proxy Setup

Re: Embedded scripting proposal

On Mon, Oct 4, 2010 at 4:48 PM, Paul Chitescu <paulc@...> wrote:
> Hi people!
>
> We decided to introduce embedded scripting in Yate as a more powerful
> alternative to regexroute and external modules. We want to know your
> questions, opinions and improvement suggestions.
.....

I think scripting will be a great add-on for Yate, and as someone
pointed out a way to easily handle any message will be specially
useful ( I'm thinking in the kind of manipulations we are presently
truing to do with the regexroute mini-language could be done in two
lines of script, and having proper subroutines and variables will help
a lot ).

I understand the reasons to embed JavaScript, but I'll like to have
some language like python/perl with a more complete library. We are
presetnly developing some control modules for Yate using the external
module interface which need to read BerkeleyDb databases, perform
connections to some other servers speaking their protocol and I'm not
quite sure this can be done easily from JavaScript ( it cannot be done
from raw perl/python, but the modules to do it are there on CPAN and
similar, I'm not aware of anything similar for JavaScript ).

I think starting with JavaScript is right, but the interface to the
scripting engine should have some intermediate class or whatever
dessigned to make it easier to plug another scripting engine
implementation there.

Regards.

Francisco Olarte.

>
> The reason to introduce scripting in Yate is to be able to perform complex
> routing and IVR like functions without the drawback of running an external
> interpreter. A script running in an external interpreter is slower to start,
> has more overhead processing the messages and cannot use all functionality of
> Yate. While regexroute can do arbitrary message processing it cannot keep a
> context associated with each call and the language itself is very weak.
>
> We are choosing the Javascript language. It is simple enough to be used by
> beginners and basic functionality can be extended by experts. Moreover, there
> are several implementation libraries suitable for embedding.
>
> We plan for the script instances to sit besides the controlled call legs just
> like pbxassist does now. The script will be able to control the call flow and
> route the call to various destinations.

>
> A set of (Javascript) expressions will select which instruction block to
> instantiate for each incoming call, much like we do now in regexroute. Once an
> instance is created all further interaction will occur in that context.
>
>
> // optional, reserved for future compatibility
> language javascript
>
> // include another file containing Javascript code
> library "/path/to/library.js"
>
> // declare a function we are going to use
> function isAuth() {
>        return username != "";
> }
>
> // send international calls of authenticated users directly to a gateway
> // in this case there is no instruction block, just a route
> called.match(/^00/) && isAuth()  ::  "sip/sip:" + called +
> " <at> gateway.xyz"
>
> // unauthenticated callers are not allowed to call outside
> called.length >= 4 && !isAuth() :: { error("noauth"); }
>
> // secondary dialer, also declare it as a function
> called == "1234" ::
> secondary_dialer()
> {
>        answer();
>        play("/path/to/prompt_file.au");
> }
>
> // alternative for the above
> function secondary_dialer2() { answer(); play("/path/to/prompt_file.au"); }
> called == "1235" :: { secondary_dialer2(); }
>
> // match and use a global variable shared between all instances
> getGlobal("chans_used") < 30 ::
> {
>        setGlobal("chans_used",getGlobal("chans_used")+1);
>        ...
> }
>
> // handling of later messages
> called == "123456" :: {
>
>        function onAnswer() {
>                ...
>        }
>
>        function onHangup() {
>                ...
>        }
>
>        // this code is executed on entering the block
>        ring("tone/ring");
>        sleep(1);
>        answer();
>        ...
> }
>
> // include another scripting file with similar syntax
> include "/path/to/next_script_control";
>
>
> Paul
>

Re: Embedded scripting proposal

On 04/10/10 15:48, Paul Chitescu wrote:
> The reason to introduce scripting in Yate is to be able to perform complex 
> routing and IVR like functions without the drawback of running an external 
> interpreter. A script running in an external interpreter is slower to start, 
> has more overhead processing the messages and cannot use all functionality of 
> Yate. While regexroute can do arbitrary message processing it cannot keep a 
> context associated with each call and the language itself is very weak.
That's right with external scripts spawned when needed. But what is the
advantage of using built-in scripting -vs- global extmodule? They don't
have the starting overhead, text processing is pretty much minimal (if
you meant only the text parsing), they can keep the global context and
language can be chosen.
What is the gain here? (apart from raw performance on network
transmissions) Also, what functionality cannot be used from global
extmodules?

> We are choosing the Javascript language.
It's been mentioned by someone else too, but why:

> called.length >= 4 && !isAuth() :: { error("noauth"); }

instead of a "standard"
addRule(
   function(call) { return call.called.length >= 4 && !call.isAuth(); },
   function() { error("noauth"); }
);

This way, both sides of the rules can be named / reused, exported to
other functions, added and removed as needed, etc. etc.
Using more "standard" javascript could also be useful if someone wanted
to include external code. Also if you're going to run any known
Javascript VM, people could reuse extensions.

Regards,
Stan

Re: Embedded scripting proposal

On 10/04/10 17:02, Francisco Olarte (M) wrote:

(...)
I understand the reasons to embed JavaScript, but I'll like to have some language like python/perl with a more complete library. We are presetnly developing some control modules for Yate using the external module interface which need to read BerkeleyDb databases, perform connections to some other servers speaking their protocol and I'm not quite sure this can be done easily from JavaScript ( it cannot be done from raw perl/python, but the modules to do it are there on CPAN and similar, I'm not aware of anything similar for JavaScript ).

Since Yate is C++ (i.e. object-oriented) and since they have a libyate containing their base classes, it should be relatively easy to provide a language-consumer -independent API onto which language-consumers (i.e. interpretors, compilers, executors etc.) could be plugged in.

Something along the lines of what SWIG does in order to reconstruct an API created in a language for other languages (i.e. bindings).

Something similar to the way PHP extensions are written: using the ABI of C but providing primitives to another language (i.e. PHP) using some form of common abstraction (i.e. the "php_string", "php_int" etc. thingies).

Once again, something similar to the way PostgreSQL loads support for procedural languages at runtime using a plugin architecture based on a common, language-independent, abstraction of primitives available in SQL.


If that is done in an as lightweight and as straightforward a way as technically possible, we could have Yate drive code written in any language (and being driven, in return, by the same) -- even in multiple languages.

I think it would be great to be able to run a Yate instance that gets user data via Erlang's Mnesia distributed DB, does the IVR logic via a Lua script and eventually provides live load statistics via XML-RPC using ECMAScript

I think starting with JavaScript is right, but the interface to the scripting engine should have some intermediate class or whatever dessigned to make it easier to plug another scripting engine implementation there. Regards. Francisco Olarte.

Keep up the good work,
<at> Dexter