IVR Systems are so expensive and proprietary.
The vendor systems I've used are all pretty weak... What is a good alternative to Genesys, Intervoice, etc.?
Asterisk is open source and it includes the capability of defining and running IVR interactions.
They have proprietary hardware for interaction with the PSTN or you can build services on top of VoiceOverIP protocols such as SIP (i.e. IP only).
See the Asterisk Gateway Interface wiki page - this describes the primitives you would use in the IVR script.
I use Asterisk for IVR implementations. I don't think the learning curve was too steep, especially considering I'm not really into telecoms, and it's worked pretty well for what I've used it. I currently have an IVR with 8 E1 links (240 channels) with Asterisk and a Sangoma card, works pretty well. And it's easy to test new features, since I can run it in my machine with just VoIP, setting up SIP in Asterisk and using the X-Lite softphone.
I connect Asterisk with my Java application using FastAGI and JAGIServer/OrderlyCalls on the Java side.
I would recommend Katalina 'VoiceGuide' - a windows-based CTI, IVR and dialler system at a reasonable price, supporting both tradtional POTS/ISDN telephony cards and VoIP. see: www.voiceguide.com
Related
I found this article:
www.codeproject.com/Articles/1077937/Possible-ways-to-organize-interaction-between-co,
and I know that there exist a code for the flash player.
Can I use only code for managing connections (as in the articles examples) and free flash player code and therefore get rid from integration software?
You need to be more specific but in reality the idea of the integration software is the following:
Session management
Multi-codec/format support
Interface Resource
Scheduling
Normally IP PBX supports SIP only, hence you need the transcoding between the SIP world (Audio + Video) and the Webcast world (Web browser/client/camera). Integration software as the one defined do a pretty good job and some of them are open Source (Wooza), If you want to replace them, I would do it with an MCU which support RMTP/Flash. Take a look at McuWeb project. Otherwise you need to write SIP Client code as well to integrate it with the SIP world
I'm looking to rebuild an existing VOIP app for android and iphone because it has poor call quality. I would like to replace my SIP library with the same one that Skype uses.
Does anyone know which SIP library Skype uses? Is it an open source one? Is it something proprietary that they built? Is it commercially available?
Skype has a proprietary signalling protocol and the code is not available. A lot of articles have been written about the subject. Here you have an example.
Skype performs the signalling over several ports and protocols and it can even send it encapsulated inside HTTP protocol so that it can still work on limited networks. I don't know what made you say that Skype uses SIP, but I don't think that it is used. I believe it is a small proprietary protocol and you can find some evidences for this in several articles where packets were analyzed.
Skype doesn't use SIP. Skype had other issues to deal with that SIP doesn't handle well. For example, SIP doesn't like NAT very much and several hacks must be used to get around it as best as one can. Skype, at least before the Microsoft era, used a proprietary protocol peer-to-peer (remember what Skype USED to make :-) ), and had the concept of Supernodes. Supernodes were other Skype nodes that had public IP addresses. Skype nodes would attempt to do a peer-to-peer call, but, in the event things like NAT and firewalls got in the way, they could relay their conversations from a Supernode. Again. who knows what they do now that Microsoft has been in the code. We know that Microsoft does inspect their messages.
What is the issue with SIP? If it's that NAT traversal issue - there are variants of protocols such as IAX where all traffic goes over a single stream, avoiding the SIP media problem.
I have a client company with a simple web application (Python Flask) and I need to add a phone notification functionality to it.
The main requirement is that the app should call users, play a certain sound file and accept some tone input ("Hello! This is an automated message from your WebApp account. You have a meeting with $John today at $5pm. Please press 1 to confirm").
The other requirement is that the solution should be relatively cheap and fast to market.
I have done some research already and it seems that there are a few consequent steps to achieve that:
Set up an Asterisk or a FreeSwitch server;
Set up a SIP account;
Write some business logic for the Asterisk server which allows to make calls and play sounds via a SIP account;
Write an API at the Asterisk server and expose it to the Python Flask web app.
Do I miss something here? Can any of the steps be omitted anyhow? Can I do it simpler?
the fastest way to get it working is to use one of the cloud voice services with speech synthesiser. Here's a short list to check out:
Twilio
Tropo
Plivo
Here I listed some details.
Those services charge you per minute, plus you may have to pay some monthly fee.
If you want to run an independent and standalone service, I would recommend FreeSWITCH instead of Asterisk. It's got reach integration possibilities and API. You will need to read the FreeSWITCH book in order to understand how it works and how to build your service.
I agree with Stanislav Sinyagin on the cloud based solutions, but I would add one more, Voxeo Prophecy. Tropo is from Voxeo, but they have offered Prophecy as a solution for a lot longer and it supports the open standards CCXML and VoiceXML. The advantage of CCXML for outbound notification applications is you have a lot more control of the notification process.
The Prophecy platform has excellent call progress analysis (CPA) which will allow you to determine whether a machine or a human answered and handle the call accordingly. For example, it does not make sense to ask a machine to "...press one to confirm". Instead you may want to leave a message that provides a call back number for the user to confirm with after they have listened to the voice message. The CPA can be used to leave a message on a machine at the correct time (when the greeting message has stopped) so that you do not get clipped messages in the voice mail. CPA will also allow you to provide detailed reports on who was notified and for those that did not it can tell you whether it was a bad number (received a SIT tone), a modem or fax answered, or ring-no-answer (pretty rare these days). These type of details can factor into your retry process for failed notifications.
The other advantage to using Prophecy and open standards is your application will be portable to other IVR systems that are VoiceXML/CCXML compatible if you ever want to migrate. Tropo, Twilio, and Plivo all use proprietary API's which does not allow you to move your applications to other services. Prophecy is also available as a software solution so that if you want to take it out of the cloud you can run it on premise. You can get a two port version for free to try it out.
There is excellent documentation on developing outbound notification systems on Voxeo's developer site. Take a look at the CCXML documentation in section F on Outbound Dialing.
Not sure which development languages you are familiar with, but if you are used to ASP.NET MVC there is an open source project called VoiceModel that makes it easier to develop VoiceXML applications. The other advantage of VoiceModel is that you develop your application once and it will run on any VoiceXML compatible platform and Tropo. They are currently working on adding outbound notification support in this project that will work for both Tropo and VoiceXML.
Third party solutions listed are your easy choice. Running your own asterisk is also suitable for what you want to do, but i think for only this much it would be overkill, from an operational perspective.
In asterisk, you can originate a call that has the 2 variables you need with an (basic-authenticated) HTTP request. You will also need some settings and a tiny dialplan. Setting up the SIP account is easier or more difficult, depending on the documentation from the provider. Most of them have detailed documentation for configuring asterisk (not so much so for freeswitch). Keeping the damn thing alive is what's gonna get to you :)
Is there a replacement technology for TAPI that supports third-party call control (3pcc)?
I want to provide the following 3pcc functionalities in an application:
Outgoing call:
User clicks at a button in the application.
The user's phone goes off hook, and the callee's phone rings.
The callee's phone shows the phone number of the callee, not the phone number used for the application.
When the callee picks up the phone, the connection is established.
Incoming call:
When user's phone rings, the caller's number and the called number are sent to the application.
The application evaluates the numbers and shows e.g. a customer record.
In the past, I would have done this with TAPI, but it seems that Microsoft does not actively develop TAPI any more (even though TAPI is supported with all current Windows versions, up to Windows 7). Therefore, I am searching for a technology that is more likely supported in the future by the majority of telephony system providers.
I am aware of CSTA, which could be used to do this, but this also is a pretty old technology and not very widespread (it has 100 times less Google hits than TAPI, for example).
I am also aware of SIP, which does not have direct support for 3pcc features, but there are ways to work around this:
For outgoing calls: use application's SIP endpoint to connect to the two phones first, then connect them by making a kind of "conference call".
For incoming calls: use SUBSCRIBE and NOTIFY and dialog event package.
Problem is that the procedure for outgoing calls is very clumsy, and the called phone would not display the correct phone number (i.e. the caller's number) when ringing.
Furthermore, SIP is not a single standard, but a collection of many different RFCs, and it seems that telephony system manufacturers only implement parts of those RFCs, and there usually is no good documentation which parts are implemented.
So, my question is: is there any other telephony integration standard that
supports third-party call control, and that can be considered as a widely supported standard in the foreseeable future?
I'd suggest you consider CSTA3.
ECMA CSTA3 is a comprehensive standard for 3rd party telephony call control far superior to TAPI in detail and implemented by several vendors. A web service definition exists for CSTA.
See ECMA CSTA 3
I can highly recommend the standard but would suggest you carefully consider if the target vendor supports the CSTA standard as you require.
The answer to the OP is yes. A couple years ago I was trying to do TAPI work and had all of the same issues as everyone else. Rather than using local hardware and drivers, I found cloud services which do everything requested in the OP. I won't mention a specific service unless someone PM's me. But my recommendation is to go off the standard path, and stop beating your head against the TAPI wall. HTH
stop beating your head against the TAPI wall
That would be nice. PM's are however not possible here TonyG. I would love hear about your cloud service experiences. Without getting specific, do you really mean call control over my desk phone is possible from the cloud?
Try Esna Ilink For Cisco Or Esna Ilink Pro. This product is Platform Independent and will work with any thing including TAPI and CSTA.
I've worked in business application development for a while but have never done socket programming. I know that all HTTP transport implicitly involves socket communication but this is all abstracted when using most software frameworks. So I was curious what types of apps developed today involve socket programming?
Any kind of proprietary communication protocol running over UDP or TCP would fit this description. We have a handful of applications that communicate with embedded systems using TCP and UDP, all using specialized protocols.
An application involving networking or network protocols could involve socket programming. This would mean UDP, TCP, peer-to-peer, etc.
Financial companies, especially ones in algorithmic trading area, rely on TCP/IP heavily.
That ranges from third party communication products like Tibco to FIX over TCP sockets to in-house frameworks over UDP/multicast.
Here's what I developped in my own spare time (took me 2 years actually) :
(1) program I called "big chief"
(2) program I called "the manager"
Here's how it works :
First launch the managers on every machine that is configured for that.
Once launched, the big chief asks for dlls to create a list of sites to "suck".
It cut them in "packets" and sends each packet to a "(2) manager"
Each manager has a pool of "workers" (threads). As soon as it gets the list, it activates each thread with one url to "suck". After some time, once all the list is done, the manager make a big "results" packet then send it back to the "big chief".
It can go far further than just "simply" suck urls. (You can define a whole "path" with get and posts, and the cookies follows the path, which means stuff like "going to xx.com, simulate valid button, then go to xx.com/valid.php (with all the cookies and so on set) then simulate something else.)
Yep, it's a mini-google.
I used TCP for "big chief" and "manager" communication with my own protocol and compression before sending.
One of its powerful feature is that you can extend it very easyli. I've used my PC for the "big chief" and 6 other Internet connexions for the managers (including a huge one from my old school). I am able to add as many "managers" as I want :).
PS : Why am I talking about that ? Because I'm proud of it and it's not used at all. It's on my computer, I've sucked a site that is hard to ... suck (pbase.com) and they've probably seen incoming connexions from the States, China, and so on (whereas I'm in France) (yep it does do support public proxies as well)... I'm so proud of a product that is not used at all...