I'd like to integrate some phone status information into our crm system (calling, on the hook, busy etc). I would prefer not to build and maintain a fully functioning SIP server because i only need very basic information. Also, our VOIP provider already maintains a fully functioning SIP server, and they are way better at it. Basically, I would my crm sever to be kept up to date on anything the phone does? Would it be possible for our crm server to receive any SIP messages the phones send to our VOIP provider.
Can I tell a sip phone to do that?
Is such a feature supported by many phones?
Am i looking at this in the wrong way? I'm completely new to SIP and phone integration so there is a good chance there is an easier or better way to do this.
Thank you for your help!
You might use phone feature called Action URL. It is generating HTTP GET requests on events like on hook / off hook, these request can be used to pass events to CRM.
Related
I am trying to develope chat app. I have done created my web service with php and mysql.
The respond of web service is json format.
In swift part; i post some paramaters to web address and retrieve json respond then show the messages. I used use nstimer to post and retrieve the respond of my json respond. And if there is new message the show it.
I dont want to use nstimer for retrieve the message. Is there any better way to do that?
Thank you
If you have a REST-ful service, periodically polling is pretty much the standard way to do it.
Instead of polling, you could consider using a real-time update mechanism to either deliver the message, or else inform your client that you need to sync with the server. Google has developed a pretty robust, cross-platform solution that allows you to achieve this using the Push Notification protocol:
Google GCM XMPP
Take a look at this tutorial. It uses XMPP to pass messages back and forward.
But if you want to do it yourself just to learn you have two options:
Use a restful api where you GET and POST. The timer you have isn't bad. I would recommend changing the time when the app is in the background or not doing it at all. You can use something like parse to send PUSH notifications and reinitiate the GET calls when the user relaunches the app.
You could use WebSockets. WebSockets work a lot like BSD sockets except that they are wrapped in a HTTP(S) tunnel. With web sockets, you can check to see if the client you are looking for is connected. If they are, you just send them the message. If they are not, you do something like in option one using parse to send them a notification.
Hope that helps.
Edit:
Since parse is shutting down, you can use another service like it. I've never used kinvey but it seems that they also provide similar services as parse like the push notification mentioned above
I have a question about integrating with a phone company (the Provider) using SIP.
I have a situation:
1. A call is made to a PSTN number
2. The Provider forwards the call to a SIP Gateway
3. Twilio is the SIP Gateway, so I receive an HTTP request for every new call
4. I execute my application logic
As I understand the SIP integration between the Provider and Twilio is done using SIP INVITE.
Now a have the challenge is to implement the integration using SIP REGISTER.
As I imagine, the scenario should look like this:
1. I register against the Provider using SIP REGISTER
2. A call is made to a PSTN number
3. The Provider gives me the call
4. I execute my application logic
I need to figure out what is needed in order to accomplish this:
Firstly, does this scenario make sense?
Do I need to use a PBX solution (like Asterisk, FreeSwitch) to implement SIP REGISTER and build my application on top of it?
If so, which PBX solution do you recommend and which features/modules are needed? And do I have to host it on my server?
Perhaps I don't need a PBX solution, and a library is enough as described here?
It is the Provider pushing for this way of integration and I have too little knowledge about it.
What I have figured out is that Twilio can't help me with this. So it looks like I have to take a part of solution in-house.
REGISTER is required if your terminal or terminals belong to the domain of a VoIP provider.
REGISTER records the mapping between the identity the VoIP provider gave you and the actual address and port where you will be listening for requests.
This way, calls addressed to you (sip:myuserid#voip.domain.com) will be sent by the VoIP provider to the address of record it has for you.
If you are a VoIP provider yourself (i.e. you have a sip:myuserid#myowndomain.com), then your peer voip providers will route requests to you based on DNS records or internal domain-based routing decisions. Once the call reaches you, then you can decide on how to handle it. If you are a real SIP provider, then you will have a registrar where you store the result of the REGISTER of your different users.
If you want to implement some application logic on your end, you have different options:
Easiest way is to implement a UAC/UAS, basically a terminal. Your application is the terminal, it registers with the VoIP provider and receives all your calls. You will just need the SIP stack, and you can do whatever you want with the call.
Using a PBX software. Basically it will handle normal calls for you, and the REGISTER when needed. Typically they will have APIs to perform some degree of automation/modification of the call handling.
Difference between the approaches, in the first case, you just have the protocol, so you must do everything else. In the second case, the objective is to process normal calls and they will offer you some window (smaller or greater) to see into those calls and do things with it.
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 :)
I am builing a win application that has user access control against a sql db, all the data is stored in this db as well.
This project is to be installed in one site on 30-40 machines (I mean to say that it's not web, it's all in one place, maximum call it intranet).
I want that while the program is logged on, the logged-in user should be able to chat to the other logged in users.
Any recommended approaches in C# & VB?
I would appreciate any idea, link or tip.
Please share me with your experience
Thanks!
NOTE: The program is in Wpf if it does matter.
Architecturally, it seems like a publisher-subscriber message bus would be a good pattern for you. You would have a centralized server that each client would register with that will distribute notifications from publishers to subscribers.
Each client will register for notification of the client list upon starting. Each client can register interest in being notified when another client publishes a message. Each client would publish messages to the bus to be delivered to any subscribers for that client.
There is a good example of a pub-sub message bus written in WCF in MSDN: WCF ESSENTIALS What You Need To Know About One-Way Calls, Callbacks, And Events. You could get this up and running fairly quickly.
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.