I have an VOIP application i'd like to implement, that requires me to process the audio from a call in real time during the call.
Currently, I'm using Asterisk to handle my calls, and it looks like there's a functionality built in called Audiohooks which is designed to let me access the audiostream, and process it from the dialplay
However, I can not find any documentation whatsoever on how to actually create my own audio hook, nor any recent examples on how it should be done. Are there resources that show how I could use this?
Thanks
That api is availible when you do c/c++ modules for asterisk. No external API.
For examples you can check MixMonitor,func_volume,app_conference and other similar application already developed.
Hint: after work done, you have test for memory leaks and hi-load/concurrent load. Code must be thread-safe.
Related
I know that Corda is in the process of removing its web server module and in the documentation they suggest the use of other frameworks.
In one example ("spring-observable-stream") they use Spring Boot for the server-side APIs and use an RPC call to the actual running Corda node. That's fine and comparable with what I have to do.
In that example, the author import the specific Corda's RPC code, along with the code of the actual flow (and states) needed.
What I want to ask here is if it's possible to avoid that tangle and keep the web server APIs independent from the actual Corda/CordApp's code by using a general RPC library (any advice ?).
If, instead, I must import the Corda-specific code (there is a reason ?), I'd like to ask you:
What is the minimum necessary to do so from a Gradle perspective ?
Is it possible to implement some sort of plugin on the CordApp to reduce that tangle ?
To be honest, I'm interested in a more general way for interacting with the CordApp (e.g. from Python), but I know that due to the AMQP integration not yet ready, we have to stay on the JVM for now. So, feel free to answer just about what we need to do as of today from Kotlin (which I have to use for a short-term PoC)…
Thank you in advance!
Currently, your server has to depend on the Corda RPC library to interact with nodes via RPC. Corda doesn't yet expose an independent format for sending and receiving messages via RPC.
Your server also needs to depend on any CorDapps that contain flows that the server will start via RPC, or that contain types that will be returned via RPC. Otherwise, your server will not be able to start the flows or deserialise the returned types.
If you're using Gradle, here's what a minimal dependencies block might look like:
dependencies {
compile "org.jetbrains.kotlin:kotlin-stdlib-jre8:$kotlin_version"
cordaCompile "net.corda:corda-rpc:$corda_release_version"
compile "com.github.corda:cordapp-example:release-V1-SNAPSHOT"
}
Here, we're depending on the corda-rpc library, and also using JitPack to depend on the CorDapp where we define the flows and states that we want to start/return via RPC.
If you want, you can modularise the CorDapp so that all the classes you need to depend on for RPC are included in a separate module, and only depend on that module.
This is software design question more than a coding one.
I am about to implement a feature where I can verify user's emails and phone numbers using Twilio's sms and voice apis.
My current implementation instantiates a Voice client at start up of the app and then I reuse this client whenever any user decides to verify email or voice.
Question: Is it a good idea to instantiate Twilio client once and then re-use it each time or should I create a new one each time it is needed?
I have browsed the Net for articles but haven't found something conclusive. Hoping to clarify here.
You are looking at whether the twillo client is thread-safe. A quick google search found this: Twilio Threaded Messages. I have not looked at the source myself, but I would consider this a likely answer that yes, it is thread-safe.
I'm not familiar with Twilio. But usually, since 3rd party API is out of our control, its stability, performance, etc, are all questions, and potentially, you might want to change to another service provider. So, firstly, try your best to decouple your own logic from 3rd ones. For instance, design an interface for this logic, and one implementation for Twilio.
Secondly, you need to test the Twilio client instance, ensure it could keep working for long time after instantiated, and if your programming language or runtime work in multi-thread way, you need to also test to make sure the instance could work properly when it is shared by multi-threads (if not, the instance is not threadsafe, you might consider using some mutex style locking on it).
Furthermore, if the 3rd party services execution is not stable, or, takes time for execution, etc, and specifically, for your email/sms verification case, it is not necessary to call the services synchronously and wait for responses. You could consider to use a worker queue, putting all tasks to the queue, and create some workers, running in asynchronous threads, to get tasks from queue and execute.
I want to make a program (more precisely, a service) that periodically scans directories to find some video files (.avi, .mkv, etc) and automatically download some associated files (mostly subtitles) from one or several websites.
This program could run on linux or windows as well.
On one hand, I know well Qt from a long time and I know all its benefits, but on the other hand, I'm attracted by node.js and it extreme flexibility and liveliness.
I need to offer some interactivity with the end user of my program (for instance, chose the scans directories, etc).
What would be the best choice in your opinion in 2013?
I advise against Node.js for "small tools and programs". Especially for iterative tasks.
The long story
The reason is quite simply the way Node.js works. Its asynchronous model makes simple tasks unnecessarily convoluted. Additionally, because many callbacks are called from the Node.js event loop, you can't just use try/catch structures so every tiny error will crash your whole Application.
Of course there are ways to catch those errors or work with them, but the docs advise you against all of them and advise you to restart the application gracefully in any case to prevent memory leaks. This means you have to implement yet another piece of code.
The only real solution in Node.js would be writing your Application as a Cluster, which is a great concept but of course would require you to use some kind of IPC to get your data back to a process that can handle it.
Also, since you wrote about "periodically scan"ning a directory, I want to point out that you should...
Use file system watchers for services
Almost every language kit has those now and I strongly suggest using those and only use a fallback full-scan.
In Qt there is a system-independent class QFileSystemWatcher that provides a handy callback whenever specified files are changed
In Java there is the java.nio.file.FileSystem.getWatchService()
Node.js has the fs.watch function, if you really want to go for it
I have a telephony scenario in which the following happens:
Customer calls a Voice Gateway
TCL script runs and a code is taken from customer
Authentication is done through a RADIUS server
Customer will hear correct voice menu
The problem is that RADIUS server must connect to a SQL Database and check the credentials. I have currently designed the solution using cisco secure ACS and through managed stored procedures on MS SQL server.
My question is: Is the VoiceXML a better tool to do this job and because some extenstions and wrappers of VoiceXML exists in .net, does it fit in this simple scenario??
Sincerely speaking, I am a little confisued with the technology and looking for a good tutorial on its features as well.
Thanks
In a strict sense, only step 4 is implemented by VoiceXML. Other aspects are handled by the platform or external code. VoiceXML is the standards mechanism for implementing step 4, but if all you are going to do is limited audio output and simple input, it may be overkill depending on the solutions available to you.
The following is just an example of a way to solve your problem and is fairly fictitious given I don't know anything about your environment nor constraints.
Given most VoiceXML platforms, upon receiving of a call your VoiceXML application will be executed. If this is a servlet/ASP based solution, you can perform steps 2 & 3 then generate/return the VoiceXML to play the menu, gather the input and move to the next step. If this is a static VoiceXML 2.1 solution, you can use a Data element call to make an HTTP request to a system that can perform these actions. The system will need to return XML that the Javascript/ECMAScript in VoiceXML application can parse and provide the correct audio output and input processing.
Since you are asking about VoiceXML, I'm assuming your challenge is the telephony aspect of the problem. Unless you have a system already available, choosing and activating a premise or hosted solution is far more complicated than the call flow code involved. Depending on your requirements, there are solutions as low as a single line, analog modem that supports audio output and DTMF input to massively scaled on premise and hosted solutions to handle 10,000s of concurrent calls that implement VoiceXML as well as a wide range of other call flow technologies.
VoiceXML would work fine in this scenario. There is a an open source project called VoiceModel that uses ASP.NET MVC to generate the VoiceXML and therefore integrates nicely with the .NET stack. There are a lot of examples in the project with discussions on how to use the examples in this blog. The examples use Voxeo Prophecy as the VoiceXML platform which has a SIP interface that will connect with a Voice Gateway. You can download two ports for free to try it out.
I'm writing a .NET 4.0 library that should be efficient and simple to use.
The library is used by referencing it and using its different classes.
Should I use .NET 4.0 Tasks tot make things more efficient internally? I fear that it might make the usage of the library more complex and limited since the users might want to decide for themselves when and where to use tasks and threads.
If your answer depends on the kind of library, here is more information:
The library is Pcap.Net, which is a wrapper for WinPcap and includes a packet interpretation framework.
It only is an issue when the user can 'see' the threading, ie you give out access to data that could be accessed (by you) on another Thread. Probably not a good idea.
But when the parallel processing stays completely inside your application then there is very little chance your users would object.
Should? Dunno. How about giving people an option by providing extension methods that use tasks against the library and push that out in a separate DLL? If you want to use tasks, reference the extension library and go crazy. Otherwise, stick with the core dll.
I believe there are many projects that follow this pattern with Linq. They provide their core library and a separate .Linq.DLL which has extension methods...