moderator: michael picher

March 10, 2013 / Bentley Univesity / Boston MA

openUC and sipXecs Architecture & Direction

1

>Load Testing & Build Team:

> Douglas Hubler

> Ciprian Hacman

>SIP Core Team:

> Joegen Baclor

> Daniel Tacalau

2 Intro of Presenters Team

>openUC & sipXecs 4.6 Architecture Overview

>Testing Procedure

>Test Automation

>Status of 4.6

>Roadmap Near-Term / Long-Term

Agenda 3

Typical openUC / sipXecs Cluster

Multi-master (Before… 4.4 and earlier)

Single Master - Now

>Needed better interprocess communications

> Lightweight

> Robust

>Evaluated several

> Build?

> RabbitMQ

> ZeroMQ

Message Queuing Introduced 7

Publisher / Subscriber

Message Queuing 8

Dealer / Worker

Message Queuing 9

SQA

openUC 4.6 Architecture 10

>Manual smoke test

>Basic tests that catch major issues

>Manual sanity test

>Detailed tests for each feature

>Manual regression tests

>Complex tests for features that are added/changed

>Automated Load Tests

>Deployment for a week on eZuce Production System

>Dog fooding…

11 Testing Procedure

>Placing and receiving calls is the core feature and we want this to be stable

>Basic testing cannot predict

>How a server behaves over time

>How a server behaves under stress

>Call Load tests helps address both problems

>Allows determination the performance of a Certain Server

>All servers are different (physical, virtual)

>Allows for determining how well openUC scales

12 sipxtest Automated Load Tests

>Simple install ‘yum install

sipxtest’

>Pink – Files or Commands that

test user can interact with.

>Yellow – Generated files (you can

edit these files, but know that

sipxtest changes overwrite edits)

sipxtest - Architecture 13

>3 days of load testing for all major builds

>15 calls per second

>4 million calls total

14 What do we do as part of build testing? Load Test Numbers

>eZuce running in house on production system since end of July 2012

>Controlled release since August 2012

>GA December 1, 2013

>Update 1, February 5

> Polycom Firmware Updates, New iptables capabilities, bug fixes.

>Update 2, February 6 (small revert)

>Update 3, March 13

> fail2ban, bug fixes.

openUC & sipXecs 4.6 Status 15

>openACD w/Supervisor & Agent Portals (openUC)

>Multiple Level Administrator (openUC)

>Multiple Time Zone (openUC & sipXecs)

>Polycom VVX 300/400 Support

>sipXsbc (openUC & sipXecs)

>Session State Services – SSS (openUC & sipXecs?, clean up RLS / XMPP link)

> Improvements to HA (get rid of odd # of server requirement, openUC &

sipXecs)

>Call Queueing

>Unite 2.0 (openUC)

End of Q1 to End of Q2

Roadmap – Near Term 16

>openACD Reporting (openUC)

>Branch Office Solution (openUC & sipXecs?)

> Will likely involve looking at User & System management differenly (i.e., more like a directory

structure).

>User Portal re-write (openUC)

> Browser based client, WebRTC. Zero Install Communications Solution.

>New Admin GUI (openUC & sipXecs)

> Time to modernize a bit. The old interface is efficient but dated.

Roadmap – Longer Term 17

End 18

>What is different as compared to traditional architectures?

>What makes openUC an IT application?

>High-level intro to openUC architecture (diagram)

>Hardware independence: What does this mean?

>Resulting deployment options: Focus on flexibility, global scale, redundancy

>Redundancy, branch redundancy

>Focus on our ‘secret sauce’. What makes this architecture better than all

the others?

19

>What is new?

>Experience with 4.6 in the field

>Test results and test methodology

20 Status of the 4.6 Release

>Pick 2 to 3 examples. E.g. Axcess Finacial

21 Deployment Examples

>Discuss near term and longer term roadmap

>What is our goal?

22 Roadmap

23

24

3:00-4:00 openUC and sipXecs Architecture

Moderator: Mike

Participants: Douglas, Daniel, Joegen, Ciprian Engineering provided content: •Architecture overview (Mongo, SIP, XMPP, CFEngine high-level arch diagram). •Features and improvements delivered with 4.6 •Test automation (how do we test?) •Status of 4.6 •Deployment examples (distributed, virtualized, redundancy) •Roadmap – what to come next?