KCT-02: Kazoo Zone Architecture (en)

• by mooseable
• 12 May 2020

As in my previous post, Kazoo brings a lot of existing projects together.

Session Border Controller (SBC)

2600hz Kazoo utilizes Kamailio as its session border controller. Public devices and carriers hit the SBC first. The SIP SDP is then processed by Kamailios rules and if not blocked, is told where to dispatch the call to and routes to the Media servers. It also subscribes/listens to the message bus (RabbitMQ) for things like presence tracking.
With the right features enabled, it will mitigate sipvicious attacks, allow SIP SIMPLE messaging, prevent SIP flooding and more.

Media Server

Freeswitch is the media server of choice here. It does the media codec negotiation, audio leg setup and It publishes/listens to events via RabbitMQ. Most of the call control is done via the ecallmgr Kazoo App.

Message Bus

The glue that binds.
RabbitMQ is the backbone and is what allows these separate components to talk to each other. Each service connects to the RabbitMQ message bus and sends or receives messages from other services. As an example, when Freeswitch loads it subscribes to RabbitMQ and requests ACLs, then the ecallmgr application is listening for that message and in response, sends the list of ACLS back to RabbitMQ. Finally, since Freeswitch is subscribed/listening to that message, it receives the list of ACLs that it needs to configure itself with.

Kazoo Applications

Written in erlang, each app communicates with the rest of the cluster, even other apps, via the Message Bus (RabbitMQ). You can extend Kazoo with other languages, since it all makes use of the RabbitMQ message bus to communicate, but everything I’ve seen so far is in Erlang.

The applications control the logic behind the system, such as how a call is routed, voicemail boxes, fax boxes, how calls are billed and rated, if an account has limits, webhooks, the API and everything else

Database

Originally using BigCouch and officially moving to CouchDB. CouchDB is a json-based, easily clustered and replicated database.

I use CouchDB over the pre-packaged BigCouch for better clustering, but it is a simple JSON document store database. It has a interesting approach to clustering and is very developer friendly, but the user interface leaves a little to be desired. I would highly recommend getting use to the REST-like commands required to manage your CouchDB cluster. The latest version of CouchDB supports resharding, allowing you to more easily scale your cluster as load increases.

HAProxy – TCP Proxy

If you are familiar with NGINX or other load balancers, HAProxy will not present much of a challenge. It is relatively easy to configure and easier to reload with updated configuration. Not pictured above, it is typically used to balance/failover the Kazoo API, SMTP and CouchDB.

Kazoo MonsterUI – The interface that saved Kazoo

In the beginning, there was an API. 2600hz rightly so started with the idea that implementors of Kazoo would design their own UI, but many more wanted to just stand up VoIP infrastructure an manage it without having to deal with the API all the time. At first, KazooUI was developed and later, the much nicer looking and easier to manage MonsterUI came along. This is one of the main reasons I gave Kazoo a shot.

Fuente: https://mooseable.com/kct-02-kazoo-zone-architecture-and-kazoo-applications/

Carrier Types

#

Every number in the system has an internal property called pvt_carrier_module that defines which carrier module is used to manage the number. The carrier module can modify how the number behaves in the system.

Manual Number Management#

knm_local#

This module is responsible for "local" numbers, that is number that only belongs to one account (local to that account) and not to the system. These numbers are expected to be added by the admin of the account (local admin) for use with that account only. Furthermore, it is expected the number is owned by the local admin and not the system operators. For example, if an account was using its own carriers (local resources) then all numbers would be owned by the local admin and not participate in any of the automatic facilities provided by Kazoo.

These special numbers do not behave like any other numbers in the system:

• When released they are completely deleted from the system, bypassing the typical lifecycle
• By default they are not quantified by billing modules
• By default they do not trigger call authorization
• By default they can not be used to route inter-account calls without leaving the cluster
• By default they can not use any number features that would incur charges/cost (such as E911 and CNAM)

knm_inventory#

This module is responsible for number inventories that are manually managed by the system administrator. All numbers managed by this module will move through the typical number lifecycle.

These numbers are expected to be added via CSV jobs/tasks as available numbers, search and found by local admins and returned through aging to the available pool if released.

knm_managed#

This module is responsible for numbers that are generated for specific accounts by the system administrator. All numbers managed by this module will move through the typical number lifecycle.

These numbers are expected to be added via SUP as available numbers that can only be searched and acquired by the pre-determined account.

Primarily, this is used for testing or development.

Example#

Generate 5 numbers, starting at 2223334000, for {ACCOUNT_ID}:

sup kazoo_number_manager_maintenance generate_numbers managed {ACCOUNT_ID} 2223334000 5

knm_mdn#

This module is responsible for numbers added for mobile services. All numbers managed by this module can only be in_service. They behave like knm_local numbers.

These numbers are internally generated and do not have a direct means of creation via the phone_numbers API.

Integrations#

knm_telnyx#

This module integrates with https://telnyx.com/ to provide number searching and provisioning services.

knm_vitelity#

This module integrates with http://www.vitelity.com/ to provide number searching and provisioning services.

knm_voip_innovations#

This module integrates with https://voipinnovations.com/ to provide number searching and provisioning services.

knm_bandwidth#

This module is deprecated please use knm_bandwidth2.

knm_bandwidth2#

This module integrates with https://www.bandwidth.com/ to provide number searching and provisioning services.

knm_inum#

This module integrates with http://www.inum.net to provide number searching and provisioning services.

knm_other#

This module is current a work-in-progress to provide a generic interface for midware applications.

Telnyx Carrier Module#

Documentation#

• Telnyx general documentation

Configuration#

Configuring number manager#

To enable KAZOO to use the telnyx module you will first need to update the number_manager document in the system_config database.

In the configuration section that applies to your crossbar servers (or the default) add "knm_telnyx" to the carrier_modules parameter.

For example:

       "carrier_modules": [
           "knm_local",
           "knm_inventory",
           "knm_managed",
           "knm_reserved",
           "knm_reserved_reseller"
           "knm_telnyx"
       ]

Configuring the telnyx module#

{
   "_id": "number_manager.telnyx",
   "_rev": "XXXXXXXXXXXXX",
   "default": {
       "debug": "true",
       "enable_provisioning": "true",
       "monthly_recurring_cost": "1",
       "sandbox_provisioning": "true",
       "should_filter_rates": "false",
       "should_keep_best_effort": "false",
       "token": "pasteyourtoken here",
       "upfront_cost": "false",
       "user": "emailaddress here"
   }
}

Note

Only set debug to true if u want to debug, creates a telnyx debug file on your server /tmp

Kazoo defaults to area codes with a minimum length of 3 numbers, and its done in the database schemas, so if you search for numbers with fewer digits, it will give an error.

One workaround is to set the area code minLength property to 1 in find_numbers.json in crossbar/priv/couchdb/schemas on your server and then run sup crossbar_maintenance update_schemas to persist it to the db.

Portal Demostracion PBX

Mediante el siguiente enlace, usted puede acceder al portal de demostracion de Kazoo/2600hz.

Para cualquier inquietud; sientase libre para comentar.

https://demo.aurus.com.do

Usuario: demo

Password: demo

Nombre de Cuenta: demo