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.
Related
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'm listening to WWDC2012 Session 707 on Bounjour. At 15:25 into the session, the apple engineer explains that you need to register your bonjour service name with IANA before publishing. I found that the link in the presentation does not work, and found this replacement:
http://www.iana.org/form/ports-services
Some of these fields look quite intimidating. Do I really need to fill out a service name request to publish my bonjour app?
In the interest of preventing every iOS developer going out and creating arbitrary (and possibly conflicting) service names and ports for their own applications, Apple rightly stresses that you should go through the approval process. Remember there are services on all kinds of platforms that depend on mDNS.
In practice, if you can find a port that's used by some extremely niche application that nobody's ever heard of, then you can get away without registering. The implication of this is that no RFC-compliant mDNS responders will recognize or honour the port or service name you're advertising as it's not part of the 'prescribed' IANA list. But as long as you don't create lots of unwanted noise (e.g. advertising your service as _http._tcp when it is something else entirely) then you should be OK.
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 :)
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 9 years ago.
Improve this question
How do you protect your commercial application from being installed on multiple computers from people who only own one license?
Do you think it's a good idea to have more than just a serial based scheme?
My general rules are
Huge deployments in commercial environments - Audit
Medium deployments of low value software < $1000 / seat - License key activation
Small deployments of high value software > $10,000 / seat - Dongles
The following method works well, as long as you have a public server at your disposal:
Serial based protection, user must enter a serial before using the program
On first serial entry, bind the serial to the MAC address and create an auth code generated from both of these values.
Check with your server to make sure the serial and MAC can be bound to eachother. Register the MAC on the server.
On each subsequent run, never contact the server again, but each time make sure the serial + MAC address matches their auth code.
If the user has no MAC address, allow them to run the program as long as they have a serial.
This gives you protection against someone simply copying the registry from one computer to another.
If the user tries to install with the same serial on another computer, the server will not allow you to bind the serial number to the MAC address because it is already bound.
It is not a perfect solution but it protects you 99% of the time.
Do you think it's a good idea to have more than just a serial based scheme?
Speaking as someone who has to install all kinds of software on all kinds of machines, do please spare a thought for the poor network administrators when thinking up your copy protection scheme. Please, please, consider network-wide installs when writing your installer - by all means include some kind of serial number protection, even make me phone up or contact your website and get an authorisation code to get a site-wide installer code or whatever, but please make sure your licensing code works. A good way to ensure your technically-superior-to-anything-else-on-the-market software doesn't get installed and used is to mess up the installer or have an install system that is simply too much trouble.
Use machine-locked licenses or licenses requiring activation to lock licenses to specific machines. Instead of developing such a scheme yourself, consider using a ready-to-use one like CryptoLicensing which supports these features.
DISCLAIMER: I work for LogicNP Software, the developer of CryptoLicensing.
We use a MAC address plus license file approach. We have the customer send us the MAC address of their PC, then generate a license file based on that MAC address. We then send the file to them via email and then they load the license file into the program. The downside is that if people swap out network cards and you'll have to issue them a new license. It takes a little more bookkeeping to make sure people aren't always requesting new licenses, and a little trust in your customer base that they won't try to game the system too much. Depending on that trust level, you can add layers of encoding or encryption into the file so they can't easily duplicate the file. On the plus side, you don't have to implement or maintain any type of authentication server.
You can always use a USB dongle if the software is worth it. Of course, all dongle manufacturers claim that their copy protection cannot be broken.
The advantage of this method is that it allows the user to use the software on multiple computers, but only run on one at a time, and it is actually not such hassle like some sort of product activation. The disadvantage, of course, is that you cannot deploy your application completely electronically. Even though you might think the opposite, actually many customers seem to accept the use of a dongle, at least in the field I work in. It's especially useful if you expect your customers to use (and also install!) the software in a place where no internet connection is available.
Edit: I overread the serial-based thing in the original question. Note that even that may annoy users more than having to put in a dongle, and it's easier for you too because neither the customer nor you have to deal with that numbers. Plug in the dongle and the app works. However, the serial-only method is by far the cheapest.
We use Orion from Agilis. For some of our users we do activation of node-locked licenses, for others they get their activation by a web page or email, and for others we put a license server on their premises. Orion covers all the bases we need.
Beside the obvious person to person instant message chat, What else have you used a Jabber server's functionality to enable?
Edit: links to working code to really show it off are particularly useful - and will be more likely to be voted up.
There are unlimited uses for XMPP/Jabber.
Take any message/data you want to send somewhere else and you can use jabber. Run a centralised logging service for distributed services? You can jabber the massage.
You want to check if your services/programs are running? XMPP presence will tell you. If you add custom status messages you can see exactly what is going on.
This is why Cisco has got into the game. Picture a server farm where each blade has a built in mini jabber client. On boot up it will register it's presence to the central server as awaiting work. The central server fires off some work in it's direction and it then changes it's status to "Busy". Another blade finished it's work and changes it's status back to "Available"... rinse and repeat.
When you combine the actual jabber messages with it's Out Of Band abilities, these servers can post where the results of the job can be found.
Anything you can think of needing to pass a message can be done with XMPP to some degree. Be this person to person, program to program, or any combination.
You could use a Jabber server to handle/broker messages between a client application and another server application.
It can actually be pretty effective.
Not me but Martin Woodward used jabber to control a "build bunny" that displays the current status of the build server.
http://www.woodwardweb.com/gadgets/000434.html
XMPP is good for sending messages back and forth between computers that don't need to be broken into chunks. They also can't be terribly big. If you use the right library, it can be pretty easy to set up.
Sending messages to a web page. Proof-of-concept: esagila.com
I plan to use it to receive notifications from my system, such as:
Process did not finish
Report was not generated on time
User needs help
I already receive many of these messages as email. But receiving an IM could be much more effective.
You might want to look at Vertebra which is...
a framework for orchestrating complex processes in a Cloud. It is designed with an emphasis on security, fault tolerance, and portability.
From the knowledge base:
Why was XMPP chosen for Vertebra?
XMPP based instant messaging can be a good alternative to search engines for information that is small, complete in itself and required frequently and repeatedly. For example, your daily horoscope - you require it daily and it is not large.
To see an example of this add astro#askme.im to your list of contacts in your jabber client (Gmail Chat/Gtalk/or any other Jabber client) and then initiate chat with this contact by sending the word "help".
Also see www.askme.im for a whole list of chat based solutions.
I've used Jabber in the past to get email notifications. Nowadays I use it for low-priority nagios notifications, it is very useful and way cheaper than SMS:
We use xmpp as both a 'bus' and a real-time API at http://superfeedr.com
Iowa State University Department of Agronomy has created this with Jabber: http://mesonet.agron.iastate.edu/iembot/
If you're a weather freak like I am, this is VERY cool stuff!
Apple implements mobileme's push service using Jabber/XMPP's subscription services to send push notifications. That is the most widespread use of Jabber for non-IM purposes I know of. This article has more details.
My friends have also built a Jabber python bot, which is kinda cute but not all that useful :-)
Edit
The most recent Next Big Thing, Google Wave, uses Jabber under the hood. Further illustrates the power of the protcol.
We have used XMPP and BOSH to enable users to communicate with a webbrowser directly and in realtime from their phone.
For example Code you can view our open source API
The vooices site also has live examples where you can control a map and play a game using your phone via your web browser: http://www.vooices.us/
I've always thought XMPP would be a good way to deliver SNMP data. OIDs are really painful, much of the system is insecure, and the SNMP traps never work quite like you want them to. With an XMPP server in the middle and a smart component to make some choices, you can use it to send out jabber or other notifications, kick off restart jobs, update web pages, or whatever else you need.
The XML data is pretty small in this case, and you can have the one XMPP server both talk to humans in message stanzas, or computers with the same protocol.