Moderators: gerski, enjay, williamconley, Op3r, Staydog, gardo, mflorell, MJCoate, mcargile, Kumba, Michael_N
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.
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
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
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.
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.
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.
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.
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.
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.
Users browsing this forum: No registered users and 78 guests