1. Components of Asterisk SCF
Introductory slide. Smile, introduce yourself and introduce the topic. If you're feeling particularly adventurous, you may want to open with a joke.

2. WTF is a component?
A component is a loadable module (.dll on Windows, .so on Unix-like systems)
icebox-loadable libraries
Standalone libraries
Most git repos have two components
The primary services
State replicator listener when in standby
We need to be clear on what a “component” is, because it's possible that people could become confused and start referring to the git repos as components.
Components are libraries (DLLs on Windows and SOs on Unix-like systems). In most cases, the libraries are created in order to be loaded into icebox.
Common elements of components are state replication and dynamic configuration.

3. Service Discovery Implementation of the discovery API
Provides means of finding needed services
Provides means of registering new services
Service discovery is a core component and used by most other components.
It provides the ability to register services and find services requested by components.
An example might be that the Routing service tells the service locator that it provides an endpoint locator. Then the SIP component can ask the service locator where an endpoint locator is. It's simple as that!

4. Routing Implementation of the SessionRouter interface
Used as a means of ... routing sessions
Voted “Most likely component to be rewritten by everyone”
The routing component is responsible for taking a destination string and interpreting that as an endpoint (or endpoints) with which to start a new session. The routing component also implements methods that help facilitate transfers.
The routing component keeps track of endpoints via its implementation of the EndpointLocator interface.
Though a basic routing component is provided with AsteriskSCF, we imagine that most people will write their own implementation instead. This way, they can control aspects like permissions.
Asterisk users could think of this as the equivalent of extensions.conf.

5. Bridging Implements the Bridge and BridgeManager interfaces
Responsible for connecting sessions in a manner that allows them to communicate
Responsible for passing indications/events between sessions while they are bridged
The bridge acts as a relay point for sessions. The bridge is the piece of the puzzle that is omniscient. In other words, it has knowledge of all sessions involved.
Bridges are responsible, during formation, for connecting media sources and sinks in various sessions as well as connecting telephony event sources and sinks between telephony sessions.
Once established, bridges mainly act as a session listener for all sessions, allowing for indications to be relayed to other sessions if necessary.

6. SIP Uses PJSIP as a SIP stack
PJSipSessionModule implements the Session interface
Acts on SIP INVITEs to initiate sessions.
Live sessions listen for SIP messages and indicate changes to session listeners
PJSipRegistrarModule implements a SIP registrar
(This is hard to express in a single slide)
SIP is the only session gateway that's been written so far. It also encompasses other SIP concepts such as registration.
SIP operates on top of the PJSIP stack. This allows for Asterisk SCF not to get bogged down (too much anyway) in the finer details of SIP. We can focus more on the application details.
The SIP allows for optional PJSIP modules to be loaded. Common ones are the session module and the registrar modules.

7. MediaRTPPJMedia Uses PJMEDIA as an underbelly
Implements the MediaSession, StreamSource, and StreamSink interfaces
Listens on RTP ports for media and passes the media to whatever StreamSinks are configured.
Sends, processes, and receives RTCP as well.
Like with the SIP component, we use an available RTP stack so we don't have to worry about some of the nitty-gritty details.
The component provides a method for creating media sessions. The SIP component uses this in order to set up the media sessions described in SDPs.

8. MediaFormatGeneric
Provides mappings between media formats and their respective SDP representations
Provides methods for adding descriptors for custom media types
This provides a service that allows for media formats to be matched with descriptors used in SDP.

9. MediaOperationsCore
Provides implementations of MediaOperation interfaces
Translators for common audio formats
WebRTC NetEQ-based jitter buffer
Inband telephony event detector
Asterisk SCF's media operations are implemented by this component.
Media operations are essentially services that provide some sort of transformation on media. This can be anything from jitter buffering, to format translation, to resampling, to volume adjustment (not implemented).

10. MediaTransportUDPTL Uses PJMEDIA and Asterisk's UDPTL stack
Provides a media implementation for UDPTL streams. IS THE DEVIL

11. C++ Libraries
Some Asterisk SCF code compiles into C++ libraries instead of icebox-loadable shared libraries

12. ice-util-cpp Common Ice-related functionality implemented in C++
SmartProxy
Base component
WorkQueue
ThreadPool
Many more!

13. Slice Provides APIs used by all Asterisk SCF components
Implemented in slice language, allowing for interfaces to be defined in multiple languages.

14. Logger
Provides for a method to record messages while Asterisk SCF is running
Client provides for ostream-style logging to a file or over Ice
Server can accept messages over Ice, allowing logs to exist on different servers if desired.