VoIP in the cloud - scaling massively through the magic of erlang
•Download as PPTX, PDF•
0 likes•957 views
Building the infrastructure for delivering complex cloud-based services is remarkably difficult, what with having to deal with concurrency, deadlocks, state-management, etc. in a scalable manner. When one adds VoIP - with its combination of short (SIP) and long (RTP) transactions, this becomes near impossible. At Aptela, we have cracked the code and now provide a true telephony cloud with highly complex applications developed using simple web APIs, and with all calling handled in a truly distributed fashion. Our platform includes complex call routing, messaging, web-portals, mobile apps, PSTN/SIP access, and a coffee-grinder attachment, currently handling dozens of calls - and an infinity of HTTP requests - per second. In this presentation, we will describe the architecture and process model, with an emphasis on the specific challenges associated with manipulating extremely large amounts of data in a near-real-time manner. In addition, we will also elaborate on the benefits of the erlang/OTP environment in developing a truly scalable, concurrent and fault-tolerant environment.
Recommended
More Related Content
Viewers also liked
Viewers also liked (17)
More from Mahesh Paolini-Subramanya
More from Mahesh Paolini-Subramanya (9)
Recently uploaded
Recently uploaded (20)
VoIP in the cloud - scaling massively through the magic of erlang
- 1. VoIP in the Cloud 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. Issues - Updates and Deployment Smooth, Seamless, and Efficient © Vocalocity 2011. Confidential. 6
- 7. Issues - Updates and Deployment “Hey guys! I dropped my wrench!” © Vocalocity 2011. Confidential. 7
- 8. Issues – Testing and Debugging © Vocalocity 2011. Confidential. 8
- 9. Issues – Testing and Debugging © Vocalocity 2011. Confidential. 9
- 10. Issues – Testing and Debugging ► Arrrggh ► Arrrggh ► Arrrggh ► Arrrggh ► Arrrggh ► Arrrggh © Vocalocity 2011. Confidential. 10
- 11. Issues – Concurrency ► Live displays of calls ► Interactivity with calls • Transfers • Conferences • Recording • Monitoring • Notifications © Vocalocity 2011. Confidential. 11
- 12. Issues - Scaling • v - VS - © Vocalocity 2011. Confidential. 12
- 13. Issues - Persistence ► Voicemails and faxes in the file system ► Databases • Telco =:= Reporting • We‟ve become Database gurus ► Replication hell © Vocalocity 2011. Confidential. 13
- 14. Issues – Testing and Debugging ► Arrrggh ► Arrrggh ► Arrrggh ► Arrrggh ► Arrrggh ► Arrrggh © Vocalocity 2011. Confidential. 14
- 15. Why erlang? ► Testing ► Code deployment ► Concurrency ► Complexity ► Predictable Performance ► Fault tolerance ► Error Containment ► Testing ► Code Deployment © Vocalocity 2011. Confidential. 15
- 16. 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. 16
- 17. 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. 17
- 18. Processes ► Allrequest goes to any available application node as a message ► Nodes have processes • Basic unit of concurrency • Extremely light weight (~300 bytes) • Not a kernel process • No shared memory ► Processes are supervised ► They restart themselves ► Processes synchronize activities ► They perform tasks © Vocalocity 2011. Confidential. 18
- 19. Event Handlers ► Theyget information to endpoints • GUI • API callbacks © Vocalocity 2011. Confidential. 19
- 20. 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. 20
- 21. 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. 21
- 22. Finite State Machines ► Many many many FSMs (25 at last count) • auto_attendant • bridge • check_voicemail • conference • dial_in • dial_in_fml • dial_out • dial_out_fax • dial_out_video • originate • originate_fax_back © Vocalocity 2011. Confidential. 22
- 23. Persistence ► Schema free document database ► Stores documents as JSON Key-Value pairs ► Incremental replication • Conflict management and resolution ► “Lazy” indexes and views • Erlang ► BigCouch = couchdb + Dynamo • http://www.allthingsdistributed.com/2008/12/eventually_cons istent.html © Vocalocity 2011. Confidential. 23
- 24. Calling ► Event interface for requests and responses ► erlang, xml for event processing ► fine-grained events which are merged to • make/break calls • record audio and dtmf System System System • play audio and dtmf • file operations erlang / xml / events Call Server Call Server Call Server © Vocalocity 2011. Confidential. 24
Editor's Notes
- Three types of PBXs – Named Box, High Level App Server, and Granular App ServerNamed Box – point at a box, and say “Yup, that’s my server”High Level App Server – Broadsoft and/or FS/Asterisk using dialplans.
- Point features are really easy to do. They are atomic, and don’t interact with each otherWhen you start talking about multiple entities interacting, users xferring amongst each other, state across a distributed environment, life gets a lot more difficult
- Really, this is worth repeating. We’ve reached the state where we don’t do anything. Anything. *Anything*. Because something *will* break.
- On the other hand, lets not talk about concurrency
- Who knew that we’d end up being postgres gurusDo you know how many VMs and faxes we get per day? They have to go somewhereTelco is a reporting business.
- Really, this is worth repeating. We’ve reached the state where we don’t do anything. Anything. *Anything*. Because something *will* break.
- Explain supervisor trees - restart processes - dynamically move them around - location invariance - resilience
- We use event_handlers to get information to endpointsGUI – anytime something interesting ahppens, we ship events off to the GUI (ringing, answered, presenceApplication – The State servers (where processes live) ship events back and forth so that processes can keep up to dateTelephony – Call servers use events to know what to do next (based on the FSMs). Pick up the call, play an error message, etc.
- We use event_handlers to get information to endpointsGUI – anytime something interesting ahppens, we ship events off to the GUI (ringing, answered, presenceApplication – The State servers (where processes live) ship events back and forth so that processes can keep up to dateTelephony – Call servers use events to know what to do next (based on the FSMs). Pick up the call, play an error message, etc.
- We use Finite State Machines – gen_fsm – to deal with anything and everything involving callsauto_attendant, bridge, check_voicemail, conference, default_phone, fml, dial_out, and havent even gotten to the voicemails and faxes
- We use Finite State Machines – gen_fsm – to deal with anything and everything involving callsauto_attendant, bridge, check_voicemail, conference, default_phone, fml, dial_out, and havent even gotten to the voicemails and faxes
- We use Finite State Machines – gen_fsm – to deal with anything and everything involving callsauto_attendant, bridge, check_voicemail, conference, default_phone, fml, dial_out, and havent even gotten to the voicemails and faxes
- We have our own BGP ASWe have DIDs from multiple providers ( limits exposure)