VoIP applications and the Cloud - Where gen_fsm really shines Aptela provides hosted communications services for small business. Our - entirely cloud based - platform includes complex call routing, messaging, web-portals, mobile apps, PSTN/SIP access, and a coffee-grinder attachment. At peak, we handle dozens of calls (and an infinity of HTTP requests) per second These complex calling services work thanks to the magic of gen_fsm, a behavior which is frequently overlooked at best, and ignored at worst. In the first part of the talk, I'll describe our architecture, with gen_fsm's critical role in it as the focus. The second part will delve into the specifics of how this behavior can help build out complex calling services, with examples culled from some of Aptela's cooler (or crazier?) features

1. FSMs can be Useful
Mahesh Paolini-Subramanya
CTO, Vocalocity

2. Hosted PBX Taxonomy
► Named Box
• Pure hosting
• Clustering/Virtual or Big Honking Box
• Load/Scaling issues same as ‘one box’ application
► High Level Application Server
• Calls generate high level events
• Events interact with application server
• Predefined spaces/features
• Load/Scaling issues same as ‘one box’ application
© Vocalocity 2011. Confidential. 2

3. Hosted PBX Taxonomy
► Granular Application Server
• Calls generate granular events
• Events interact with application server
• Easy to create simple applications
 Point features: FML, notifications, transcriptions
 Call Switch: Routing, voicemail
► Difficult to build complex applications
• Updates and deployments
• Testing and Debugging
• Concurrency
• Scaling and Partitioning
• Persistence
© Vocalocity 2011. Confidential. 3

4. Cloud Computing
►Wikipedia
“a style of computing in which typically real-time scalable
resources are provided as a service over the Internet to end-
users who need not have knowledge of, expertise in, or control
over the technology infrastructure”
►Vocalocity
• Horizontal Scaling and/or Clustering
• Abstraction of application layer
• SOA and/or fine-grained API
• Redundancy irrelevance
© Vocalocity 2011. Confidential. 4

5. Cloud Computing
► Telephony makes it harder
• Simple and distributed actions? Done
• High Level Applications? Done
• Both at the same time? Well, Maybe Not…
► Vocalocity
• Distributed application infrastructure (erlang)
• Distributed persistence infrastructure
• Distributed telephony infrastructure
 Simple, atomic events!!
© Vocalocity 2011. Confidential. 5

6. Why erlang?
► Testing
► Code deployment
► Concurrency
► Complexity
► Predictable Performance
► Fault tolerance
► Error Containment
► Testing
► Code Deployment
© Vocalocity 2011. Confidential. 6

7. Clean APIs
► Only interface into System
► Handlersfor different modalities System
• HTTP for Public
• STOMP for Private
Business Rules
STOMP HTTP Event
Workflow Vocalocity Call Server
© Vocalocity 2011. Confidential. 7

8. Clean APIs
► Administrative
• CRUD – Users, Depts, …
System
• Regulatory – E911, TRS, …
• OSS
► Informative Business Rules
• Notifications
• High Level Events
• Messages – History, Reporting STOMP HTTP Event
► Interactive
• Communications – Calls, Contacts, …Workflow Vocalocity Call Server
• Profile – Blacklist, FML, Media, …
• Messages – History, Reporting, …
© Vocalocity 2011. Confidential. 8

9. Processes
► Allrequest goes to any available
application node as a message
► Nodes have processes
• Users
• Clients
• Calls
• Faxes
• Phones
• Load Balancers
► Processes do things
© Vocalocity 2011. Confidential. 9

10. Event Handlers
► Theyget information to endpoints
• GUI
• API callbacks
© Vocalocity 2011. Confidential. 10

11. Event Handlers
► The perform asynchronous application
activities
• Logging
• notifications
► They bridge between the FSMs and the
calls
• Check blacklist
• Play error message
• Hangup
• Go offhook
© Vocalocity 2011. Confidential. 11

12. Calling
► Calls are tracked as Processes
► Event interface for requests and responses (XML)
► fine-grained events that can
• make/break calls
• record audio and dtmf System System System
• play audio and dtmf
• file operations erlang / xml / events
► Call Process tracks
• Channel parameters Call Server Call Server Call Server
• FSM name and state
© Vocalocity 2011. Confidential. 12

13. Finite State Machines
► System has a limited set
of states
► Statestransition based
on conditions
► Transitions are atomic
► Events and actions at
entry and exit
A Dog
A Cat
* Diagrams from http://learnyousomeerlang.com/finite-state-machines
© Vocalocity 2011. Confidential. 13

14. Finite State Machines
► Many many many FSMs (25 at last count) init
• Auto Attendant
• FML Check node
• Voicemail
• Conference Check
Blacklist
Move node
• Fax
• C2C
• Video Cancelled Blacklisted Next Endpoint Collections Unknown
• Directory
• Search
• Announcements Auto Attendant FML Voicemail Conference Fax
• Paging
© Vocalocity 2011. Confidential. 14

15. Finite State Machines
► Templates are your friend init
init
► So are BIG sheets of paper.
Return
Setup Call AutoAttendant
► More is merrier
► But keep them simple, OK? Hangup
Get Caller
Name
Play Transfer
► Mixing States is BAD Message
► As is my haiku talent. Got Caller
Name
Dial
© Vocalocity 2011. Confidential. 15

16. FSMs can be Useful – See?
Mahesh Paolini-Subramanya
CTO, Vocalocity