Playing Kazoo
Dudka-style
Experience from
across the globe
Mikhail Rodionov, CEO,
Who? Where? Why?
About US
Who we are?
•Location: Novosibirsk, Russia. That's right, that’s somewhere in Siberia
•Occupation: Professional services company
•Ambitions: High
•Ideas: a lot
We give a thing
about KAZOO!
Novosibirsk, Russia, where is
it!?
We are right there
What we do?
•We plan, design, deploy, test, maintain and support Kazoo-based
systems for our clients
•We develop for KAZOO platform
•Outside KAZOO we work with sipXecs, plain FreeSWITCH and even
sometimes Asterisk (yep, guilty)
•We resell Yealink hardware and develop Yealink-based solutions (like
Yealink support for sipXecs)
What we do for our clients
PROJECTS
Client: Moscow-based ITSP
•Dedicated CEPH cluster for storage (24Tb)
•CloudStack/KVM-based private IaaS cloud infrastructure
•2xRabbitMQ, 2xKamailio-SBC, 3xKAZOO, 3xFreeSWITCH, 3xDB,
2xKamailio-Outbound, SIPCAPTURE, LogStash/ElasticSearch, Email2Fax
SMTP proxy, HA PaaS platform for Pivot scripts, monitoring
infrastructure, reverse HA HTTP proxy for API access, etc.
•Custom built Kamailio with custom Kamailio RADIUS module for
outbound gateway
•Heavily patched stable 3.13-based system
•12 2CPU hardware nodes
•Tested at 2000 concurrent calls/35 CPS/20 API calls per second
•Client-developed custom UI
Client: US-based SaaS
•Really tight integration with custom SaaS CRM system
•KAZOO is hidden behind the scenes and is top-secret
•Targeted to up to 10000 concurrent calls (!)
•Custom version of KAZOO with proprietary modules
•SuperMicro micro-cloud servers
•SuperMicro 1U servers for storage cluster
•Private cloud infrastructure
Planned:
•Custom ACD (call-center) application
•Integrated voice quality monitoring solution
•WebRTC frontend (now in development)
Product in development:
Converba Cloud Platform
SIPLABS turnkey Kazoo-based
solution
•Ubuntu LTS-based
•IaaS/PaaS/STaaS platforms included
•Custom admin UI
•Custom client UI
•Stable (internally tested and patched)
releases
•Everything highly-available
•Rich set of scripts included
•Built-in centralized log
collection/monitoring
•Built-in monitoring/alerting system
•Built-in backup/recovery system
What’s already done?
Contributions
Kazoo-UI i18n
It all began with this contribution
•All string constants in kazoo-UI were replaced with gettext-like function
calls
•Russian language pack was included
After_bridge callflow module
•After hangup call control
•Allows remaining leg of call to be transferred to some extension or
parked
•Useful for call QA (like in real call-centers)
"numbers": [
"2010"
],
"flow": {
"module": "after_bridge",
"data": {
"action": "transfer", // “transfer” or “park” or “hangup”
"data": "1002“ // Extension to transfer ramaining leg to
},
"children": {
"_": {
"module": “user",
"data": {
"id": "048c8190b52d6f0850a1b72f376dfb9b"
},
"children": {
}
}
}
}
Eavesdrop callflow module
•Allows eavesdropping (spying, whispering) for generic (non-ACD) calls.
Leg B is addressed
•Provides security mechanisms for limiting access
•Implemented as generic (target required in data) and feature-code type
modules
{
"numbers" :[
“2555"
],
"flow" :{
"module" : "eavesdrop", // “eavesdrop” OR “eavesdrop_feature”
"data" :{
"device_id" : "143c8140b52f6f085aa1b74f376dfb9b", // Device OR user to eavesdrop
"approved_device_id":”453afa67b52fdf0f5a45c74f316df5c5" // Device OR user OR
// group allowed to eavesdrop
},
"children" :{
}
}
}
NB: whispering mode can be managed via DTMF
commands
Intercept callflow module
•Allows intercepting ringing or answered calls. Leg B is addressed
(changed)
•Provides security mechanisms for limiting access
•Implemented as generic (target required in data) and feature-code type
{
modules
"data" :{
"numbers": [
"2001"
],
"flow" :{
"module" : "intercept", // "intercept_feature" is also available
"data" :{
"device_id": "d9722acd6db64e0686365cd79747aabe", //calls to this device
// will be intercepted
"approved_group_id": “3479acd7452fdf0f5a45c74f336455b7" // Members if this
// group are permitted to intercept calls
},
"children" :{
}
}
}
}
Pattern lists (API)
•Lists are meant to be used as a storage for named CID patterns
•Special API is created for managing lists and list entries
Lists manipulation
Create list: PUT /v1/accounts/{account_id}/lists
Get all lists: GET /v1/accounts/{account_id}/lists
Get list: GET /v1/accounts/{account_id}/lists/{list_id}
Modify list: POST /v1/accounts/{account_id}/lists/{list_id}
Delete list: DELETE /v1/accounts/{account_id}/lists/{list_id}
List entries manipulation
Add entry: PUT /v1/accounts/{account_id}/lists/{list_id}
Get list entries: GET /v1/accounts/{account_id}/lists/{list_id}
Get list entry: GET /v1/accounts/{account_id}/lists/{list_id}/{entry_id}
Modify list entry: POST /v1/accounts/{account_id}/lists/{list_id}/{entry_id}
Delete list entry: DELETE /v1/accounts/{account_id}/lists/{list_id}/{entry_id}
Pattern lists (API), cont.
{
"data": {
"id":"caea32f84b5b2538d0e99c68b6891df7",
"name":“testlist", // lists are named
"entries":{
"6d42b485b84b8c8c68fc34dd612e7766":{
"pattern":"^79\\d{9}$", // entry pattern
"firstname": "Mobile", // first name (optional)
"lastname": "Phones", // last name (optional)
"displayname": "Mobile phones", // display name (optional)
"type" : "range" // type – freeform string (optional)
},
“53476538abcd38475638475638438465":{
"pattern":"^7495\\d{7}$", // entry pattern
"firstname":"Moscow", // first name (optional)
"lastname":"Landlines", // last name (optional)
"displayname":"Mobile phones", // display name (optional)
"type": "range" // type – freeform string (optional)
},
}
}
TODO: Add "number" (exact match) parameter
Pattern list CID match
(callflow module)
•check_cid module was there before, but it was meant to match one
pattern
•cidlistmatch matches CID to the whole list and makes it easy to manage:
• VIP lists
• Black lists
• Area-based routes
• …
{
"data":{
"id":"01fc63f92d9b89a25dd4ff1039e64497" // list id
},
"module":"cidlistmatch",
"children": {
"match": {
}, // something to do if CID matched over list
"nomatch": {
}, // something to do if CID did not match
}
}
TODO: use CID types (internal/external)
Set CID callflow module
•Modifies CID name and number (useful for Pivot scripts)
{
"flow" :{
"module" : "set_cid" ,
"data" :{
"caller_id_name": "ACME Inc." // "caller_id_number" can also be changed
},
"children" :{
"_": {
"module": "user",
"data": {
"id": "048c8190b52d6f0850a1b72f376dfb9b"
},
"children": {
}
}
}
}
TODO: use CID types (internal/external)
TODO: set_cid_from_list module – to set CID
based on list
CAMP-ON feature
PBX Camp On
This feature is used to "stack" a call onto a busy
extension.
If the called party hangs up, their phone will ring
with the "stacked" call.
•New application was created and named "camper"
•New callflow module (feature code) was created to initiate "camp on"
calls
•Works{ differently for onnet and offnet calls
"flow": {
"module": "camping_feature",
"data": {
"tries":10, // number of tries (for offnet calls)
"try_interval":1, // interval between tries, minutes (for offnet calls)
"stop_after": 10, // operation timeout, minutes (for offnet calls)
"timeout":9 // for onnet-calls: wait timeout
},
"children": {
}
},
"featurecode": {
"name": "camping_feature",
"number": "777"
},
"patterns": [
"^\\*777([0-9]*)$"
]
}
SBC per-account/per-device
ACLs (SOON!)
•New application was created and named "kamdb"
•Kamailio module db_kazoo was modified to match
•New Kamailio configuration role was added: ACL-ROLE
•Every account/device can have ACLs that work on SBC
•Devices can't register or make calls if their IPs don't match ACLs
•IP and (soon) User-Agent ACLs
"acls":{
"order":"AD", // Allow-Deny, "DA" means Deny-Allow
"cidr":[
"12.34.23.54/32"
,"54.34.65.23/32"
]
}
TODO: Special API within accounts and devices
(/acls)
SBC per-account/per-device
rate limits (SOON!)
"rate_limits": {
"own": {
"per_minute": {
"invites": 2000,
"registrations":
"total": 10000
},
"per_second": {
"invites": 5,
"registrations":
"total": 30
}
},
"device": {
"per_minute": {
"invites": 20,
"registrations":
"total": 300
},
"per_second": {
"invites": 2,
"registrations":
"total": 20
}
}
}
}
2000,
5,
20,
2,
•"kamdb" application used for ACLs is used for
rate-limits as well
•Kamailio module db_kazoo was modified to
match
•New Kamailio configuration role was added:
RATE-LIMIT-ROLE
•Every account/device can have rate limits that
work on SBC. Accounts may have rate-limits for
entire realm or for devices
•Per-second and per-minute rate limits are
implemented
TODO: Special API within accounts and devices
(/ratelimits)
What we are working on right now
Future contributions (Q4)
Device manager (aka
Provisioner)
•Device provisioner implemented as KAZOO application and set of
crossbar modules and APIs
•Profile (policy) based devices configuration
•Profiles contain data for various brands/families/models
•Multiple profiles can be assigned to device/account/provider/system
•Core modules and data/modules for Yealink will be open source and
freely available (hopefully as part of KAZOO)
•Sponsors will get everything
Benefits
•Highly available and fault tolerant (because it's KAZOO app)
•Multi-level policy based – flexible from system to individual device level
•Universal and expandable
What we are going to do in near future
IDEAS WORTH sharing
Built-in CNAM provider app
•Built-in CNAM database SERVER as KAZOO application
•CNAM lookup callflow module
•CNAM lookup chain management
XMPP integration
•XMPP server integration (MongooseIM)
•Integrated presence
•MyBuddy-like bot
User profile data management
•Container and API for user profile data: avatar, manager, contacts, etc
•Special callflow modules like "call user's manager", "call user's mobile
contact" etc.
•Active Directory connector app for Windows Servers / LDAP connector
BW emulation (yes, we
dare)
•BW API emulation app
•BW features for devices
Built-in DNS server
•System-integrated GEO-IP enabled smart DNS server
•Proper DNS balancing for SBC nodes
•Serving proper DNS records for SIP/XMPP: NAPTR, SRV records,etc.
Have an idea?
Bring it on!
What we face daily
Challenges
Learning curve
•Source code serves as the primary documentation
• Use the source, Luke!
• RTFC (code), repeat
•Kazoo is a big, complex system
Bugs
•There are bugs caused by high development pace
•We have to have QA and maintain our own stable builds (and do it for
our clients)
Community Engagement
•We wish for a tightly integrated partner program with 2600hz
Community
• Improved interactions and response times
• Create formal community policy
• Moderators and gurus available via community
Community is Important!
Features cost money to design, build,
document, test, support, maintain.
(Remember: Kazoo is a big, complex
system!)
This is often misunderstood.
We can leverage the community to help
financially and via contributions of time for
each of these phases.
Consider contributing to the
project!
What we dream of
OUR GOALS
Goals to achieve
•Our goal, in conjunction with 2600hz, is to be the most amazing KAZOO
integrator/developer/support provider
•To offer best 3rd party premium components and applications KAZOO
(for advanced users/SPs) on the market
•To constantly improve the KAZOO system and contribute
patches/features/applications to the open source version
KAZOO is great.
Big, complex and great.
We are here to
help you use it for your business
Thank you!
SIPLABS LLC.,
4a, Inzhenernaya str., suite 231
Novosibirsk
Russia
630128
info@siplabs.ru
+7(383)363-2111
Skype: siplabs
