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.
Related
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.
I think about the following setup, but I do not know how to connect the main parts.
One the one side there is a Kamailio SIP server. This server provides VoIP connectivity within a certain network (non public intranet).
On the other side there is a SIP provider. This provider provides a single telephone number from the PSTN. Let's say the number is 0034-443322.
Both components are working fine so far.
I want to use that number as a dial-in to my private network. A user with number 8282 in my network should be reachable via 0034-443322-8282 from the outside world. Outgoing calls aren't necessary.
How to reach my goal? I don't know what to look for :/ Any ideas are very welcome :)
kind regards
K.A.
If your PSTN gateway can be reached by dialing the full number (including the extension), simply let the gateway forward every incoming call to your Kamailio instance which will forward the call to the appropriate user. For that, you need to create your users (known as subscribers in Kamailio) and they need to register to your Kamailio instance so that they can receive incoming calls. Regarding mapping extensions to users, you can simply let the extension be the username; or you can add extensions as aliases of the subscribers.
I am not overly technically savy so I am asking the community if this can be done.
I am using ONSIP.com as a hosted PBX solution. ( Its easy and I like their interface.
What I would like to do is use their "bridge function" to have Twilio be the source for my SIP numbers.
I think this can be done because ONSIP describes how I can get an international number from DIDWW>com and have it "pointed" into to my system. So I thought, why not have Twilio supply me with numbers, local and international.
The real question I have though is can I make calls out on that SIP number, going through ONSIP.com to start the call but have Twilio actually make the call , (if that makes sense)
ONSIP.com charges 2.9/minute in or out bound and it appears as though Twilio is on 1/minute. so it would seem to make sense to do this if it can be done?
Here is their info on an inbound bridge
http://www.junctionnetworks.com/knowledgebase/onsip/admin-portal/apps/inbound-bridge
Thanks for any advice or input you might have on this subject.
What you need to find out is if OnSIP and Twilio both support SIP transfers.
To have a call you've started on OnSIP's server "moved" to Twilio it will require the use of SIP REFER requests, which are how call transfers are done in the SIP World. Without a transfer it means your call would end up going through both OnSIP's and Twilio's server and mean you end up incurring both sets of charges.
I suspect you'll find one or both of them don't support transfers since such functionality can be tricky for a SIP provider to implement and it's also it's not going to be in the originating provider's interests, in this case OnSIP, to provide you with a way of avoiding their call charges.
Perhaps an easier way for you would be to get an IP Phone or ATA that has two or more SIP lines and connect the first line to OnSIP for incoming calls and the second line to Twilio for outgoing calls.
For anyone who finds this now, Twilio does not support Sip Refer at the time of this post
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 still learning about SIP and all its protocols, specifically trying to integrate PJSIP into an iPhone application to make p2p calls.
I have a question about a peer 2 peer connection using PJSUA. I am able to
make calls perfectly to other clients on my local network by calling directly using the URI:
sip:192...*:5060
I am curious if this will work for
making direct calls to other SIP URIs that are not on the local
network without using server configuration - if not this way, is there another way of making p2p calls without server configuration?
thanks in advance,
You can make calls without server configuration, as a general principle, but something needs configuring. As mattjgalloway points out in the comments below your question, the most robust solution is a can of worms involving ICE which provides a kind of "umbrella" protocol for things like STUN.
Last time I touched this issue, I had the requirement that I couldn't use internet-based SIP servers to help. I came up with the idea of a registry of sorts: your client can define a bunch of "address spaces" with particular routing requirements. For SIP URIs in your LAN, you define no routing; for URIs in your company's VPN-accessed network, you define a route passing through your VPN connection; for everything else you define a route through your internet router.
By "define a route", I mean that when you place a call to a URI in some particular address space, you store what IP will go into a Contact header, what Route headers you might need, and so on.
Thus, the process of making a call becomes:
Look up in the set of address spaces for a match.
Ask that address space for the suitable bits needed to make a workable INVITE (appropriate Contact header details, Route headers, etc.)
Construct a normal INVITE, mutating as necessary for the previous step.
Send the INVITE as normal.
This essentially reproduces half of what ICE would give you, in a manually administrated form. "Half", because this ensures that one SIP agent can make calls such that the SIP routing all works. The missing half is you still need some kind of registrar somewhere, and each agent in your contact list needs to have the necessary setup to receive incoming calls. (If an agent's behind a NATting internet router, the router would need to either run a SIP proxy, or forward ports 5060, 5061 to a particular machine (which might be an agent, or a proxy serving the LAN's agents).
It is, indeed, a large can of worms.
The basic issue is to solve the problem of getting transport ports anywhere on the internet for multimedia traffic.
Many companies/experts have tried to solve this situation. A possible way out of is to buy a domain and setup a basic registrar using YATE or Asterisk on an address accessible from the internet and configure it to also use ICE as needed. Your iphone application at both ends could register automatically to it upon start. Then make P2P calls.