vicidial.org

Can anyone give me a guide on installing opus on asterisk 13 on vicibox 8.

I have tried numerous links but none are working.

Does anyone have a working example?

You will need to recompile Asterisk with the opus option enabled in make menuselect, so you'll have to install a bunch of utilities in OpenSuSE to do code compiling, and you'll have to install the base Opus stuff. I have done it before to see if I could do it, but I did not document the steps.

Isn't it possible to precompile opus? It is better for webrtc, especially remote agents.


Also, if I recompile Asterisk, where can I get a source that is compatible with vicibox 8

hello all,

You will need to recompile Asterisk with the opus option enabled in make menuselect, so you'll have to install a bunch of utilities in OpenSuSE to do code compiling, and you'll have to install the base Opus stuff. I have done it before to see if I could do it, but I did not document the steps.

I sympathize Yoda Florell ! started to "note" the steps but got bored falled back into kernel sources compiling + dev tools + utilities etc .. before compiling the dahdi

vkad wrote:Isn't it possible to precompile opus? It is better for webrtc, especially remote agents.
Also, if I recompile Asterisk, where can I get a source that is compatible with vicibox 8

SO same here for opus and vp8 ... i will post the .so when done xwith install assuming it's under asterisk-13.21.0-vici / vicibox8
but only Pbxwebphone working on my side, viciphone just register and can make call but can't be reached to join the meetme room ..
ps: source compiling turning since 40 min .. holy smoke ...

I actually just compiled Asterisk 13.21.0 today during our last day of VICIdial Training here in Florida, with Opus/SRTP/etc... before I posted the new tarball to the download site.
Here was the final configure string I used:

./configure --with-dahdi=/usr/src/asterisk/dahdi-linux-complete-2.11.1+2.11.1/ --with-gsm=internal --with-opus=/usr/lib64/ --with-speex=/usr/lib64/ --with-srtp=/usr/lib64/ --with-ogg=/usr/lib64/ --with-ssl --enable-asteriskssl --with-pjproject-bundled

I did this install on VICIbox, and there were a lot of packages I had to install through "yast" before all of the configure options would work properly. For example, you have to install "xmlstarlet" to get the "opus" codec to become selectable in "make menuselect".

http://vicidial.org/docs/ASTERISK_13.txt
http://download.vicidial.com/beta-apps/ ... ici.tar.gz

mflorell wrote:I actually just compiled Asterisk 13.21.0 today during our last day of VICIdial Training here in Florida, with Opus/SRTP/etc... before I posted the new tarball to the download site.
Here was the final configure string I used:

./configure --with-dahdi=/usr/src/asterisk/dahdi-linux-complete-2.11.1+2.11.1/ --with-gsm=internal --with-opus=/usr/lib64/ --with-speex=/usr/lib64/ --with-srtp=/usr/lib64/ --with-ogg=/usr/lib64/ --with-ssl --enable-asteriskssl --with-pjproject-bundled

I did this install on VICIbox, and there were a lot of packages I had to install through "yast" before all of the configure options would work properly. For example, you have to install "xmlstarlet" to get the "opus" codec to become selectable in "make menuselect".

http://vicidial.org/docs/ASTERISK_13.txt
http://download.vicidial.com/beta-apps/ ... ici.tar.gz

opensuse leap kernel sources not installed by default (requested by dahdi to compile) + as you said devlibs (logic vicibox is optimised for production)
and of course xmlstarlet is needed
i have 1 week-end per month sandboxing with vicibox.
during this sleepless night (gmt + 1 here) .. exploring the possibity to add a WEBRTC GATEWَََAY embedded with the WEB VICIBOX SIDE.
this may give the ability to avoid (webrtc leaks acting as a gateway with asterisk)
in this sandboxing i will use the janus gateway
check the link: https://github.com/meetecho/janus-gateway you "may like the concept"

have a good day/night Yoda !

Just as a side note, we are planning on releasing the next version of VICIbox soon, which will have Asterisk 13, Opus and WebRTC installed by default, as well as options to use the VOIP blacklist and some other security options.

mflorell wrote:Just as a side note, we are planning on releasing the next version of VICIbox soon, which will have Asterisk 13, Opus and WebRTC installed by default, as well as options to use the VOIP blacklist and some other security options.

good news yoda,
if there is beta testing release, i will enjoy sandboxing it !
actually webrtc with vicibox working perfectly (tested standalone vicibox running 30 remote agents webrtc 10/10 )
Best regards.
PS: why not asterisk 15 ?
a read me around upgrade to asterisk 15
https://github.com/asterisk/asterisk/bl ... ADE-13.txt

Asterisk has continued to embrace the technologies offered by the WebRTC movement. Asterisk 15 now supports RTCP Multiplexing and BUNDLE, both of which more easily allow connections to traverse NAT routers and firewalls, and to reduce call setup times. To better facilitate SDP negotiation with WebRTC capable endpoints, Asterisk 15 also supports Unified Plan.
In supporting Unified Plan, Asterisk’s underlying bridging core has been improved to support multiple media streams per connection. This is important, because Asterisk’s long-used audio conferencing application, Confbridge, has been extended to handle these streams; in particular, video streams. Now, utilizing Confbridge, a user may connect a number of WebRTC capable endpoints, such as the Cyber Mega Phone 2000 demo client, and have an impressively-easy to set-up multi-party video conference.

We do not support any of the short-term Asterisk releases, and Asterisk 14 & 15 are both short term releases. We have found them in the past to be less stable and the Asterisk community devotes much less resources to those branches because they go end-of-life after only one year, unlike the Long-Term-Support branches that are supported for about 5 years. Asterisk 13 is currently the only supported LTS branch of Asterisk. Supposedly, Asterisk 16 will also be an LTS branch.

perefctly right .. short term release can't be reference , but they will be a base for next LTS release !
running webrtc with ulaw ok let's see if what could opus give better ..

I installed the asterisk-13.21.0-vici (from source) with opus and all stuff (ofc rebooted)
opus is working but i felt a 1-2 sec latency on loggin in
i hear the conf-onlyperson.gsm after 2 sec after loggin in (ulaw or opus)
the precompiled asterisk13.19 vici is plays the conf-onlyperson.gsm simultaneously with all codecs no latency
same conf files on both sides ..
using 2 sandboxes same config vicibox 8 (4 cores - 8 Gb ram)..

I tried compiling and its working fine...Now I am thinking, I should have just waited for you to release the new Vicibox, but a lot of thanks Any date on the new vicibox yet?


I was just wondering, why don't you use a php framework? It would make the php files a lot cleaner and easier to read.
Also, what about a php templating engine (smarty maybe)?

No ETA on the next VICIbox yet, we're hoping for the end of June.

As for PHP templating engines or frameworks, I've looked at several of them and don't like any of them, that's about the simplest answer I can give you. Also, at this point it would take a massive amount of time to rewrite and test everything to work with a framework, and nobody is going to pay us to do that.

mflorell wrote:No ETA on the next VICIbox yet, we're hoping for the end of June.

As for PHP templating engines or frameworks, I've looked at several of them and don't like any of them, that's about the simplest answer I can give you. Also, at this point it would take a massive amount of time to rewrite and test everything to work with a framework, and nobody is going to pay us to do that.

wrote a lot and deleted. in two words:
respects matt

mflorell wrote:No ETA on the next VICIbox yet, we're hoping for the end of June.

As for PHP templating engines or frameworks, I've looked at several of them and don't like any of them, that's about the simplest answer I can give you. Also, at this point it would take a massive amount of time to rewrite and test everything to work with a framework, and nobody is going to pay us to do that.

If I was to give you a PHP developer (based in India) + web developer from my team for free for 6 months. To us, the cost is around $700-$900 a developer a month, but I would like to give something in return for all your help and we will cover the PHP developer and the web developer. There may be little communication gaps but he should be able to understand written English well enough. I will be here to bridge the gaps.

We can use larval or use MVC structure. Make it look pretty and keep it functional. Separate the Model + Controller + Views + Templating
I think rewriting shouldn't take longer than 90 days of work with our own framework with your support.

We can make something that looks and feels easier to use.
Also, we will like to upgrade the database structure in the process to make it more efficient and self-governing.

Other things we would like to implement is S3 compatible storage for recordings. Also, we would like to focus on creating a platform more focused on webRTC. For example, an option of automatically creating webphones when users are created, sort of thing.

Let me know if you are interested.

None of my experiences with outside PHP developers have been good, and after rewriting everything in a new framework language, you would still have to test every feature to ensure everything still works. The testing alone would take hundreds of hours. I have attempted to do this before, more than once, and every time it has ended up being a huge waste of my time with nothing to show for it. As an example, one rewrite of the VICIdial admin and agent screens from two years ago that I have seen the code for, is full of bugs and many features don't work at all in the new interfaces.

As for "upgrade the database structure", what exactly did you have in mind?

As for S3 storage, recording archival is already a separate configurable process, so that shouldn't be too difficult to implement as long as S3 storage allows for standard transmission options.

As for WebRTC, we are moving more in that direction already. After the next VICIbox release, we will be able to focus more resources on more WebRTC-centric features.

mflorell wrote:None of my experiences with outside PHP developers have been good, and after rewriting everything in a new framework language, you would still have to test every feature to ensure everything still works. The testing alone would take hundreds of hours. I have attempted to do this before, more than once, and every time it has ended up being a huge waste of my time with nothing to show for it. As an example, one rewrite of the VICIdial admin and agent screens from two years ago that I have seen the code for, is full of bugs and many features don't work at all in the new interfaces.

As for "upgrade the database structure", what exactly did you have in mind?

As for S3 storage, recording archival is already a separate configurable process, so that shouldn't be too difficult to implement as long as S3 storage allows for standard transmission options.

As for WebRTC, we are moving more in that direction already. After the next VICIbox release, we will be able to focus more resources on more WebRTC-centric features.

The developers we have have atleast 5 years of experience. They won't be the smartest or the brightest of developers, but they follow standard practices and paradigms, so that the project can be picked up by anyone. The framework is designed to be easy to use and easy to implement.

If you think laravel or code igniter is easy, then you will find our framework much easier to use. We don't have fancy bells and whistles. The framework is developed by computer scientists and engineers in our company in the USA and UK so that it is easier to develop software for programmers who don't code well...

If you can send us the copy of rewrite of the vicidial admin/agent screens, we can have that looked at.

In terms of testing, we have automated testing in our framework and they way we deal with the framework is such that there is a presentation part (html templating, etc) and there is a core php part.
Presentation will talk to the core through APIs and no more than that.
The process for any object is as follows: Data is received -> Data is validated -> Data os

So the database can be cleaned up a little bit and a bit more nomalisation of data...
Also, certain parts of the database can be moved to innodb. Also maybe use transactions.

Having an option to setup storage from the web gui will be great. Also an option to clean, migrate, directories.

Also, having a better file manager for audio files, Along with an option to convert files to asterisk compatible format from within the interface...A user may upload an mp3 and it will be converted to asterisk wav or gsm automatically.


The MOST important thing we need to know is how php interacts with the rest of the system...Other parts of the system is mainly forms and data management.

For example, it will be relatively easy to setup a campaigns management system in PHP/MySQL.
The hardest part I believe is going to be the agent screen. But we will see how we can approach this once we have a deeper know how of the PHPs interaction with other parts of the systems.

As for your framework, we will not be standardizing the VICIdial project on some unnamed company's home-grown framework product, that just isn't going to happen. What is the name of your company? Is this framework open-source?

As for testing, automated testing misses a large number of the problems that I've seen in large code migration projects on complex codebases like VICIdial. You have to have humans test functionality or you are going to miss things, and with thousands of features, that interact in all sorts of ways, human testing for a complete rewrite of the code would take hundreds of hours.

Could you please explain in more detail what "the database can be cleaned up a little bit and a bit more nomalisation of data" means?

Also, what database tables do you think would work as InnoDB?

As for converting audio files, the problem with that is dealing with the different versions of SoX, and the fact that they change what some of the command flags mean even within sub-versions of SoX. We tried to build an automatic audio converter years ago, but it didn't work consistently and had problems if installed with the wrong versions of SoX.

We have quoted adding web-configurable audio recording archiving before, it's a pretty complex project given the changes that would need to be made at the dialer level for all of the existing options there are now.

As for PHP, except for the audio store, it only ever interacts with the database, all of the perl scripts on the Asterisk side interacts only with the database, none of the PHP code interacts with Asterisk, ever.

The agent screen uses PHP to generate very complex dynamic javascript code depending on user, user-group and campaign settings, which is never easy to convert to frameworks due to the complexity and the load of all of the different AJAX calls being pushed out. Yes, the basic function if the agent screen is just forms, but there is A LOT more to it than that, and the complex interaction of how all of the thousands of features interact together is what makes switching the agent screen to a framework so difficult.

mflorell wrote:As for your framework, we will not be standardizing the VICIdial project on some unnamed company's home-grown framework product, that just isn't going to happen. What is the name of your company? Is this framework open-source?

As for testing, automated testing misses a large number of the problems that I've seen in large code migration projects on complex codebases like VICIdial. You have to have humans test functionality or you are going to miss things, and with thousands of features, that interact in all sorts of ways, human testing for a complete rewrite of the code would take hundreds of hours.

Could you please explain in more detail what "the database can be cleaned up a little bit and a bit more nomalisation of data" means?

Also, what database tables do you think would work as InnoDB?

As for converting audio files, the problem with that is dealing with the different versions of SoX, and the fact that they change what some of the command flags mean even within sub-versions of SoX. We tried to build an automatic audio converter years ago, but it didn't work consistently and had problems if installed with the wrong versions of SoX.

We have quoted adding web-configurable audio recording archiving before, it's a pretty complex project given the changes that would need to be made at the dialer level for all of the existing options there are now.

As for PHP, except for the audio store, it only ever interacts with the database, all of the perl scripts on the Asterisk side interacts only with the database, none of the PHP code interacts with Asterisk, ever.

The agent screen uses PHP to generate very complex dynamic javascript code depending on user, user-group and campaign settings, which is never easy to convert to frameworks due to the complexity and the load of all of the different AJAX calls being pushed out. Yes, the basic function if the agent screen is just forms, but there is A LOT more to it than that, and the complex interaction of how all of the thousands of features interact together is what makes switching the agent screen to a framework so difficult.

Spark London and we are main vendor for (Universities in London for software), and the framework is not opensource "yet", but it will be. Human testing can also be arranged, free of cost. Testing is cheap in India because of sheer amount of people in testing.

We essentially want to separate the logic from the views...For us its not very hard as that is how we do things...

First of all we will separate the login part from the agent logged in screen. We will break down the html and js into templates.
The DBA looked at some queries and recommended quite a few changes. I can ask him to write them down for next time.