At the SIPfoundry CoLab users conference members of the sipXecs team present an architecture overview and explain why sipXecs is optimized for cloud production.

1. sipXecs Architecture & Direction
moderator: michael picher
March 10, 2013 / Bentley University / Boston MA
1

2. 2 Intro of Presenters Team
>Load Testing & Build Team:
>Douglas Hubler
>Ciprian Hacman
>SIP Core Team:
>Joegen Baclor
>Daniel Tacalau

3. Agenda 3
>sipXecs 4.6 Architecture Overview
>Testing Procedure
>Test Automation
>Status of 4.6
>Roadmap Near-Term / Long-Term

4. Typical sipXecs Cluster

5. Multi-master (Before… 4.4 and earlier)

6. Single Master - Now

7. Message Queuing Introduced 7
>Needed better interprocess communications
>Lightweight
>Robust
>Evaluated several
>Build?
>RabbitMQ
>ZeroMQ

8. Message Queuing 8
Publisher / Subscriber

9. Message Queuing 9
Dealer / Worker

10. sipXecs 4.6 Architecture 10
SQA

11. 11 Testing Procedure
>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 our Production System
>Dog fooding…

12. Automated Load Tests
sipxtest 12
>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 sipXecs scales

13. sipxtest - Architecture 13
>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)

14. Load Test Numbers
What do we do as part of build testing? 14
>3 days of load testing for all major builds
>15 calls per second
>4 million calls total

15. sipXecs 4.6 Status 15
>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.

16. Roadmap – Near Term 16
End of Q1 to End of Q2
>openACD w/Supervisor & Agent Portals
>Multiple Level Administrator
>Multiple Time Zone
>Polycom VVX 300/400 Support
>sipXsbc
>Session State Services – SSS (clean up RLS / XMPP link)
>Improvements to HA (get rid of odd # of server requirement)
>Call Queuing
>Unite 2.0

17. Roadmap – Longer Term 17
>openACD Reporting
>Branch Office Solution
>Will likely involve looking at User & System management differenly (i.e., more like a directory
structure).
>User Portal re-write
>Browser based client, WebRTC. Zero Install Communications Solution.
>New Admin GUI
>Time to modernize a bit. The old interface is efficient but dated.

18. End 18

19. 19
>What is different as compared to traditional architectures?
>What makes sipXecs an IT application?
>High-level intro to sipXecs 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?

20. 20 Status of the 4.6 Release
>What is new?
>Experience with 4.6 in the field
>Test results and test methodology

21. 21 Deployment Examples
>Pick 2 to 3 examples. E.g. Axcess Finacial

22. 22 Roadmap
>Discuss near term and longer term roadmap
>What is our goal?

23. 23

24. 24

25. 3:00-4:00 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?