Version 1.2.5 of SafiServer (linux and windows) and SafiWorkshop (windows) are now available for download. You will need to uninstall any older version before installing the new version. Also, be sure to backup your Projects and Saflets in a SAR file and/or backup any workspaces you have (located by default in the SafiWorkshop install directory).

There are mostly bug fixes in this release and some changes to the way we're versioning the product.

Please let us know if you encounter any issues: Safi Systems Forums

Thanks,

Eric

First off, thank you everyone who has been posting in the forums and sending us emails! We live off your feedback and in turn we've been able to address quite a few issues in our 1.2 release. These updates/fixes are available through our updates site. Also, make sure to "push" any pending updates to your SafiServer (from the SafiServer view tab).

NOTE: You should be prompted to update when SafiWorkshop starts, but you can also go to: Help::Update

We've also been getting quite a few post and emails regarding the qualifying strings with quotes. This may be a little confusing as it wasn't always the case in our system. We decided that in order to maximize the flexibility of our system, we would switch to having our scripting engine handle most ActionStep properties (the fields with the blue background). This change allows users the ability to enter short scripting statements directly in the property field without having to open up the Dynamic Value Editor.

So in short this means that if you want to put a literal string value in a field; you must qualify (surround) it with quotes (e.g. "test"). For example: when evaluating captured DTMF digits; you will need to have the digit(s) that you are comparing to surrounded by quotes (as the value captured is a string not a number).


On a completely separate note, one of our users (kevinb) has graciously set up an IRC channel for users of SafiServer/SafiWorkshop. The channel is: #safiserver on Freenode.Net. You can use your favorite IRC client or click here for the web chat access. We will try to be in the channel as often as we can.

-Eric

This is a seminal release for us as the product is now more stable, powerful, and easy to use than ever.  We've also added a new ActionStep "CallWSByWSDL" that allows you to easily consume Web Services from your Saflet, providing you with even more integration possibilities for your IVR/Callflow applications.  The release of this ActionStep is merely the first of many non-telephony-specific ActionSteps that are in the works, representing an overall commitment to making SafiWorkshop and SafiServer the most flexible and powerful development and integration tools for Asterisk on the market (free or otherwise). 

The Web Services integration functionality is currently in Alpha and we'd love to hear your feedback and ideas for how to improve it.  This screencast should help get you started.

Here's a summary of some of the changes with this release:

SafiWorkshop

• Added Web Services features (alpha)
• Undo/Redo now works correctly for ActionStep dialogs
• Fixed bug where moving ActionStep connections would fail and cause workshop to hang
• (UI) Variables all synched up appropriately with SaifServer and editors.
• Added pre-execution busy check for the Extension ActionStep
  
• Fixed issue with deleting Saflets on SafiServer
• Added recursive audio file import for Asterisk system prompts
  
• Added full channel support (i.e. Local, SIP, ZAP, IAX, etc) for Extensions ActionStep
• Performance improvements and bug fixes for Prompt Manager
• Fixed bug in SAR (Safi Archive) imports causing null pointer exception
• Added auto-complete for all Dynamic Value editors.
• Variable editor enhancements

• Fixed an issue causing the SafiServer to bind to an invalid IP address in some cases
• Fixed Global variable issue.
• Improved Linux install script that installs SafiServer as a service
• Added ami.retry.period property to environment.properties to control how frequently to retry broken manager connection (in seconds)
  
• Added useManagerPing (true/false) to environment.properties to toggle the manager "ping" function (ping command is broken in some versions of Asterisk 1.6.x)
• Removed bind.ip from environment.properties and install scripts.
• Fixed issue with certain linux (e.g. Ubuntu) distro picking up wrong localhost ip address and route based on misinformed hosts file information.

So I came across a photo we took back in August on the day we released SafiServer and SafiWorkshop as open source projects:



Nothing quite like some beer, good friends, and some strong coding on a nice summer day.

-Eric

This update includes all previous updates and includes the following:

1. An improvement to the SafiServer ssh tunneling system for better NAT traversal characteristics. Of course this update won't help you much if you currently can't connect to the SafiServer due to NAT issues since you won't be able to push the files :) For you a new installer is forthcoming.

2. bind.ip property in environment.properties is no longer used.

3. Additional parameter added to Asterisk server registration info for SafiServer IP accessible from the Asterisk server. In some cases, the IP that the Asterisk server will use to access the SafiServer is not the same IP to which the SafiServer is bound (eg NAT'd network configurations). In those cases, the provided IP will be used when an Asterisk->SafiServer communication is initiated by the SafiServer (eg. FastAGI call). This resolves some issues with the PlaceCall ActionStep.

4. Misc bug fixes.

One of our users, Dave (xad), caught a serious regression bug with the thread pool configuration. A patch is now available so next time you start the SafiWorkshop you should see an update notification. If you don't, please select help->update from the main menu. After updating you should see an entry in the "Pending Updates" table on the SafiServer View tab (assuming you're connected to a SafiServer). Click on the entry so it's selected and press "Push Selected Updates to Server". The SafiServer will need to restart following this update.

Previous to this patch, the thread pool on the SafiServer was defaulting to 10 threads, didn't correctly observe the settings in fastagi.properties, and wasn't creating more threads beyond the initial count even when all those threads were in use and the total count was below the configured maximum.

The global threadpool size now observes values in resources/fastagi.properties. Namely, 'maximumPoolSize' which determines the maximum allowed number of threads allowed to be active at any given time, and 'queueSize' ('poolSize' is also accepted but is deprecated and may be removed in a future release) which determines the size of the job queue which is where jobs will be queued until a thread becomes available. If no threads are available and the job queue is full, execution of the job will be rejected and an exception will be thrown.

Thanks to Dave for finding and reporting this serious issue.