42. • IPv4 and IPv6 for all IP-aware interfaces.
• Flexible (and dynamic) session capability negotiation
• UTF-8 aware for all interfaces that can transport and
manipulate such strings. • Access to session quality metrics and statistics
• Transport security for all interfaces that can support it (TLS, • RTCP
SRTP).
• Bridging
• Example implementations of various extension point hooks,
interface decorators and other APIs in easily consumable • Add, remove, change state of sessions in bridges dynamically
languages. • Events indicating when sessions start and stop speaking (or similar)
• Mechanisms to support non-transparent network connections • Mixing audio at highest quality possible for sessions in bridge
when necessary (NAT, NAPT, etc.).
• Support direct media paths for two-session bridges when available
• STUN, TURN, ICE
• Glacier2 • Message-Oriented Communications
• Example component that listens to bridges and their sessions • SIP
and shows how events and state changes can be seen. • MESSAGE
• All components provide interfaces for dynamic configuration.
• Presence and Resource State Communications
• SIP registrar service.
• SIP
• Active/passive failover (hot standby model using real-time
state replication) in all core components. • SUBSCRIBE, NOTIFY, PUBLISH
• State replication mechanism that utilizes an existing, • dialog-info, presence, message-summary
wiki.asterisk.org
well-supported replication technology.
• Media
• Mechanisms for developers to be able to attach and retrieve
their own information to all long-lived objects in the system. • Support for arbitrary sample rates, sample sizes and frame sizes.
• Stable, version-controlled and well documented APIs for • Transport and connect (not transcode/transrate) commonly used video
component developers. formats
• Thorough, but basic, routing service and documentation to • H.263, H.263+
ease learning of the framework. • H.264
• Service location mechanism that can take into account user-
• Connection of dissimilar media streams with transcoding/transrating as
specified attributes when deciding on which component needed.
should service a request.
• G.711 u-Law and a-Law
• Session-Oriented Communications
• SIP • G.729A and AB
• ISDN • G.722
• Primary Rate Interface • OPUS
• Q.SIG • SILK
• Telephone in-session events (but not telephony events)
• Adaptive jitter buffering and packet loss concealment.
• DTMF
• Recording and playback of media streams.
• Hold/Unhold
• Media components support passthrough of user-defined media formats
• Flash of known media types.
• CNG, CED, ANSam, V.21
• Audio manipulation components (denoise, AGC, level adjustment).
• Party identification, with support for 'domains of trust'
Good afternoon, for those of you who don't know me, my name is Bryan Johns. I joined Digium in the Fall of last year as it's Community Director. Im here to give you an overview of our new open source project Asterisk SCF. \n\nThis is a 2-part presentation and I will be followed to the stage by Tim Panton who is going to give a developers perspective on Asterisk SCF, so I only have 10 minutes. If you've never seen a 40 slide presentation given in 10 minutes, you're in for a real treat, so strap in.\n\n\n
Over the past 11 years, Asterisk has been the largest force for change in the world of telecommunications. It provides developers worldwide with the open source tools that they need to build voice-based applications for their businesses. Thanks to Asterisk, telecommunications has been delivered to the masses, without restriction.\n
Asterisk has been the backbone of the global migration to Voice over IP. No other platform has the penetration across the board that Asterisk does. This year, Asterisk will be downloaded more than two million times. Let's take a few minutes to ask and ultimately answer the the question "asterisk...what's the big deal?"\n
Over it's history, Asterisk has received development contributions from more than 9800 developers world wide.\n
The Asterisk community is comprised of more than 73000 participants. To put that into perspective...\n
73000 people would fill Lambeau Field, the home of the Green Bay Packers.\n
Asterisk is currently deployed in more than 162 countries around the world. \n
...and Asterisk is estimated to be handling roughly 400 calls each second of every day of the year globally.\n
The point that I am working to make here is that over the last 11 years, Asterisk has become a really big deal.\n
So if we ask ourselves how we were able to achieve all of these things, there's a single contributing factor that we cannot be overlooked....\n
The Asterisk Community and it's collective mission to rewrite the rules of IP communications and the Telecommunications business as a whole deserves the credit for all that we have achieved over the last eleven years.\n
If you've spent any time with Asterisk, you know that while it is very powerful, it has some very obvious limitations. This comes from it's original design as a PBX....\n\nAsterisk as software is monolithic in design and while Asterisk is a powerful application, today's IP communications world demands more. Today's needs go far beyond the functional limitations of Asterisk and incorporate media types beyond voice, such as video, text, desktop sharing and so on....in essence the broader concept of communications.\n
So in late 2009 and early 2010, Digium reached out to it's community and defined the specific capabilities currently absent from or difficult to achieve with asterisk. These requirements were categorized into 4 core areas:\n\nPerformance\nScalability\nFault tolerance\nExtensibility\n\n
In assessing these new requirements, it was determined that we couldn't sufficiently modify the existing Asterisk code base to include these capabilities without significant disruption to the project and the community that utilize it...\n
So in partnership with the community we decided that we needed to launch a companion project that would bring all of these capabilities to Asterisk....\n\nWork began immediately on this new framework and at Astricon 2010 in DC, we announced....\n
The Asterisk Scalable Communications Framework, or...\n
The Asterisk Scalable Communications Framework, or...\n
The Asterisk Scalable Communications Framework, or...\n
Asterisk SCF\n
Asterisk SCF\n
Asterisk SCF\n
Asterisk SCF\n
Asterisk SCF\n
Asterisk SCF\n
Asterisk SCF\n
Asterisk SCF\n
So as I previously mentioned, Asterisk SCF was conceived by the Asterisk community to deliver on 4 primary goals:\n\nPerformance\nScalability\nFault tolerance\nExtensibility\n
Asterisk SCF is a distributed application. It assumes that it's capabilities will be broken up across different functions or services and will also likely be broken up into different server environments, geographic locations or network infrastructure.\n
So this is what a distributed application looks like... the components are located in the places they are needed, and the number of components is dictated by the requirements of the application or solution. Just as importantly, if additional resources are required, only the components needed for that function need to be deployed; the other components of Asterisk SCF will just see the increased capacity become available.\n
So let's take a moment to look at how Asterisk SCF addresses each of its core goals, beginning with the goal of performance.\n
\nThe performance of traditional communications applications can be limited because all their processes run on the same computer. The modern world of scalable computing has given rise to transparent distribution of processes across multiple computers in multiple locations, providing theoretically unlimited scalability. Asterisk SCF takes full advantage of this by allowing each individual component, which might provide a function such as route lookup, media translation, or bridging, to run on a different processor or a different computer while still appearing as one cohesive system.\n
Once we've gotten past the requirement for performance, we can address the need for scalability...\n
Traditional communications applications can be scaled to accommodate very large deployments, but this scaling is typically not native or requires extraordinary measures.\nSome features, such as transfer of calls or inter-system presence information, can be difficult to implement in a scaled environment and frequently require the use of many disparate applications.\n\nExamples of OpenSER derivatives used to cluster Asterisk environments.\n
But where we've got CPU segmentation of components, the door is open to expand capacity on a machine-by-machine basis.\n
...and we can bring additional capacity online on the basis of any core component without disrupting the function of the whole...\n
Moving along to fault tolerance...\n\nIf you've ever tried to cluster asterisk to accomplish fault tolerance, you know what a challenge this can be...\nAsterisk was not originally designed for this capability and you essentially have to force it to play nice in a clustered design to achieve something that looks like fault tolerance... \n
But where you have CPU isolation by function and a simplistic means of incrementally scaling individual components, you can layer-in state replication services...\n
...and where you are replicating state across multiple instances of the same component, you have an integrated fault tolerance model that affords you a simple means of failing across systems and network segments without a loss of media and without a loss of call control.\n
Lastly, let's take a look at extensibility. Asterisk users and developers have become all to familiar with AMI and AGI as a means of interfacing with and controlling Asterisk functionality. This is cumbersome because it requires translation from your coding environment going in and coming back out. \n
Where you have segmented the functionality of the platform by component and by CPU and you are able to provide a common set of API calls for accessing the broader framework's capabilities....\n
...you are able to extend the platform's functionality with new services or applications seamlessly and without disruption to the broader framework.\n
One of the most exciting aspects of Asterisk SCF is it's support for a broad inventory of programming languages and operating systems. This opens the door for all sorts of creative design ideas and integration of existing software applications with an Asterisk SCF network. We see this design concept as opening the door to an entirely new ecosystem of Asterisk SCF applications and services. \n
Now that we've covered the mission of Asterisk SCF and looked at how the projects design accommodates the four core deliverables of performance, scalability, fault tolerance and extensibility through a common set of developer APIs, let's take a quick look at the overall architecture of Asterisk SCF\n
I realize that this slide is difficult to read. A detailed overview of the architecture of Asterisk SCF is available on the project wiki at wiki.asterisk.org.\n
So you’ve seen most of what Asterisk SCF is....but it's probably more interesting to talk for a second about what it is not..\n\nAsterisk SCF is being built with a deliberate intention to avoid the implementation of business logic. Asterisk SCF is a service delivery framework to which you can attach applications written in the language of your choice. You may have conventional Asterisk platforms attached to Asterisk SCF or you may have applications you've built and deployed yourself or you may find applications made available by the community that are useful to your organization.\n
Earlier this year, we finalized the technical deliverables for Asterisk SCF 1.0....\n
Here is a slide representing what we intend to deliver in Asterisk SCF 1.0... Again, a slide that is next to impossible to read, so you can also retrieve this information from the project wiki at wiki.asterisk.org. \n
So once we are able to arrive at Asterisk SCF 1.0, how will you be able to utilize it? What is it good for?\n
We believe that there are certain uses for a scalable, fault tolerant, extensible distributed service delivery framework that are obvious. This list most certainly includes:\n\nService Provider Networks\nEnterprise communications\nCloud Applications\nContact Centers\n\n...and I can imagine there are many more.\n \n
We believe that there are certain uses for a scalable, fault tolerant, extensible distributed service delivery framework that are obvious. This list most certainly includes:\n\nService Provider Networks\nEnterprise communications\nCloud Applications\nContact Centers\n\n...and I can imagine there are many more.\n \n
We believe that there are certain uses for a scalable, fault tolerant, extensible distributed service delivery framework that are obvious. This list most certainly includes:\n\nService Provider Networks\nEnterprise communications\nCloud Applications\nContact Centers\n\n...and I can imagine there are many more.\n \n
We believe that there are certain uses for a scalable, fault tolerant, extensible distributed service delivery framework that are obvious. This list most certainly includes:\n\nService Provider Networks\nEnterprise communications\nCloud Applications\nContact Centers\n\n...and I can imagine there are many more.\n \n
So in my role as a Community Director, I am here to implore you to get involved and there are a number of ways and places that you can do that.\n
There's always the project web site at www.asterisk.org\nthe aforementioned-mentioned project wiki at wiki.asterisk.org\nwe hold regular developer conference calls (shared calendar files available on the wiki)\nThe IRC channels for Asterisk SCF are on Freenode at #asterisk-SCF and #asterisk-SCF-dev\n\n
There's always the project web site at www.asterisk.org\nthe aforementioned-mentioned project wiki at wiki.asterisk.org\nwe hold regular developer conference calls (shared calendar files available on the wiki)\nThe IRC channels for Asterisk SCF are on Freenode at #asterisk-SCF and #asterisk-SCF-dev\n\n
There's always the project web site at www.asterisk.org\nthe aforementioned-mentioned project wiki at wiki.asterisk.org\nwe hold regular developer conference calls (shared calendar files available on the wiki)\nThe IRC channels for Asterisk SCF are on Freenode at #asterisk-SCF and #asterisk-SCF-dev\n\n
There's always the project web site at www.asterisk.org\nthe aforementioned-mentioned project wiki at wiki.asterisk.org\nwe hold regular developer conference calls (shared calendar files available on the wiki)\nThe IRC channels for Asterisk SCF are on Freenode at #asterisk-SCF and #asterisk-SCF-dev\n\n
There's always the project web site at www.asterisk.org\nthe aforementioned-mentioned project wiki at wiki.asterisk.org\nwe hold regular developer conference calls (shared calendar files available on the wiki)\nThe IRC channels for Asterisk SCF are on Freenode at #asterisk-SCF and #asterisk-SCF-dev\n\n
There's always the project web site at www.asterisk.org\nthe aforementioned-mentioned project wiki at wiki.asterisk.org\nwe hold regular developer conference calls (shared calendar files available on the wiki)\nThe IRC channels for Asterisk SCF are on Freenode at #asterisk-SCF and #asterisk-SCF-dev\n\n
Following me to the stage will be Tim Panton of phonefromhere.com. Tim is a long-time asterisk guru and contributor who has been instrumental in the early definition and design of Asterisk SCF and he will sharing some of the community-specific attributes of the project and demonstrating some of the power of this new platform. Thank you for your time and attention. Tim?\n