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.

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.

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!

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.

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.

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.

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.

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.

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).

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

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

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

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

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.