vicidial.org

Hi I am just wondering when vicidial will be made to be compatible with 1.8. I have seen an old bounty thread where the it looked like you had enough bounty $2500 but no guide or news on asterisk 1.8

If any news of asterisk 1.8 please reply to this.

Thanks[/url]

We have it scheduled for next year. It is on our priority list, and we have worked with a couple of outside users that have contributed some code to get us there when we have the time to work on it.

That's great news Matt. I would like to be part of that team if possible because we have it at the point now that vicidial works with 1.8 but not in vm environment like VMware which vicidial at the moment does. It's the zaptel / meetme side of things is where we r stuck so would love to share n contribute to getting this working.

We have also developed some new bits of code and features you might like to incorporate into your next build.

Cheers

We have actually used the instructions for Voxilla to get meetme (dahdi version, not zaptel) up and running in EC2. On an 8 processor system, no less.

We had a client who was using Voxilla's EBS, but that did not come in an 8 processor flavor, so we duped it (with Voxilla's instructions!)

Regarding to asterisk 1.8, when u say next year, do u mean 2012 or 2013?

Thanks for you in advance.
Regards
Bilal

As he said it in December of 2011, I would jump to the conclusion that he meant 2012. As a rule.

I have actually begun adding Asterisk 1.8 support. It is in a very alpha stage right now. Currently this is a low priority item that I am working on in my spare time, so do not expect it to be in beta any time soon.

So far I have only tested outbound dialing and agent login, but they do appear to be working in my test bed environment. I actually let it run in performance test mode with a few remote agents over night and was actually quite surprise that Asterisk did not crash. There are a few troubling ERROR and WARNING messages popping up in the CLI. Some of these might be related to the test bed and not the actual system. One though is quite troubling as it could potentially fill a heavy outbound dialer's a hard drive with WARNING messages in the logs in just a few hours. I do not expect Asterisk 1.8 will be recommended for production use anytime soon. I guess this is to be expected. Asterisk 1.4 was not really stable till 1.4.18.

Sadly one of the big features that I was looking forward to in Asterisk 1.8 does not work the way I was hoping it would. They added an AMI command called "LocalOptimizeAway" which I was hoping would allow us to force Asterisk to optimize a Local channel out of the way in the call_log processes. This would make the RINGALL agi script work much better. Unfortunately all this does is clear the LOCAL_NO_OPTIMIZATION flag which prevents optimization. It does not actually do the optimization. That is only done during audio processing. If we have not gotten any audio from the SIP peer by the time the call reaches the routing script, the Local channel will not optimize away and we cannot route it. I am debating writing a patch to attempt at optimization when this manager event is called, but that will have to wait for 1.8 to be fully supported.

Isnt it about time we had vicidial on asterisk 1.8 now??
Asterisk is running at 1.8.13 and so has been well established now and bugs should be ironed out.

Vicidial still uses asterisk 1.4 which is now EOL and that seems crazy!

We are working on Asterisk 1.8 support and hope to have it finished soon, but it is unpaid development work so our paid development work takes priority. If you think it will be ready for production use once we are finish, you are deluding yourself. Asterisk 1.4 had support added for it till about 1.4.12. It was not until asterisk 1.4.18 that it was ready for production use, and not until asterisk 1.4.21.2 that we started recommending it for production. This was well after asterisk 1.2 had moved into security fix only mode.

The current state of things is this. I have 95 percent of the back end processes patch on my test bed system to support asterisk 1.8. I have been able to run asterisk 1.8 for a few days under heavy load without it crashing. Currently waiting for Matt to finish up with a paid development project so that he can assist me with some of the agent interface side development. Once that is in place we have to test EVERY feature in Vicidial to make sure it is working properly. We also have to work around or fix any bugs in Asterisk we discover. Once all of that is in place we will look for people in the community to beta test it. Once we are satisfied that it is working properly we will merge support into the main line code and it will be available in SVN.

Speaking of Asterisk bugs, I am currently working to try and fix a bug in Asterisk 1.8 that could fill the hard drive of a production system in a single day with WARNING messages. This bug is effecting call recording and a few other features. When it pops up Asterisk generates a WARNING for every single audio packet it processes in a channel. Each audio packet is 40ms. So for a two way conversation that is 50 messages per second per effected channel. As mentioned this effect audio recording. So if you have 25 agents logged into a server with full call recording on, you could get up to 1250 of these messages per second. I have found a work around in Vicidial that basically passes the recording path through the loopback, but this is not the ideal solution. Among other things if ip_relay fails for whatever reason all call recordings will stop, and you probably will not notice until you go looking for one. This work around will probably be in place for the initial asterisk 1.8 support as it will probably take a while for Digium to fix it.

Ultimately, if you would like Asterisk 1.8 support sooner, please consider donating to the bounty that is floating around the forums. The more funds that are available the higher a priority the development becomes with relation to our paid development. I do not have the link to the bounty at the moment, but it is out there.

I am sorry. Matt corrected me. We added support for asterisk 1.4 earlier than 1.4.12. He does not remember the exact version though.

i'll consider paying for it if i knew how much? any links to the page that has a bounty on it?

Het guys!

Any update?

I believe we are trying to get Digium to help fix a bug related to recording in 1.8. We are still working on it, but progress is slow.

If there is anything I can do to help..... let me know.

It looks like Digium has narrowed down the problem and will have a fix here soon. After that all that should be left is getting the agent interface to properly stop the recordings when told to (probably will need Matt's help with that). Once that is done we got to do some internal testing to make sure it does not break Asterisk 1.4.

i can help test or code the agent side if some direction is given

Actually just finished the agent side. Digium in their infinite wisdom switched the comma at the end of a Local channel to a semicolon. This prevented the hang up code from ending the Monitor on the MeetMe sessions. It was very hard to spot so I spent quite a bit of time pulling my hair out. It was a simple fix though to a single SQL query.

We are now doing internal testing to make sure everything looks good in a controlled environment for both asterisk 1.8 and asterisk 1.4. Once that is done I got to prepare a asterisk-1.8.*-vici version with all of the patches needed to get it stable.

Sorry to be so 'pushy' but..., is there any update on this?
Thanks!

started testing a couple weeks ago, we have found a few things that needed to be fixed already. We are progressing slowly, when we have available time, but we are getting closer to a release of this.

Awesome!! Cant wait. I need to re-build my cluster and I want to start off with the new 1.8 asterisk. I've been delaying my migration to get there.....
Great job guys! This is an awesome application that works wonders!!!! From me to you; THANK YOU! You're doing an awesome, awesome job.

Okay so in the final stages of adding Asterisk 1.8 support. Here is the version of Asterisk 1.8 that we are using:

http://download.vicidial.com/beta-apps/ ... eta.tar.gz

It is beta because it has not been tested on a production system, and it does not have Sangoma CPA support yet.

In my testing DAHDI is still a requirement to use this with Vicidial. Even though the pthread timing interface does work, it causes massive numbers of ERRORs to stream to the CLI under even slight load, and other weird issues.

I have to wait for Matt to finish committing another major development project, update my test systems to include his code, test some things, and then put the patch set together for Matt to commit. I hope to have that done within the week.

For all those looking to use this, while I am happy for your enthusiasm, this code has not been tested in a production environment. You will be a guinea pig if you decide to do so. Above all before reporting any issues with Asterisk 1.8 be sure to confirm that the issue cannot be replicated on Asterisk 1.4. Also be sure that you are using the DAHDI for timing. Pthread timing causes too many problems.

We're going to build a test server and try to get 60+ people on it placing 500+ calls. In theory we could just use a standalone all in one vicibox 4.x version correct? Never done something like this.

So I ran into a few snags with Call Menu generation which were fairly easy to fix, but testing was a mess. We are in the final stages of merging the code into SVN and should have it ready shortly.

@KeithHBW - While there should be some performance enhancements from switching from 1.4 to 1.8 (wont know till we see real word data), I do not think they will be substantial enough to handle what you are trying to do. Probably closer to five and ten percent (if that). We still recommend 25 users per server with a maximum outbound channel count per server of 150. Above that and you will probably have issues. If you need more than that, build a cluster.

As for building a test system with Vicibox, we will put out a document explaining how to install 1.8 on the latest Vicibox once the code is committed.

The changes to Vicidial have just been committed for Asterisk 1.8 support. This is in the BETA testing phase currently, and is not recommended for use in production at this time. While we have performed a lot of testing, we have not tested this in production, so you have been warned.

If you choose to upgrade an existing system, please make note of the many conf file changes(extensions.conf and manager.conf) that will need to be made for Vicidial to function properly while interfacing with Asterisk 1.8. Also, make sure that the Admin -> Servers -> modify server "Asterisk Version" setting is set properly for the version you have installed on that server.

To download a version of Asterisk 1.8 that we are working from, go to:
http://downloads.vicidial.com/beta-apps/

To download the Vicidial code changes, just upgrade or download the latest svn/trunk snapshot.

When approximately do you expect it to be ready for production?

As far as we have tested, it is ready to try in production. Give it a try and let us know how it works for you.

@mflorell


Any special procedure needed to install and integrate with Vicidial also when used this for upgrading existing Vicidial system with 1.4 version on it.Thanks

If upgrading on the same system you need to:
- make sure you are using a svn/trunk vicidial version from the last week
- set the Servers -> Asterisk version to 1.8.19
- either choose to install the sample config files or go through and compare the docs/conf_examples that are marked with a "1.8" and compare with your existing conf files

@mflorell

i tired testing install of asterisk-1.8.19.0-vici-beta problem encounter during installation are this:

Code: Select all

config.status: creating Makefile
./config.status: line 970: gawk: command not found
config.status: error: could not create Makefile
make[2]: *** [config.h] Error 127
make[2]: Leaving directory `/usr/src/asterisk/asterisk-1.8.19.0-vici-beta/menuselect/mxml'
make[1]: *** [mxml/libmxml.a] Error 2
make[1]: Leaving directory `/usr/src/asterisk/asterisk-1.8.19.0-vici-beta/menuselect'
make: *** [menuselect/menuselect] Error 2


Basically from there i can proceed anymore with the install - any idea somehow.Thanks

i have somehow overcome the 1st error now trapped on this install ERROR:

Code: Select all

ranlib libmxml.a
make[2]: Leaving directory `/usr/src/asterisk/asterisk-1.8.19.0-vici-beta/menuselect/mxml'
gcc  -o menuselect menuselect.o strcompat.o menuselect_stub.o mxml/libmxml.a
make[1]: Leaving directory `/usr/src/asterisk/asterisk-1.8.19.0-vici-beta/menuselect'
Generating input for menuselect ...
menuselect/menuselect --check-deps menuselect.makeopts

***********************************************************
  The existing menuselect.makeopts file did not specify
  that 'res_config_ldap' should not be included.  However, either some
  dependencies for this module were not found or a
  conflict exists.

  Either run 'make menuselect' or remove the existing
  menuselect.makeopts file to resolve this issue.
***********************************************************

make: *** [menuselect.makeopts] Error 255


This happen after i do make command.

have you already run the menuselect process where you select the asterisk modules you want to be installed?

@ mflorell


It works now already just some dependency for the ldap and the installation went well now.Testing for production and update you on result.Thanks

hi update on my asterisk 1.8 with latest svn trunk

Version: 2.6b0.5
SVN Version: 0
DB Schema Version: 1339
DB Schema Update Date: 2013-02-05 01:32:13
Auto User-add Value: 101
Install Date: 2013-02-05
asterisk-1.8.19.0-vici-beta.tar.gz

So far when i test it on Predictive Dialing working well but when i used Manual Dialing by Clicking manual at the bottom the Live call indicator does not turn green even calls are connected already and the transfer-conf, quick transfer are all grayed out cannot be click i can transfer when i do manual dial click but i can transfer when at ratio which are trasnfer-conf button are click able...any idea on this

Post a CLI output from a fresh attempted Manual Dial.

Ok guys update, issue solve, during setup on the asterisk version it appears 1.4 i change it with 1.8.19 to be exact and make rebuild conf..and all things work accordingly..running smooth so far. Thanks

Excellent PostBack

But guys, i see one disadvantage when i have done Asterisk 1.8 the logs on the asterisk console don't have any color distinction instead its all WHITE pretty hard to identify like before, any work around on this issue, its really hard to see logs with no color variation like the default asterisk, pink, yellow and white, NOT WHITE only.Thanks

asterisk.conf [options] section

nocolor yes Suppresses color output from the Asterisk console. This is useful when saving console output to a file. This option is set to no by default.

Why are you using the asterisk logs? The /var/log/astguiclient/screenlog.0 file is the complete asterisk output from the original asterisk process. It will have output the asterisk logs don't. You may have to open it with less -r to read it properly, but it will have the full color coding and everything.

he's talking about the console output. apparently color is turned off. i'm not sure what triggers that, but the reference I found I posted. i also don't know if the console output color is linked directly to log file output color or not.