When it comes to VoIP stuff though I always lean towards Twilio-but once again, it entirely depends on what you want to do.
OP, if you want to drop me an email, would be happy to help. gb@twilio.com.
It could be a chrome issue though because firefox works fine.
[1] https://webrtc.org/native-code/
[2] https://github.com/jangouts/jangouts
https://mightysignal.com/top-android-sdks?tag=47 https://mightysignal.com/top-ios-sdks?tag=47
https://news.ycombinator.com/item?id=15690623
Thanks
Spend some time trawling the various soft-switch mailing lists. Join the VoiceOps mailing list and trawl through there. Read the SIP RFCs and curse their use of MAY and MIGHT and SHOULD! :)
There's a lot of wisdom baked into the projects about how to handle phone calls; I don't know that there's money to be made redoing their work to be honest. Scratch the itch for sure! But be honest in your expectations - you're probably looking at years before your project becomes viable (unless there's a JS/Node SIP stack out there you could plug into already?) in a commercial sense.
Best of luck!
Asterisk is really, really solid, and will handle a lot of things for you that you shouldn't have to care about handling - lower level stuff.
Check this out: http://www.igorescobar.com/blog/2014/08/13/working-with-aste...
If you're going through the SIP RFCs for what you want, you're attacking the problem at the wrong layer of the stack. It's just not necessary to write your own SIP stack. It'd be like writing SSL negotiation logic for a web app: totally pointless. Just use what already works and extend it with the fancy UI and dev experience that you want. It's totally possible.
Source: work there building Kazoo
- Launch a call programmatically (from an extension to a phone number) while setting a custom caller ID.
- Check extension status: idle / calling to {phone number} + call duration
- Read call history log for the day (talking time, calls made)
- Record a call
- Monitoring functions over calls: listen/whisper/barge
We are able to provide all of those already, but using FreePBX + a SIP trunk provider.
The problem is, our approach seems difficult to scale, as we will have to develop the VoIP infrastructure to support new users, and we don't want to go that route, as we want to focus on the software.
We would rather outsource that part to some VoIP provider with an API that enables those functionalities, however some well-known services (like 8x8.com) don't provide all those functionalities and some others that do provide them (like RingCentral) turn out to be too expensive, pretty much double our current cost.
Any suggestion?
Let us build your VoIP infrastructure and help you with technical support when you have call issues.
Contact sales@2600hz.com if you want a demo, talk through your requirements, etc. I can also answer your questions here as I'm able (one of the core developers of Kazoo).
I'll try to list the reference docs that probably address your points:
- If you plan to have devices/users in Kazoo, you can use the quickcall functionality[0] to connect them to a phone number. Includes setting custom caller ID. Some folks build queues using conferences and you can dial out[1] from them as well
- With the channels[2] API you can query active channels per account/user/device.
- With the CDRs[3] API you can fetch CDRs over a range of time
- You can setup call recordings automatically for devices/users/accounts (see [4] for example). You can also enable them on-demand in the callflow (JSON tree that determines how to process a call).
- Depends on whether you bridge two callers together or put them in a conference how you implement these features but definitely do-able.
From what you've described, your use case fits in our sweet spot of providing the infrastructure for you to build on. You get the scaling of your app for free by using Kazoo, in that Kazoo presents one logical soft-switch while taking care of the bookkeeping of which media server calls and conferences actually exist on. You can setup Kazoo yourself to play with it (currently recommendation is to use CentOS[5] but Debian is coming), knowing that we have professional services and SaaS/PaaS/Iaas offerings to get you going faster as well.
Hope that helps!
[0] https://docs.2600hz.com/dev/applications/crossbar/doc/quickc...
[1] https://docs.2600hz.com/dev/applications/crossbar/doc/confer...
[2] https://docs.2600hz.com/dev/applications/crossbar/doc/channe...
[3] https://docs.2600hz.com/dev/applications/crossbar/doc/cdrs/
[4] https://docs.2600hz.com/dev/applications/crossbar/doc/device...
[5] https://docs.2600hz.com/sysadmin/doc/install/install_via_cen...
But it seems like a good option for sure, thank you for taking the time to point me to the specific parts of documentation related to the functionality we need to implement.
I will be checking the viability of using this service and contacting sales for a demo if it seems like a good fit.
If/when you go full throttle and need more power, we offer custom boards that will run the infrastructure for you versus the hosted offering which you share with other tenants. And if you have your own hardware, we can install/maintain the software in your datacenters (and transitioning off hosted to one of these is done with 0 down time and transparent to your users).
And of course you can build it all yourself from the RPMs.
One thing to note is that a properly configured Kazoo cluster is redundant across data-centers so outages in one geographical area won't impact customers in other areas, and customers pinned to the down data center will fail over to the next closest during the outage.
Anyway, things to consider as you plan what your infrastructure will need to handle. These are mostly independent of Kazoo and things you'll want to think about regardless of the solution/provider you move forward with!
sales@2600hz.com is the best way to reach you or someone in there to discuss pricing and some other details?