Sprint Review 16.10

Posted on Mon 08 August 2016 in XiVO IPBX by sduthil • Tagged with XiVO, development

Hello XiVO community! Here comes the release of XiVO 16.10!

New features in this sprint

XiVO Client: There are currently three ways of starting a transfer in XiVO: from the key on your phone, by dialing *1 or *2 during the call, or from the XiVO Client. In the latter case, there was no way to complete or cancel the transfer from the XiVO Client since the xlet Contacts was replaced with the xlet People. You could complete the transfer by hanging up your phone, but cancelling a transfer was simply not possible at all, since dialing *0 during the call has no effect for transfers started from the XiVO Client. This problem is now fixed by the addition to the xlet Identity of two new buttons: complete and cancel a transfer.

The new buttons of the xlet Identity

REST API: Some restrictions of the current API of users and phones has been lifted: it is now possible to have one user with multiple phones on the same (or multiple) numbers. The main goal is to allow users to associate their different phones (physical phone, softphone or mobile) with the same phone number so that they all ring at the same time. Until now you had to create a group of users, and each user had only one phone. This new feature makes simple multi-phones configuration easier, but you can't (yet) choose a ring strategy like groups: all the phones will ring in the same time or not at all. The different phones may also have their own number, so a user may now have one number per phone. Again, this was already possible but somewhat cumbersome. Most features of XiVO support this new kind of configuration, but some will only use one phone.

Technical features

Asterisk: Asterisk has been upgraded to 13.10.0

Community contributions

XiVO Client: Thanks to Marilyn "Kaalyn" Pauvert for making the xlet Identity more friendly (fr) to long user names.

Ongoing features

Multiple phones: We are working on fully supporting multiple phones for the same user. As we said above, the REST API is working, and we still need to integrate it in the web interface, but it's almost there! This is a feature we've been waiting for a long time, and it's the result of a long set of modifications we started a few years ago, so we're really glad we can finally make this step forward.


See you at the next sprint review!

Sources:


Sprint Review 16.09

Posted on Wed 13 July 2016 in XiVO IPBX by sduthil • Tagged with XiVO, development

Hello XiVO community! Here comes the release of XiVO 16.09!

New features in this sprint

Web interface: Editing a user with many functions keys now takes the same time as editing a user with no function keys. There is a noticeable performance improvement when editing users with lots (25+) of function keys.

Entities: A new API has been added to manage entities on a XiVO. Entities allow administrators to isolate multiple companies or departments on the same XiVO server, so that they may share resources like the machine itself, or phone connections with operators.

User call flow: New APIs have also been added so that users may control their current call flow, like hanging up or transferring to a third party. The XiVO Client uses those APIs under the hood, and benefits from a couple of bugfixes brought by those APIs.

Installation: Older versions of XiVO may be installed via the installation script (only the older ISO images were available until now). This is especially useful for restoring old backups, or migrating XiVO across machines.

Operators: XiVO is now compatible with operators and devices offering SS7 signalling. This allows XiVO to be used with more diverse physical interconnections.

Technical features

SCCP phones: The newer Cisco SCCP firmwares 9.4 are available for installation.

Community contributions

Monitoring: Thanks to Alexandre Lafarcinade for fixing the bug 6278 which make Monit alerts much more useful in an environment with multiple XiVO.

Installation: Thanks to Gregory Esnaud for improving the installation script so that we can install archived versions of XiVO.

Provisioning: Thanks to Jeremy Spiesser for adding support for SIP transport selection to the Yealink plugins.


See you at the next sprint review!

Sources:


Sprint Review 16.08

Posted on Mon 27 June 2016 in XiVO IPBX by sduthil • Tagged with XiVO, development

Hello XiVO community! Here comes the release of XiVO 16.08!

New features in this sprint

Provisioning: The provisioning server has been reinforced to avoid attacks allowing to discover phone credentials that would allow an attacker to start phone calls without authorization. Thank you to Jean-Loup Depoisier from the XiVO community for bringing this problem to our attention.

Ongoing features

Call Transfers: We are working on a new API for managing call transfers. This will offer third parties more flexibility when developing applications that control the call flows, such as a Web Switchboard. In addition, this new API should solve a number of bugs related to call transfers. In this iteration we continued working on a version of the CTI server that uses this new API for all XiVO Client transfers.


See you at the next sprint review!

Sources:


How we test multiple XiVO with Terraform

Posted on Mon 06 June 2016 in articles by sduthil

We are very fond of tests when developing XiVO, especially automated ones :) Currently, we have three levels of tests: unit-tests (very small), integration tests (medium size) and acceptance tests (large tests, which take a few hours to run). Acceptance tests also include manual tests, which we love hating of doing: manual testing takes us about half a day of 4 people, before each release. Of course we hate running manual tests when a machine could do it for us, so we're always wanting to automate them out.

On our journey towards the eradication of manual tests, we've encountered a quite friendly software called Terraform. It allows us to automatically deploy and configure XiVO instances, which is very helpful when testing in an almost-real environment. We'll introduce it and show you how we can deploy two XiVO with High Availability (HA) enabled, in about 250 lines of scripts and configuration.

Terraform is written in Go by HashiCorp and allows you to deploy virtual machines, containers, databases and a lot of other instances on a variety of providers.

We use OpenStack to host virtual machines, and it happens Terraform can talk to OpenStack to automatically create new virtual machines.

Who is going to glue this all together? Our trusted friend Jenkins (which you can meet on http://jenkins.xivo.io) is the perfect candidate. Here's the summary of his job:

The steps of the Jenkins job: clone, terraform, configure, test

  1. Jenkins will fetch the latest code from our Github repositories (and xivo-terraform, because tests or the deploying scripts might change
  2. Jenkins gets ready to test and swears at us for doing such a boring job
  3. Jenkins creates the configuration files for Terraform and runs terraform apply
  4. Terraform tells OpenStack to create 2 Debian virtual machines, then installs XiVO on them, which takes about 15 minutes.
  5. Jenkins finalizes the configuration of the XiVO by enabling the HA between the two machines.
  6. Jenkins may now run the automatic tests for the HA, such as verifying data replication, shutting down the master, etc.

We'll get a bit more in details of the Terraform configuration files. Here goes the main one, xivo.tf:

provider "openstack" {
    user_name = "${var.user_name}"
    password = "${var.password}"
    tenant_name = "${var.tenant_name}"
    domain_name = "${var.domain_name}"
    auth_url  = "${var.auth_url}"
}

resource "openstack_compute_instance_v2" "xivo" {
    name = "xivo-test-ha${count.index}"
    region = "${var.region}"
    image_id = "${var.image_id}"
    flavor_id = "${var.flavor_id}"
    key_pair = "${var.key_pair}"

    count = "${var.count}"

    security_groups = [
        "default"
    ]

    user_data = "${file(\"files/cloud-init.txt\")}"

    network {
        name = "${var.network}"
    }

    connection {
        user = "root"
        key_file = "${var.key_file}"
    }

    provisioner "local-exec" {
        command =  "echo ${count.index}:${self.network.0.fixed_ip_v4} >> private_ips.txt ; sleep 2"
    }

    provisioner "file" {
        source = "private_ips.txt"
        destination = "/tmp/private_ips.txt"
    }

    provisioner "remote-exec" {
        inline = [
            "wget --no-check-certificate https://raw.githubusercontent.com/sboily/xivo-terraform/master/bin/xivo_install_aws -O /tmp/xivo_install_aws",
            "bash /tmp/xivo_install_aws"
        ]
    }

}

output "ips" {
   value = "${join(\" \",openstack_compute_instance_v2.xivo.*.access_ip_v4)}"
}

Variables ${var.something} are defined in a separate file, vars.tf, looking like:

variable "count" {
  default = 2
}

variable "user_name" {
    description = "Openstack username."
}

...

What, no values? No, that's only the definition of the variables. The values are set in a third file terraform.tfvars, looking like:

user_name = "jenkins"
password = "secret"
tenant_name = "jenkins"
auth_url = "http://openstack:5000/v3"
key_pair = "jenkins"
key_file = "/home/me/.ssh/id_rsa"
network = "provider"

There are three interesting bits in xivo.tf:

command =  "echo ${count.index}:${self.network.0.fixed_ip_v4} >> private_ips.txt ; sleep 2"

This will create a file containing the IP address of the two machines Terraform created on OpenStack, looking like:

1:10.0.0.1
0:10.0.0.2

We decided 0 would be the master and 1 would be the slave. All the code we use to connect to the newly created machines rely on these two lines to know where the machines are, because the IP addresses are not fixed.

user_data = "${file(\"files/cloud-init.txt\")}"

When the machine starts, a little software called Cloud-Init will make a HTTP request to get its configuration and do some changes on the machine, such as setting the hostname, allowing SSH connections, etc. The above line tells Openstack which configuration to expose to Cloud-Init.

provisioner "remote-exec" {
    inline = [
        "wget --no-check-certificate https://raw.githubusercontent.com/sboily/xivo-terraform/master/bin/xivo_install_aws -O /tmp/xivo_install_aws",
        "bash /tmp/xivo_install_aws"
    ]
}

This script will be run after the machine is started, that will:

  • install XiVO
  • configure the wizard
  • configure the HA

Don't hesitate to take a look, it's very straightforward.


Sprint Review 16.07

Posted on Mon 06 June 2016 in XiVO IPBX by pcadotte • Tagged with XiVO, development

Hello XiVO community! Here comes the release of XiVO 16.07!

New features in this sprint

Asterisk: Asterisk has been updated to version 13.9.1

Community contributions

Tutorials: Many thanks for Ward Mundy from Nerd Vittles for creating many new tutorials for XiVO.

Ongoing features

Call Transfers: We are working on a new API for managing call transfers. This will offer third parties more flexibility when developing applications that control the call flows, such as a Web Switchboard. In addition, this new API should solve a number of bugs related to call transfers. In this iteration we started working on a version of the CTI server that uses this new API for all XiVO Client transfers.


See you at the next sprint review!

Sources: