OpenStack based WebRTC PaaS by Frafos

May 2015, José Luis Millán, Binan Al Halabi

Intro

HOWTO for implementing a simple WebRTC service, using JsSIP and OpenStack-based Frafos WebRTC

PaaS

•Background: WebRTC, PaaS•JsSIP•Openstack PaaS

Frafos Architectural Assumptions

Voice is not a target product anymore

•It is becoming an add-on for web apps.•It is easier to add a media channel to an app (like CRM) than vice versa. WebRTC does exactly that.•We integrate the business logic with media using the browser•We therefore contemplate that infrastructural VoIP will be standardized into PaaS so that application integrators won’t be concerned about VoIP.

Frafos PaaS Architecture

WebRTC

Browser

integrates

Business Logic

with VoIP

Channel

Business Apps

online shops,

customer service,

eductation,

entertainment

HTTP

WebRTC

protocol

suite

Standardized VoIP Cloud: provides SIP and

PSTN connectivity, NAT traversal, media

processing, scaling, high-availability, and

security.

Example App: Cloud Audio Conference

•Faster-to-build than any enterprise IT can: The browser application for organizing web-conferencing implemented and tested within two weeks.•Consumer-grade easy to use: three browser steps to be in conference.

Start Invite

Talk

Using JsSIP (go.areteasea.com)

Openstack-based PaaS

PaaS Objectives

•Simple integration --> Less errors•Cost: minimum of extra traffic and processing needed for the integration•Scalability•Service Monitoring•Minimum delay (caching when possible + shortest geographical path)•No single point of failure•Clean shutdown/termination

Automated Scalability

•Automation --> Less errors•Better customer experience:

•(High demand --> add servers)•Lower costs:

•(Lower demands --> remove servers)

Openstack Auto-Scaling

WebRTC

Cloud ServersLoad Balancers

Resources

+

Auto Scaling Group

The Resources are scaled up and down based on

the policies

…..

Heat Client

•Using heat client to create the stack/resources

# heat stack-create stack01 -f template.yaml ...

•Openstack control panel

Heat Template

•The template = static

architectural design of your

application (infrastructure

resources in a text file

treated as code).

•Syntax: HOT, YAML, or

JSON

•The snippet here is how to

define a scaling group

group:

type: OS::Heat::AutoScalingGroup

properties:

cooldown: 60

desired_capacity: 2

max_size: 5

min_size: 1

resource:

type: OS::Nova::Server::Frafos

Here the server is defined in a separate yaml file and mapped

in the environment yaml file:

resource_registry:

"OS::Nova::Server::Frafos": "fserver.yaml"

Orchestration Service

•Heat is the orchestration tool used for:•Create resources described in a template•Configure the resources•Installing packages•Auto-scale the resources

•Heat interacts with different Openstack services using the APIs (e.g. Heat creates the alarms using Ceilometer API service)

Ceilometer + Heat

But

•Originally Ceilometer is designed for metering and not for monitoring•Ceilometer is not for application/service level monitoring• Openstack monitoring as service:

•E.g. Monasca that integrates with Openstack (requires Monasca agent to be installed on servers)

Rackspace Monitoring Service

•Monitoring agent must be installed on machine to reports metrics•The users can create their own checks:

• Predefined metrics (CPU, Memory, Load, ..) • Custom (Frafos metrics: calls, regs, and TCPs)

•The service is integrated with autoscaling service using general webhooks created for scaling policies

Rackspace Monitoring Service

Autoscaling policy is triggered --> Alarm is sent to Rackspace

Autoscaling service

Frafos Custom Metrics

•Regs, Calls, and TCP Metrics•The monitoring agent installed on servers reports these metrics periodically (60 s)•Push-Metrics bash script works as plugin to the monitoring agent

Push-Metrics Frafos Plugin

•It is a Bash script•SNMP-based: Obtain the measured data using SNMP•Echos the metrics in the following format:

metric <name> <type> <value> [<unit>]e.g. "metric calls int32 $calls [Count]"

•The agent takes the echoed metrics in that format and sends them to the monitoring service using Metrics API.

No Clean Shutdown

•When the scale-down policy is triggered, Nova kills the servers as following:

•Immediately and hardly•Killing priority: Pending servers and then the oldest

•The problems are:•Gateway case: existing calls•Conference case: existing served conference rooms (long sessions) + late-join requests

•Shutdown controlled by the server is needed

Solution: Heat Software Deployment

•Available since IceHouse Openstack release (2014)•New resource type OS::Heat::SoftwareConfig which defines the configuration •New resource type: OS::Heat::SoftwareDeploymentwhich bind the configuration with the lifecycle actions: CREATE, DELETE,.. actions•The deployment resource remains in progress until a signal comes from the server --> complete state • Heat agents must be installed on the server: os-collect-config, os-refresh-config, heat-config, heat-config-hook, and heat-config-notify to support the software deployment in Heat

(1) Server Configuration

•The user_data_format property must be specified as SOFTWARE_CONFIG in the server definition in the template•The software_config_transport property specifies how the software config metadata goes from Heat to the server

server:type: OS::Nova::Serverproperties:

image: ...user_data_format: SOFTWARE_CONFIGsoftware_config_transport: POLL_SERVER_HEAT

(2) DELETE Action Configuration

•OS::Heat::SoftwareConfig encapsulates the configuration that

we want to apply on DELETE

•“group” property is the type of the configuration to be applied

•“get_file” property can be remote or local address

•The script will be packed in the stack creation package by the

heat command (Heat client)

•The script will be passed to the server to be executed on

DELETE

delete_config:

type : OS::Heat::SoftwareConfig

properties:

group: script

inputs: ...

config: { get_file: scripts/drain_sessions.sh }

(3) DELETE Action Deployment

Bind the configuration with the DELETE action- No new connections- Clean (drain_sessions.sh)- Kill - send HEAT_SIGNAL signal using curl to Heat's API service

frafos-server-delete:

type : OS::Heat::SoftwareDeployment

properties:

actions: [ DELETE ]

config: { get_resource delete_config }

input_values: {...}

server: ...

....

signal_transport : HEAT_SIGNAL

Clean Shutdown - Conference Case

JOIN-Late RequestsIn conference case, people may join a conference late --> the terminating/dying server should not completely isolated- The server is removed from LB- The rest of servers redirect the late-join requests to that server using the public IP- The server drains its sessions- Then the server signals Heat with HEAT_SIGNAL to be killed

Thank YouFrafos GmbH, Ahoy office, Windscheidstraße 18, 10627 Berlin, Germany

http:// www.frafos.commailto:info@frafos.com

Visit Our Online Demo

go.areteasea.com