mc_

Happening with AdNauseum enabled too: https://github.com/dhowe/AdNauseam/issues/2692

It used to be the wild west but FCC is tightening up (maybe even going too far, we'll see). STIR/SHAKEN and KYC (know your customer) rules are making it more expensive for providers to allow any traffic over their networks. Shady providers would look the other way at spammers pumping traffic (providers getting paid); shady providers mix legitimate traffic in so upstream carriers can't just block them, etc.

Now, there's more regulatory teeth to go after the shady providers allowing this traffic.

I know FreeSWITCH and Kamailio both have WebRTC connections available, so if you use a SIP client in the browser over WebRTC to the server, you can plug into telephony networks on the server side.

We use Kamailio's WebRTC implementation heavily in Kazoo along with our libwebphone client. The transport is abstracted so Kazoo deals with the device and its configs; the Kamailio instance the browser connects to does the TLS termination for WebRTC. FreeSWITCH has the smarts for the SDP DTLS bits. And it all just works real nice together.

"Issues with Magic Transit and BYOIP" apparently, looks to be identified now.

Seems to coincide with Bandwidth's outage: https://status.bandwidth.com/incidents/d8vft1kpxdmk

There are many graziers to refer to without bolstering the racism of Salatin.

Greg Judy and Gabe Brown being some bigger names but Chris from Sylvanaqua Farms is a good Black/Indigenous voice to start listening too.

Curious how the Erlang->C++ progress is going? I asked a bit over a year about it (which I think prompted the pre-emptive note :) ); obviously not owed an explanation but perhaps you can get a quick update on whether the migrations are more painful than expected, or the scope of changes in-/decreased, etc?

We've used RabbitMQ since 2010 in KAZOO. I would argue, save one or two instances in the intervening 10 years, that RabbitMQ is the most stable piece of the infrastructure. I think it might be the only open-source project we build on that we haven't committed upstream to because we haven't encountered any issues in our usage.

The Regrarians [0] is another avenue to explore - I find Darren a bit more grounded in science than your average "permie" and appreciate the work he's doing, integrating holistic systems design (see Savory Institute), permaculture, and Yeoman's keyline design work. It seems more of a toolbox approach vs what can feel like "doctrine" at times from permaculture. Perhaps more suitable to larger farming operations than backyard gardens but still worth reading, I think.

[0] http://www.regrarians.org/

Kazoo [0] offers this as a config option on devices (which can represent SIP desk phones, soft phones, WebRTC endpoints, or call-forwarded cell phones): call_forward.require_keypress [1] There's a lot of re-inventing of telecom wheels required (if even possible) with TwiML (and clones).

[0] https://github.com/2600hz/kazoo [1] https://docs.2600hz.com/dev/applications/crossbar/doc/device...

WombatOAM seems similar:

https://www.erlang-solutions.com/products/wombatoam.html

We have a fair bit of property tests in KAZOO now, using PropEr[0], an open source implementation in Erlang.

Fred (of Learn You Some Erlang) wrote a great book/site[1] on property testing in Erlang and Elixir, well worth the price of the book.

I find property testing is a muscle; the more time I can spend writing them, the "better" I get at writing useful tests. But the muscle atrophies quickly for me, so having the existing tests helps speed up getting into the mindset again.

I think the model checking (proper_statem in the PropEr code) is the real winner though. We can model a part of our system, write state transitions and then test those against both the model and a running system and compare our results. Any discrepancy points to either the model or the system being wrong (which is its own joy/pain to figure out).

[0] https://github.com/proper-testing/proper

[1] https://propertesting.com/

We're happily plugging along on KAZOO [0] since 2010 at 2600Hz. Erlang is a force-multiplier for us. Approaching 300K LOC and ~10 Erlang engineers (depends if Karl is writing code or CTO-ing that day) today.

[0] https://github.com/2600hz/kazoo/

Interesting, thanks for the teaser :) I'll look for the writeup as well!

Any explanation on why you're moving away from Erlang to C++? Curious about the tradeoffs you're making with that decision.

Also check out Nikola which has a nice orgmode plugin.

We use Erlang to build Kazoo (https://github.com/2600hz/kazoo). In production since 2011, deployed around the world in various clusters.

Nikola[0] has an orgmode plugin[1] that works fine for my blog. After I write something up, nikola builds the site (incremental build), I can view it locally to verify the rendering, and finally rsync the changes up to the web server.

[0] https://getnikola.com/

[1] https://plugins.getnikola.com/v8/orgmode/

We moved the majority of docs for our projects (https://github.com/2600hz) to use mkdocs to build our doc sites (https://docs.2600hz.com/dev https://docs.2600hz.com/ui etc).

I have a simple script that receives github webhooks on PR merges to master that fetches the latest version of master and builds the site. So from PR merge to the docs site being updated is now seconds of time.

We also integrated building the doc sites into our CI process so PRs will fail if they would cause mkdocs to fail to build the site (borked yaml, make sure docs are included in the yaml, other things).

This has been a boon for our community of users and developers. Coupled with our AST parsers that look for code changes that require doc changes, we're getting better about alerting developers of the need to document something, and reviewers of the need if the developer forgot. Not a panacea but has significantly improved doc coverage for Kazoo which has a broad set of APIs available to different types of users.

Cheers to 1.0!

Sales will get you all the info you need and can setup further calls with engineering/operations/whomever as necessary to get you going.

Well, it depends. You can signup for the hosted platform and use our provided carriers (transparent to you), purchase numbers via API, manage their lifecycle, assign them to sub-accounts, etc. So if you want a proof of concept, that is definitely the fastest way to get up and running.

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!

Understood. I don't want to deter you; I will instead suggest taking a little more time to learn about telecom, SIP, and running telecom infrastructure. Just glancing at your repo, I see you are trying to send/receive the SIP yourself, which is ambitious. SIP interop probably accounts for a larger-than-it-should-be percentage of support issues; non-negligible amounts of time are spent arguing with other carriers and phone manufacturers about interpretations of the SIP RFCs.

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!

Hi Otto,

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...

2600Hz is who you are looking for in this case! :)

Let us build your VoIP infrastructure and help you with technical support when you have call issues.

Contact [email protected] 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).

Just curious how you evaluated projects like FreeSWITCH and Kamailio and what you found lacking/horrible? We have been building on them for 8+ years now with no major issues. We've found both communities and core teams to be helpful and responsive with bug reports, feature requests, and pull requests.

2600Hz has an API-driven platform, Kazoo[0], built on FreeSWITCH and Kamailio. You can use the APIs to start calls, modify in-progress calls, and more. Multiple commercial offerings[1] depending on your needs are provided by 2600Hz as well.

Source: work there building Kazoo

[0] https://github.com/2600hz/kazoo

[1] https://www.2600hz.com