Skip to content

Architecture

In this section, some key concepts about das-Peak Streaming architecture are explained. Following image shows a high level architecture diagram of das-Peak Streaming:

High Level Architecture

Signalling Channel

Before start sending audio, das-Peak Streaming needs to know some information such as the audio protocol to be used, the format of the audio to be sent (codec, sample rate, number of channels, ...) or the duration of the audio for a registration/verification. In addition, user requires a way of receiving operation outcomes, cumulated voice information or error feedback. Thus, das-Peak Streaming provides Signalling Services.

Signalling Services allows users to specify the audio parameters to be sent to das-Peak Streaming. Also allow them to get information about current registration/verification process. The communication between a user and the Signalling Service flows through the Signalling Channel.

Currently, das-Peak Streaming exposes two different Signalling Channels:

  • REST Channel: Implements a REST API that allows to create registration/verification processes and consult their state using a polling mechanism. This API is very useful for IVR environments where no other mechanism but polling is available. Check details of REST Channel API here.
  • Socket.IO Channel: Implements a Socket.IO based API that allows to create registration/verification processes and establish an asynchronous bidirectional channel where process state is notified via events. Check details of Socket.IO Channel API here.

Audio Channel

das-Peak Streaming is designed for covering a broad scenario where audio can be sent/received in many different protocols and formats exposing different Audio Consumers.

Audio Consumers are services which implement a specific real-time audio protocol. These services can be used by any user in order to send real time audio to das-Peak Streaming. The communication between a user and the Audio Consumer flows through the Audio Channel.

Currently, das-Peak Streaming exposes two different Audio Channels for receiving real time audio. Each of these Audio Channels has its corresponding Audio Consumer implemented.

  • Genesys Audiohook Channel: Implements Audiohook Protocol Specification. Useful for Genesys Cloud's integrations. Check details of Genesys Audiohook Channel here.
  • Twilio Media Streams Channel: Implements Twilio Media Streams API. Useful for Twilio's integrations. Check details of Twilio Media Streams Channel here.

das-Peak Streaming provides the capability to send audio without being tied to the use of Genesys Cloud or Twilio platforms. It achieves this by interpreting a subset of the Twilio Media Streams specification for audio transmission without the need to utilize the Twilio platform. Check details of this specification here.

Audio - Signalling interaction

To perform a registration/verification process, das-Peak Streaming's users first need to use a Signalling Channel in order to negotiate audio streaming terms. The user must specify a call_id parameter that univocally identifies the process. This parameter is used by das-Peak Streaming Signalling Services to synchronize with the corresponding Audio Consumer. Therefore the call_id parameter also requires to be sent via the Audio Channel together with the audio.

call_id is the unique identifier that allows das-Peak Streaming to match a register/verify session with its corresponding audio stream.

Any combination of Signalling and Audio channels is possible. This feature makes das-Peak Streaming a versatile tool for all kind of real time authentication solutions.

Sessions

When a user sends a request to a Signalling Service via Signalling Channel, das-Peak Streaming validates it and creates a Session. This one represents a complete registration or verification process, since user first request, through audio streaming, until a result of the process is obtained.

There exists two types of Sessions:

  • Register Session: Created when a registration process is requested.
  • Verify Session: Created when a verification process is requested.

Sessions contain all information about a registration or verification process, audio streaming status, errors, etc. Sessions are created by using Signalling Services APIs.