Asterisk Server Security – SIP security

If your SIP server is exposed to internet. Then you need to take some measure even if you have fail2ban installed. Fail2Ban keep track of the logs while blocking the attacks and some of the attacks might occur while fail2ban start jump into it.

Following are the Tools used for that;

  1. sipsak
  2. sipvicious
  3. iWar
  4. sip-scan
  5. sipcli
  6. friendly-scanner
  7. VaxSIPUserAgent
  8. sundayddr

you can block these attacks by using IP Tables. Following is the example for one the attack to block;

iptables -I INPUT -j DROP -p udp –dport 5060 -m stringstring "sip-scan" –algo bm


Ref: Haroon Javed

CUCM – Conference – Ad Hoc Conference

CUCM Conference Ad Hoc Conference

Unlike the Meet-Me conference, the ad hoc conference is started by an initiator and only the initiator of the conference can add people into the conference.

There are two methods to use in order to initiate ad hoc conferences:

  • Put a call on hold, dial another participant, and conference additional participants.
  • Join established calls by using the Select and Join softkeys Use the Conference Softkey for Ad Hoc Conference

The conference controller controls ad hoc conferences. When you initiate an ad hoc conference, CUCM considers you the conference controller. In an ad hoc conference, only a conference controller can add participants to a conference. If sufficient streams are available on the conference device, the conference controller can add up to the maximum number of participants that is specified for ad hoc conferences to the conference.

Configure the maximum number of participants for an ad hoc conference in CUCM Administration under CUCM Service Parameters Configuration by using the Maximum Ad Hoc Conference service parameter setting.

The default value for this Clusterwide Service Parameter is 4. If you have more than 4 participants in the conference, you need to change the default value for this service parameter to allow all the participants to join the conference. CUCM supports multiple, concurrent ad hoc conferences on each line appearance of a device. For example, phone 2001 dials 2002. The phones want to add 2003 into their conversation. 2001 presses the conference button and dials 2003. When 2003 answers, the confrn button is pressed again in order to add 2002 and 2003 into the conference.

Conference by Using Join Softkey: The user initiates an ad hoc conference by using the Select and Join softkeys. During an established call, the user chooses conference participants by pressing the Select softkey and then the Join softkey. This makes it an ad hoc conference. Up to 15 established calls can be added to the ad hoc conference, for a total of 16 participants. CUCM treats the ad hoc conference the same way as one that is established by using the Conference softkey method.

Note: You cannot be the only person in an ad hoc conference.

Note: There must be either hardware or software conference resources available before you can use any conference features. By default, the CUCM has a software conference bridge configured that can be used. In order to configure a hardware conference bridge, refer to Configuring and Using a Hardware Conference Bridge with Cisco Call Manager and a Catalyst 6000 WS-X6608 Port.

The Cisco Hardware Conference Bridge supports the Cisco Catalyst 4000 and 6000 Voice Gateway Modules and these conference sessions:

On the Cisco Catalyst 6000—In a G.711 conference, there are 32 available streams. Up to 10 conference sessions with three participants in each conference or one conference session with 32 participants.

On the Cisco Catalyst 4000—In a G.711 conference, only 24 conference participants are allowed. A maximum of four conferences with six participants each.

For the Cisco Software Conference Bridge—The maximum number of audio streams is 128. With 128 streams, a software conference media resource can handle 128 users in a single conference, or the software conference media resource can handle up to 42 conferencing resources with three users per conference.

Note: Although a single software conference bridge can run on the same server as the CUCM service, Cisco strongly recommends against this configuration. If you run a conference bridge on the same server as CUCM Ad Hoc Conference Settings CUCM Administration provides the Clusterwide Service Parameter, Drop Ad Hoc Conference, to allow the prevention of toll fraud (where an internal conference controller disconnects from the conference while outside callers remain connected). The service parameter settings specify conditions under which an ad hoc conference gets dropped.

Perform these steps to configure the Drop Ad Hoc Conference parameter:

From CUCM Administration, choose Service > Service Parameters. Choose the server from the server drop-down list box, and choose CUCM from the service drop-down list box.

1. From the Drop Ad Hoc Conference drop-down list box, which is listed in the Clusterwide Parameters (Features – General) area of the window, choose one of these options:

2. Never: The conference is not dropped. (This is the default option.) When No OnNet Parties Remain in the Conference: The system drops the active conference when the last on-network party in the conference hangs up or drops out of the conference. CUCM releases all resources that are assigned to the conference. When Conference Controller Leaves: The active conference terminates when the primary controller (conference creator) hangs up. CUCM releases all resources that are assigned to the conference.

3. Click Update. Note: CUCM does not support multiple options; that is, all conferences support the same functionality dependent upon the option that you choose.

Ref: Cisco

CUCM – Applications

Cisco Unified Communications Manager – Applications

The choices in the drop-down list box include the following Cisco Unified Communications Manager applications:

Cisco Unified Communications Manager Administration

Shows the default when you access CUCM. Use Cisco Unified Communications Manager Administration to configure system parameters, route plans, devices, and much more.

Cisco Unified Serviceability

Takes you to the main Cisco Unified Serviceability window that is used to configure trace files and alarms and to activate and deactivate services.

Cisco Unified OS Administration

Takes you to main Cisco Unified OS Administration window, so you can configure and administer the CUCM platform. You must log off from any other application before you can log in to this application.

Disaster Recovery System

Takes you to the Cisco Disaster Recovery System, a program that provides full data backup and restore capabilities for all servers in a CUCM cluster. You must log off from any other application before you can log in to this application.

After you log in to Cisco Unified Communications Manager Administration, you can access all applications that display in the Navigation drop-down list box, except the Cisco Unified Operating System Administration and Disaster Recovery System, without needing to log in to each application. You cannot access the Cisco Unified Operating System Administration or Disaster Recovery System GUIs with the same username and password that you use to access Cisco Unified Communications Manager Administration. To access these applications from Cisco Unified Communications Manager Administration, you must first click the Logout button in the upper, right corner of the Cisco Unified Communications Manager Administration window; then choose the application from the Navigation drop-down list box and click Go.

If you have already logged in to one of the applications that display in the Navigation drop-down list box (other than Cisco Unified Operating System Administration or Disaster Recovery System), you can access Cisco Unified Communications Manager Administration without logging in. From the Navigation drop-down list box, choose Cisco Unified Communications Manager Administration and click Go.

 

KAZOO – Features v4

It’s been a long time coming. We know we’ve been somewhat silent about all the work we’ve been doing for the past several months… but that’s because we’ve been hard at work for almost 18 months on Kazoo 4.0. Now we’re ready to share this great milestone with you!As part of this release, we’re trying to do a better job communicating changes and release dates. This email represents a “heads up” on all the new major features, bug fixes and backend improvements coming out in Kazoo 4.0. Open-source users should feel free to begin testing the new changes in 4.0 now (some of you already have). We are eager to hear your feedback and squash any bugs you may find! Make sure to include the specific build/package number you are on. Also, for those waiting for installation instructions that are step-by-step, we’re still polishing those but will release those as soon as they are ready, hopefully before KazooCon.
We will go into full detail about the release on stage at KazooCon, so if you haven’t already purchased your ticket, we encourage you to check it out – www.kazoocon.com!. In the meantime, here’s what to expect with the 4.0 rollout. If you have questions or want to discuss these items more click here, and check out our 4.0 announcements! 

BACKEND

Functional and Performance

Couch Connector – Enhancement

What’s New:
We have made a major enhancement which lays the framework to allow Kazoo to connect to more than one database at a time, and to connect to different types of databases. This framework is utilized by other new features coming out, enabling new functionality and control over your database architecture. This also prepares Kazoo to officially use the upcoming CouchDB 2.0 software, which has a number of bug fixes and improvements.

How does it impact you:
This change should be transparent unless you are a developer, in which case you’ll need to review the new modules for Couch Connectivity (previously called couch_mgr, now known as kazoo_data library).

Couch Connector – Data Plans

What’s New:
Data plans allow you to configure where your system’s data is stored. It utilizes the new Couch Connector framework for connecting into multiple databases. It then allows you to setup “plans” where you can split data across different databases by data type (i.e. voicemail, call recording, etc.), by user (i.e. user A is on database A, user B is on database B), by zone (i.e. user C is in the New York cluster and user D is in the San Francisco cluster) and so on.

How does it impact you:
If you wish to take advantage of data plans to use alternate databases, you will need your Amazon, Google Drive or BigCouch cluster credentials/authentication keys. This is often in the form of OAuth authentication/permission. A UI component and APIs are not yet available for configuration, but you can follow the instructions on our documentation page to configure this manually and try it out.

External Storage Engine – Amazon S3

What’s New:
We have built support to utilize Amazon S3 as a storage provider (in conjunction with the new Couch Connector features). The engine allows you to configure a different Amazon S3 account and folder for each type of item stored, on a per-user, per-account, per-reseller or system-wide basis.

How does it impact you:
Kazoo Admins and Resellers will need to decide on a strategy for signing up and maintaining Amazon S3 accounts for either all customers, or a single sign-up that has permissions across their customers, or similar variations. In addition, customers are solely responsible for managing the keys and credentials for the Amazon S3 service and inputting them into Kazoo.

External Storage Engine – Google Drive

What’s New:
We have built support to utilize Google Drive as a storage provider (in conjunction with the new Couch Connector features). The engine allows you to configure a different Google Drive account and folder for each type of item stored, on a per-user, per-account, per-reseller or system-wide basis.

How does it impact you:
Kazoo Admins and Resellers will need to decide on a strategy for signing up and maintaining Google Drive accounts for either all customers, or a single sign-up that has permissions across their customers, or similar variations. In addition, customers are solely responsible for managing the keys and credentials for the Google Drive service and inputting them into Kazoo.

Number Manager Rewrite

What’s New:
The number management sub-system within Kazoo has been re-written to massively improve performance and stability for accounts which have 10,000 phone numbers in a single account, and for systems that have a collective total of over 1,000,000 numbers. The performance improvement will be perceived when doing number operations, especially bulk operations such as importing batches of numbers or deleting numbers.

How does it impact you:
Customer accounts will be migrated automatically the first time a phone number is modified (added/deleted/updated) within a single account. The automation will change the structure of the phone number documents within an account and on the global number database. This strategy ensures backward compatibility with the old structure, avoids risk at doing a mass-migration and avoids downtime. Please note that once an account has been upgraded to the new format, you can not downgrade to v3.xx of Kazoo.

Performance – Conditional Document Change Suppressions

What’s New:
Every time a document is updated in Kazoo, we publish a message that a document has been created/deleted/updated. We use these for self-flushing caches and Webhooks, etc. However, for certain notifications, they’re not useful and yet we’re still publishing them. Now, in the Erlang code and in system_config, you can select which Doc Update/Change notices go out to AMQP and which are suppressed (to avoid chatter on the message bus).

How does it impact you:
If someone has created a custom app that uses document change notices and is reliant on particular messages Kazoo produces, the customer must validate that those messages are still published and their app behaves the same way after upgrading to 4.0.

Performance: Cache Optimization Work

What’s New:
Every cache used to have an ETS table. We cache pointers, watchers and the object itself in the same cache. Because all three items were in the same cache, sometimes the cache itself would back up. We’ve changed Kazoo cache to comprise of three ETS tables – one for pointers, one for watchers and one for objects themselves. This makes it so we can reference everything by key and not search the caches anymore. This makes EVERYTHING much faster on large systems.

How does it impact you:
The cache changes have a dramatic performance impact on clusters with over 10k phones.

Voicemails Moved to Modb

What’s New:
Voicemails used to be stored in the same location as configuration settings. Accounts older than 12 months would often get too big, thus this became a design issue. Voicemails have now been redesigned so that the messages are stored in a monthly database that can be purged later.

How does it impact you:
All new voicemail messages goes into modb. All Kazoo Administrators need to migrate their voicemail messages from 3.22 to modb.

Account-Level Debug Mode

What’s New:
On highly active systems the default logging strategy is too busy. With this change the default log level can be reduced. Accounts experiencing trouble can have their individual levels increased for debugging.

How does it impact you:
There is no preparation required to take advantage of this improvement.

iBrowse Removed

What’s New:
In order to issue HTTP requests Kazoo and some of the Kazoo dependencies used a third party library called iBrowse. This library did not maintain backward compatibility so there wasn’t an upgrade path readily available. This resulted in Kazoo being stuck with a number of significant bugs in iBrowse which occasionally impacted call processing. In 4.0 iBrowse has been completely removed and a more stable HTTP client sanctioned by the core Erlang team is now utilized.

How does it impact you:
This upgrade prevents customers with CNAM lookups or heavy database usage from experiencing a partial outage. In addition, developers who previously coded using iBrowse should now switch to using kz_web module.

Data Structure

Support for over 1,000 numbers on a single account

What’s New:
Phone number storage has been enhanced to support a large quantity of numbers on a single account.

How does it impact you:
There is no preparation required to take advantage of this improvement.

Support for resellers to have their own phone number inventory

What’s New:
Resellers can now manage their own inventory of numbers.

How does it impact you:
There is no preparation required to take advantage of this improvement.

Ability to search the number inventory based on carrier as well as search for additional inventory

What’s New:
Massively enhanced the number search reservation and provisioning capabilities to support private number inventories and an infinite amount of secondary providers.

How does it impact you:
There is no preparation required to take advantage of this improvement.

Configuration

Kazoo core config file cleanup

What’s New:
The three global Kazoo configuration files in /etc/kazoo have been moved to /etc/kazoo/core.

How does it impact you:
After installing kazoo-config-core you will need to move the three files (which will be marked as .rpmsave) into /etc/kazoo/core.

Dispatchers list

What’s New:
Kamailio is responsible for distributing and load-balancing SIP packets to all nodes in a cluster. This distribution is configured with a database engine that tracks which nodes are in the cluster. In 4.0, we have upgraded to a more performant configuration engine. This change also corrects memory consumption issues and allows Kazoo to query the configured dispatchers list easily. Because of this change, the Kamailio dispatcher file format has also changed. It is now consistent with the formatting used by other files in the dbtext folder.

How does it impact you:
After installing kazoo-config-kamailio you will need to covert /etc/kazoo/kamailio/dbtext/dispatcher to the new format.

Management

Sup Commands

What’s New:
Our System Utility Program (SUP) utilized commands which used our old product name, Whistle, or wh in some cases for short. Beginning with 4.0 we have changed these commands to be consistent with the name ‘Kazoo’. Commands that contained wh have been shortened to k (such as kapps_controller). Additionally, the ability to use the -h argument and connect to machines remotely via SUP has been removed.

How does it impact you:
If you were using sup remotely you will no longer be able to and you will have to adapt any scripts that utilize sup to match the new command names. System admins will need to learn the new sup commands.

Requiring upgrade to CentOS7

What’s New:
CentOS6 is scheduled to stop receiving full updates Q2 of 2017. to ensure the highest level of reliability of our platform, 2600Hz will require CentOS7 so that Kazoo Administrators can continue receiving updates and security fixes in a timely manner.

How does it impact you:
The transition to CentOS7 also introduces the use of systemD which admins should prepare for.

Packaging

New RPM Repo

What’s New:
In order to support both Debian and CentOS, we needed to rebuild our packaging and automated release systems. However, we realize some users will still need access to the older packages for a while. To achieve both goals, we’ve created a new package repository for 4.0 packages (for both Debian and CentOS) but will also retain the old package repository for some time to come. Anyone moving to 4.0 should be aware of the new repository.

How does it impact you:
Kazoo Administrators will want to make sure they remove the old repo file and install the new one so the right packages are used.

Shipping both Debian & CentOS packages.

What’s New:
2600Hz is preparing to support both Debian and CentOS packages starting with Kazoo 4.0. We will continue supporting ONLY CentOS for paid clients as we start testing the feasibility of moving to Debian reliably.

How does it impact you:
Feel free to use either Debian or CentOS.

Freeswitch 1.6

What’s New:
2600Hz will stop maintaining custom FreeSWITCH packages. All patches we have done have been back-ported into FreeSWITCH 1.6. We will now utilize FreeSWITCH’s repository for all packages. This allows us to stay up to date with the developments in the FreeSWITCH project, including new features and bugs.

How does it impact you:
Make sure you use FreeSWITCH’s packages going forward and have their repo on your system.

Kamailio 4.4

What’s New:
2600Hz will stop maintaining custom Kamailio packages. All patches we have done have been backported into Kamailio 4.3. We will now utilize Kamailio’s repository for all packages. This allows us to stay up to date with the developments in the Kamailio project, including new features and bugs.

How does it impact you:
Make sure you use Kamailio’s packages going forward and have their repo on your system.

Individual Kazoo Apps

What’s New:
We will now package and ship all Kazoo applications as individual packages. This allows Kazoo Administrators to install, maintain and upgrade packages individually rather then ship all items together, and better exposes the modular capabilities of our system.

How does it impact you:
These benefits will be automatically realized when you upgrade to 4.0.

Requirement for Erlang 18 (not 19!)

What’s New:
We now require Erlang 18 (not 19!) for running Kazoo.

How does it impact you:
These benefits will be automatically realized when you upgrade to 4.0.

Erlang Releases-new packaging system

What’s New:
Kazoo is now an executable release, utilizing the Erlang release/package system. This means that the correct version of Erlang’s binaries comes with our software.

How does it impact you:
You no longer need to worry about what version of Erlang is installed on the machine. Kazoo will start with the correct version that is shipped with the Kazoo core. This behavior is similar to an executable binary.

International Language Packs

What’s New:
Kazoo now ships language prompts (sound files) as separate packages, per language. This allows you to install one or more languages of your choosing on your system and avoid installing extra languages you don’t need.

How does it impact you:
These benefits will be automatically realized when you upgrade to 4.0.

First compilation now requires internet connectivity to download dependencies

What’s New:
The first time you compile Kazoo applications, Kazoo will automatically attempt to download dependencies via the internet.

How does it impact you:
This means users who are compiling modules in Kazoo need to make sure they have internet access the first time they do this.

Call Recordings

Call Recordings

What’s New:
Call recordings existed in v3 but required additional effort from resellers to handle storage of the recordings. Most users found this cumbersome. 4.0 introduces the ability to easily enable call recordings and track all call recordings in CDRs. Each CDR points to the call recording for easy lookup and retrieval. The recordings themselves can be placed on an external storage engine, such as Amazon S3, making it easier for people to manage the recordings.

How does it impact you:
You must bring your own storage engine and configure this to use it.

Multiple call recordings per call

What’s New:
Sometimes, on a long call, users wish to start and stop recordings mid-call but still have a single file result at the end of the call. In addition, calls which are transferred between callers are expected to remain in a single file. We have upgraded the system to support storing multiple parts of a call in a single file.

How does it impact you:
There is no preparation required to take advantage of this improvement.

CDRs

Added interaction ids and Listed CDRs, now shown as calls

What’s New:
Kazoo has always delivered multiple records for every call because it creates a CDR for each leg of a call. This can be challenging to program for if you are a developer, and can confuse users. It also makes it challenging to understand what happened during a call. We are introducing a concept called “Interaction IDs” to solve this. Interaction IDs allow you to get a unified view of all calls in the system. You can drill down to the previously available detail about each call leg once you’ve located the interaction ID (call) of interest.

How does it impact you:
There is no preparation required to take advantage of this improvement.

RabbitMQ Enhancements

Clustering Rabbit over the local LAN

What’s New:
Kazoo now supports the initial attempt at redundant RabbitMQ clusters (on the local LAN). This solves the last remaining hurdle of full redundancy within a single zone. Using RabbitMQ’s built-in clustering, clusters can be configured to be aware of multiple AMQP nodes and Rabbit itself can use it’s built-in clustering to improve redundancy.

How does it impact you:
This solves the last full redundancy requirement for the stack. Enabling this and properly configuring all other components means the system is fully redundant in every level of the stack and should failover automatically. More testing is needed here, so please feel free to play with this.

Kamailio

TLS / SRTP

What’s New:
We are now configuring TLS and SRTP support out of the box. We will soon also utilize “letsencrypt.com” to auto-generate certificates. This will help with configuring and utilizing SRTP encryption and WebRTC services.

How does it impact you:
There is no preparation required to take advantage of this improvement.

HTTP / HTTPS

No more options pings on API calls (Preflight)

What’s New:
As typically deployed, the web UI communicates to a Kazoo API server. The two URLs to do this are not necessarily on the same domain. This causes browsers to send an OPTIONS pre-flight request which significantly slows down the UI. Through new deployment procedures, we are eliminating these extraneous requests.

How does it impact you:
There is no preparation required to take advantage of this improvement.

Tasks API

General

What’s New:
A major feature enhancement was added to 4.0 which allows for generic background processes to be queued across a cluster. This feature represents a framework for adding background jobs to a queue and then popping them off, processing them and returning the results. Individual APIs can now be built that take advantage of this queueing mechanism.

How does it impact you:
There is no preparation required to take advantage of this improvement.

Jonny5 / Ecallmgr / Call Rating & Limits

Community contribution to disconnect calls when the credit is exhausted

What’s New:
Kazoo’s ecallmgr can now be configured to continuously validate that active calls consuming per minute credits still have funds available. If the funds are exhausted the channel will be killed in the middle of the call.

How does it impact you:
By default per minute usage is debited from the account at the termination of a call and a long call could result in a negative balance. By checking proactively – this is avoided. This feature is community supported only (not supported by 2600Hz).

Carrier Management

Bandwidth 2 Carrier Edition

What’s New:
Bandwidth.com has stopped using the old API subsystem on my.bandwidth.com, which we used to rely on. This required re-coding the bandwidth.com module which allows for searching and purchasing of phone numbers. The new bandwidth API for purchasing and searching for numbers provides better service from the customer’s perspective and allows us to continue supporting this provider.

How does it impact you:
You’ll need to reconfigure the wnm_bandwidth module to use wnm_bandwidth2 on the database backend and enter new credentials / API keys for the new bandwidth.com dashboard.

Voip Innovations Carrier Edition

What’s New:
2600Hz has added backend support for VoIP Innovations as a carrier module. This allows Kazoo Administrators to search, buy numbers, configure E911 and manage settings for numbers on a VoIP Innovations wholesale account, through Kazoo.

How does it impact you:
You’ll need to reconfigure the wnm_bandwidth module to use wnm_voipinnovations on the database backend and enter new credentials / API keys for the new bandwidth.com dashboard.

APIs

Voicemail enhancements

What’s New:
Sometimes a customer’s voicemail box fills up erroneously, usually because it is misconfigured (but sometimes because the voicemail to email application is having an issue sending emails, in which case the voicemails are retained). This requires clearing out the voicemails in the mailbox later, which is tedious. This enhancement introduces the ability to clear a voicemail box all at once.

How does it impact you:
There is no preparation required to take advantage of this improvement.

HTTPS for all

What’s New:
We are now including HTTPS support as the default strategy for all interactions with Kazoo. Soon, we will sunset support for raw unencrypted HTTP requests.

How does it impact you:
You should switch your application to use HTTPS if you are calling our APIs directly.

WARNING: we have changed a lot in the numbers API

What’s New:
The phone numbers API was updated heavily. A lot of work was put into getting the new number manager to “speak” the same API as the old API used to. However, it’s possible 100% backward compatibility has not been obtained. Mishaps may occur.

How does it impact you:
If you have done your own integrations to our number manager, you should test APIs for phone numbers to be sure they work as expected. Most of the changes are in the DB storage mechanism and should be transparent but this will not be code we can roll back once it’s out, so please proceed with caution.

BUG FIXES

Callflows

On-net CDR fixes (loopback)

What’s New:
Kazoo now properly logs CDRs when calling between accounts on the same system. Previously, the CDR would only be in a single account.

How does it impact you:
There is no preparation required to take advantage of this improvement.

On-net authz fixes (loopback)

What’s New:
Kazoo now properly authorizes calls when calling between accounts. This allows billing to work properly when calling between accounts on the same cluster.

How does it impact you:
There is no preparation required to take advantage of this improvement.

On-net T.38 fixes

What’s New:
Kazoo now properly handles fax calls between two T.38 devices on the same cluster.

How does it impact you:
There is no preparation required to take advantage of this improvement.

On-hold music fixes

What’s New:
You can now transfer calls to your clients/across accounts and the correct on hold music plays for the right account when calling between accounts.

How does it impact you:
There is no preparation required to take advantage of this improvement.

Kamailio

Resolve contact string at Kamailio reducing the load on ecallmanager.

What’s New:
Previously, every phone which made a call would be asked for the phone’s username/password. This occurred on each call. The process of doing this can take 50-150ms in some cases, which slows down call setup times. In addition, the backend systems would have to re-check the password for a phone even though we already know the phone’s IP and port and know it’s authorized. Now, we don’t challenge already registered phones if the INVITE comes from the same IP and port as a previous call. This improves performance on things like park/transfer. This also reduces all call setup time and reduces post dial delay.

How does it impact you:
There is no preparation required to take advantage of this improvement.

WebRTC Support

What’s New:
We now properly lookup and address WebRTC clients when calling inbound. This will help ensure WebRTC connectivity when calling to WebRTC users.

How does it impact you:
There is no preparation required to take advantage of this improvement.

General

Forgot password update–now sends a link to actually reset password

What’s New:
The forgot password button previously reset a password on the fly and emailed the new password. Malicious users could submit false password requests that required no confirmation. The system has been updated to work more like other systems where an email with a token/link is sent first to confirm the user really requested the password reset, and then the password is reset once the link is clicked on.

How does it impact you:
You’ll need to make sure the new forgot password templates are updated.

Konami

Konami code for audio levels-adjust your speaker volume or mic sensitivity

What’s New:
The older version of Konami received an update that allows keypresses to adjust the volume level or mic sensitivity when mid-call.

How does it impact you:
You’ll need to be running Konami.

APIs

Blacklists

What’s New:
We have had blacklists for a while, but they have not had a way to handle Anonymous Caller IDs on inbound phone calls. Now the blacklist app will not attempt to try to normalize an anonymous caller ID, which means that blacklisting “all zeros” (anonymous caller ID) will now work correctly.

How does it impact you:
If you are using the blacklist APIs, you can now block anonymous caller IDs.

Validate type of document being posted

What’s New:
Previously, an issue existed where the API would not validate the pvt_type you submitted against the existing document. This means that if you were trying to update a voicemail box via the API, but accidentally passed in the document ID of something else (like the account or user), the system would happily accept the update – and break the corresponding document/feature you incorrectly specified. While this error is caused by the user/developer, Kazoo has been upgraded to be stricter about enforcing the pvt_type stays the same so that this error can’t be made accidentally.

How does it impact you:
If you are using our APIs from your own scripts, you should be aware of this validation in case you somehow cause an error by trying to change the pvt_type (although you should never do that anyway, so it just means you should fix your code).

VoIP in a Cloud

(This is the first of a two-part series on using Amazon’s cloud services to meet your business telephony needs. In this part, we look at Amazon EC2 and how it is used in a VoIP setting. In Part 2, we’ll cover all the steps necessary in getting the open-source Asterisk PBX to work on Amazon’s cloud.) 
2004_04_10-012-1280
Businesses looking to upgrade their telephony systems to more cost-effective and powerful IP-based PBXes generally limit their choice to two approaches: in-house and out-sourced.

An in-house solution is often more powerful, gives the business much more control, is more secure and is less costly on an on-going basis to  maintain. On the down side, an on-premise PBX, however, requires some specialized knowledge, is tricky to scale as your needs grow and requires a significant up-front investment.

An out-sourced service, often called a “virtual PBX,” is much easier to use and manage, can easily scale and costs less up front. The trade-off comes in the form of reduced customizability and significantly higher on-going costs.

With the recent growth in use of cloud computing, internet based pools of servers that can be dynamically configured to meet a businesses variable needs (i.e.: an office telecommunications system gets much greater use during business hours than on a weekend), an interesting third option for the office PBX has developed.

Why would I want to run my server in the cloud?

Cloud computing has lower upfront capital costs.  Rather than spend a few thousand dollars on a Dell server that will take weeks to arrive and days to configure, you can configure a virtual machine in the cloud, pay for the server as you use it, and be up and running in under an hour.

As an example, imagine a retailer planning for the 2008 holiday season by ordering new servers to handle the expected holiday call volume.  Due to the economic downturn, 2008  holiday sales where down significantly — and those servers ended up sitting idle.

If the retailer had used the cloud, servers could have been added or removed on the fly as needed to cover the actual call volume.

Probably the best-known of the cloud services is Amazon EC2, an innovative and useful offering by the web retail giant that offers an interesting way to greatly reduce  phone system and telephony application server costs.

What is Amazon EC2?

The Amazon Elastic Compute Cloud (Amazon EC2) is a virtual machine web service that provides dynamic resizable compute capacity in the cloud.  Amazon EC2 provides a virtual computing environment,enabling an easy increase or decrease in capacity within minutes.

Need more voice channels, for the holiday rush?  Turn on another virtual machine instance.  Less calls after business hours, turn off an unneeded virtual machine instance.  The process can even be automated with the EC2 API, and the servers can figure out when they should shut down or add another instance.

Regions and availability zones

Amazon EC2 instances can run in multiple locations.  Amazon EC2 locations are divided into Regions and Availability Zones.

Amazon EC2 is available in two regions — the US and Europe —  each consisting of one or more Availability Zones, distinct locations insulated from failures in other similar server locations.

Launching instances in separate Availability Zones can protect your system from a failure in a single location.   The Amazon EC2 Service Level Agreement commitment is 99.95% availability for each Amazon EC2 Region.

By setting up redundant instances closer to your physical location, you significantly reduce call latency.

Instance types

Amazon offers a variety of instance types.   Until you know how your setup will perform, the small virtual machine instance is the best place to start; it has the following performance specifications:

  • 1.7 GB memory;
  • EC2 Compute Unit (1 virtual core with 1 EC2 Compute Unit);
  • 160 GB instance storage (150 GB plus 10 GB root partition) additional storage available via Amazon EBS;
  • 32-bit platform;
  • I/O Performance: Moderate;
  • Price: $0.10US ($0.11EU) per instance hour.

One EC2 Compute Unit is roughly the equivalent of a high-end computer purchased three years ago. By optimizing certain parameters (i.e.: transcoding, which we’ll cover in more detail Part 2), this is plenty of firepower to handle the needs of 50 or more employees working in multiple locations.

Data transfer

The beauty of the Amazon EC2 pricing model is that there are no minimum monthly fees for the service.  You only pay for what you use.  Running a test machine for three hours costs $0.30 in the US or $0.33 in Europe,  or less than $80 a month.

The Internet data transfer rates are also reasonable.  Inbound data costs $0.10 per GB/month and outbound data costs $0.17 per GB for the first 10TB/month.  Data transfer between two Amazon Web Services within the same region is free of charge. Be aware that voice media traffic is generally two-way, traffic in and out of Amazon EC2.  To keep data transfer costs down, when possible, route RTP traffic between end-points (we’ll show you how in Part 2).

Before choosing Amazon EC2, compare your dedicated hosting bandwidth usage and costs with Amazon EC2′s costs.  Unlike some hosting providers with capped bandwidth and excessive overage charges, the Amazon EC2 has no bandwidth caps or overage charges.  Amazon offers a calculator tool to estimate your monthly costs.

Elastic Block Store (EBS)

Until recently, Amazon EC2 didn’t offer persistent disk storage.  If an instance was shut down, the data was lost, unless it was backed up into Amazon S3 or off-site.  Most telephony platforms don’t have support for Amazon S3 and this storage limitation was an impediment to using Amazon EC2 service for the storage of call logs and voice mail.  Amazon addressed the storage limitation with Amazon Elastic Block Store (EBS).

Amazon EBS provides block level storage volumes for use with Amazon EC2 instances. Amazon EBS volumes are off-instance storage that live independently from the life of an instance.  Shut down an instance, start a new one, reattach the storage and your data is still there, like a removable hard drive.

You create a volume, specify the size, then mount the volume on your server.  Each volume can be 1GB-1TB in size and a single instance can have multiple volumes mounted.  Voice mail and log storage can easily scale.  Need more space? It’s as easy as adding another volume.  It’s an ideal approach for those who never delete voicemail or want their voicemails back after they delete them.  Voice mail and log volumes can also be separated for improved performance.

Amazon EBS also provides the ability to create point-in-time snapshots of volumes, which are stored in Amazon S3. These snapshots can be used to protect data for long-term durability.

Volume storage is charged by the amount you allocate until you release it, and is priced at a rate of $0.10 US ($0.11 EU) per allocated GB/month.  Amazon EBS also charges $0.10US ($0.11EU) per 1 million I/O requests you make to your volume.

Elastic IP Addresses

Another early complaint about Amazon EC2 was that the IP address and hostname of an instance was never the same. This was problematic because whenever an instance was shut down and a new one turned on, the hostname and IP address would be different.  For many applications, this added an extra burden and users had to implement a variety of DNS workarounds.
Amazon addressed this problem with Elastic IP address.  You can now get and keep an IP address and assign it to any one of your instances.  If your telephony server instance goes down, you can bring up a new one and assign the existing IP address to the new server.  There’s no need to update configuration files, track down hard coded IP addresses, or modify DNS records.
Elastic IP addresses are free while they are assigned to an instance.  To prevent wasted IP addresses, Amazon charges for $0.01/hour for unassigned IP addresses.

VoIP – Kazoo 2600HZ – debugging – no servers available in group 1 or 2

After Kazoo 2600hz install if you are getting errors while making calls even extension to extension

———–

ERROR: dispatcher [dispatch.c:1262]: ds_get_index(): destination set [2] not found

ERROR: dispatcher [dispatch.c:1660]: ds_select_dst_limit(): destination set [2] not found

WARNING: <script>: |end|no servers avaliable in group 1 or 2

———-

this is in most cases due to either wrong configuration on freeswitch nodes in dispatcher or wrong entry/missing entry in db

check using command

1) sup -n ecallmgr ecallmgr_config get fs_nodes

are you getting list of all freeswitch nodes, in not then add them usign following command for each freeswitch node

2) sup -n ecallmgr ecallmgr_maintenance add_fs_node freeswitch@fs-hostname

now check again using command (1) if all ok. then run follwoing commands to reload services

epmd -daemon

service freeswitch restart

chkconfig freeswitch on

epmd -names

 

then try again , issue should be fixed

 

VoIP – Kazoo 2600HZ – troubleshooting – kazoo-ui module not working

kazoo-ui module not working

Try ‘sup whapps_maintenance migrate’

It will walk all the databases and make sure everything is up to date. Typically you’d do this anytime you upgrade versions of Kazoo.

 

Do you have a ‘system_schemas’ database?

If not, try ‘sup whapps_maintenance refresh system_schemas’

Should build and populate the DB.

 

try:

sup crossbar_maintenance start_module cb_schemas

If that was successful, open the system_config/crossbar document in Couch and edit the list of autoloaded modules to include cb_schemas.

 

try running

sup whapps_maintenance migrate

 

Ref: Darren Schreiber + James Aimonetti ( google groups discussion )

VoIP – Kazoo 2600HZ – troubleshooting – couch_compactor_fsm failure

couch_compactor_fsm failure

if 2600hz plateform logs shows  couch_compactor_fsm failed to ping.

solution:

The compactor needs to know the cookie with which the BigCouch Erlang VM started because it needs to find out what ports BigCouch is listening on.

Some folks run on non-standard ports, so the compactor will query the node directly to discover its configured ports.

Failing to connect to BigCouch, compactor will use the ports configured in /etc/kazoo/config.ini to try compacting.

Obviously this fails in most installs because most people are using HAProxy locally on 15984/15986 instead of 5984/5986.

The cookie value in the system_config/whistle_couch doc should be set the whatever the cookie value in /etc/kazoo/bigcouch/vm.args is, as that’s the cookie value the BigCouch VM is running with.

The [bigcouch] cookie value is used to initialize the system_config/whistle_couch entry, but is otherwise unused.

If your BigCouch nodes are running with ‘couch_cookie’ (or whatever it actually is) as their cookie, and you cannot ping that node, check firewall rules to make sure traffic from the apps server can reach the BigCouch server.

It will ping bigcouch@bigcouch1.server.com or whatever the hostname of the server is. You can test this yourself by starting an erlang VM on an apps server and trying to ping BigCouch:

erl -name foo -setcookie {bigcouch_cookie}

1> net_adm:ping(‘bigc…@bigcouch.server.com‘).
pong

If you see ‘pang’, something is blocking communication between the two servers. Check IPTables or similar on the BigCouch server.

Ref: James Aimonetti ( google groups answer)