The FrontStage and recording with other AS7 PBX functions can run independently on each other. If you would like to use them as whole and to have all the data aligned, you have to take into consideration following architecture and dependencies.

Solution architecture

Components needed for the recording



The PBX has a “multi-tenant” cloud logic, which means that one physical PBX can have more tenants in it, which are then serving particular FrontStage instalations. PBX creates individual IDs for the tenants internally. The same principal also applies for the RecordWeb. The PBX provides the recordings in a .waw format.


From the AS7 perspective, Tenant is a virtual PBX, which has dedicated it’s own sources and serves only one FrontStage installation.

Parameters needed to be set for recording:

  • Upload URL - PBX sends the recording to the specified URL after the call is ended, including metadata. Communication can be realized through HTTP or HTTPS protocol. You can specify a custom port (default is 4080)

  • TenantID and TenantName - tenant identification for pairing with the RecordWeb

Metadata transferred with the recording

  • CallingNumber - customer’s number

  • CalledNumber - dialed number

  • StartTime - call start (UTC time)

  • CallID - AS7 internal call ID

  • FileName - AS7 internal file name

Metadata needed to identify the right tenant

All these metadata are filled only when available, otherwise the value will be NULL.

Caller side info

  • CGTENANT - Tenant ID

  • CGTENANTNAME - Tenant Name



  • CGEXT - Extension ID

  • CGEXTNAME - Extension Name

Called side info:

  • CDTENANT - Tenant ID

  • CDTENANTNAME - Tenant Name



  • CDEXT - Extension ID

  • CDEXTNAME - Extension Name

We can say, that all of the sent IDs are equal to the internally used AS7 PBX IDs, parameters ending on “NAME” are equal to defined names (can be defined in the AS7 admin)

Sent parameters example (a part of the URL sent to the recording):


AS7 Record Service

The service has the “multi-tenant” logic, the same as for the PBX. It handles the communication comming from the AS7. Recordings are being stored to the defined storage (more storage options) and metadata to FrontStage database.

The service is beign configured in the FrontStage database.

Service parameters in appsettings.json :

"Logging": {
   "LogLevel": {
    "Default": "Information",
    "Microsoft": "Warning",
    "Microsoft.Hosting.Lifetime": "Information"
   "Kestrel": {
      "Endpoints": {
      "Http": {
     "Url": "http://*:4080"
   "AllowedHosts": "*",
   "As7Recording": {
    "Tenants": [
      "Name": "13",
      "ConnectionString": "Server=localhost;Database=FrontStageV4;Trusted_Connection=True;",
      "DatabaseType": "MsSql",
      "DebugIndicators": "Detail,Event,Logic,Handling,Csta,Linq",
      "RecordingOptions": {
        "InstanceKey": 1,
        "ProcessingDelay": 5000,
        "TempPath": "C:\\Atlantis\\Temp"
   "TraceListener": {
      "FilePath": "c:\\Atlantis\\Logs\\SRec.AS7RecordService.log"
   "File": {
      "Path": "C:\\Atlantis\\Logs\\iCC.ServiceSync.log",
      "Append": true,
      "MinLevel": "Information",
      "FileSizeLimitBytes": 67108864,
      "MaxRollingFiles": 32

Logging section

Contains the default settings (Logging:Loglevel subsection) and subsection for individual providers (where LogLevel structure is being repeated). Possible values for providers are: Logging:Console, Logging:Debug, Logging:EventSource and Logging:EventLog when running on Windows. More about logging here

Loglevel structure

In a subsection, there’s usually stated a Default loglevel, which is then common for all the levels, that are not mentioned explicitelly. Specific loglevels can be then stated as standalone parameter. Loglevels are commonly set as FQDN C# classes. Possible degrees: Trace, Debug, Information, Warning, Error, Critical and None.

Console provider

The most common provider, which content can be seen in a running application window, if the console is triggered (also in Kubernetes log). The output format can be set via Logging:Console:FormatterName parameter, possible values are simple, systemd and json. Formating in more detail here

Debug provider

It is possible to use it on Windows (can be watched with a help of DbgView) or Linux, where the output is inserted to /var/log/syslog or /var/log/message folder.

File provider

File logging in case of a Windows server usage.


  • Path - path to the log file; if empty, logging is turned off

  • Append - true - after the program is started, logging continues in the already existing file; false - logging to a newly created file, the old one is deleted

  • MinLevel - the logged information minimum level (analogous to a LogLevel.Default - enables additional configuration out of the default settings)

  • FileSizeLimitBytes - maximum file size when cyclic logging is used; 0 means without cyclic logging

  • MaxRollingFiles - file count when cyclic logging is used

Kestrel section

In Kestrel section and it’s Endpoint subsection, you can define the IP address and port on which the app will receive requests to store the recordings. The settings has to be the same as for AS7 PBX. Default port is 4080.

AllowedHosts section

In this section, you can define the hosts, which can request communication towards the recording service. It’s a safety mechanism, you can use DNS or IP of AS7 PBX. Default is ‘*’ , which means all communication is allowed.

As7Recording section

This section contains definitions of recording rules for particular tenants. “Tenants” key contains a list of particular tenants and their configuration. Tenant configuration contains keys:

  • Name: tenant ID, same format as listed in PBX administration

  • ConnectionString - connection string for tenant database

  • DatabaseType - SQL database type

  • DebugIndicators - log switches settings

  • RecordingOptions section - recording parameters settings * InstanceKey - recording instance identifier, it has to be the same as in the database * ProcessingDelay - delay between periodic operations (dynamic params change in database etc.) * TempPath - TEMP folder path, which is needed for temporary files saving (not necessary in every case)

TraceListener section

FilePath parameter sets the path for storing the trace log.


Second part of the settings is described in the database section RecordWeb service settings


AS7 Record Service uses the FrontStage database to store the metadata and its own configuration. In particular cases, the database can be also used to store the records.

  • AS7 Record Service configuration - see below

  • Metadata are stored to Voicerecord table

  • Recordings can be saved as binary data in the database or to Azure Blob storage

    • If Azure Blob storage is not configured, the database will be used (not optimal for system performance)

RecordWeb service settings

In the database, you have to define the recording device (Device table), create one database record in the Storage table (backward compatibility with SRec V3) and in case it’s used, configure the Blob storage (Device table)

Recording device

In the Device table, create the record:

  • DeviceType = “RecWebActive”

  • DisplayName = anything, for example “SRec AS7 recording”

  • MachineGroup = null

  • ConfigurationJson = null

  • OnLineStatus = 0

  • Deleted = false / 0

  • InstanceKey - has to be the same as InstanceKey in appsettings.json (default 1)


In the Storage table create the record:

  • DisplayName = anything, for example “SRec voice storage”

  • SystemName = “Voice”

  • InstanceKey - has to be the same as InstanceKey in appsettings.json (default 1)

  • FilePath - fake path to the storage, for example C:Temp

Blob storage

In the Device table create a record based on the blob device creating rules.

An example of record for File Hierarchy = Storage (storing to the folder)

  • DeviceType = “StorageFileHierarchy”

  • InstanceKey = DeviceRank has to be the same rule as for ContentCondition

  • ConfigurationJSON = { “RootDirectoryPath”: “c:AtlantisRecords” }

In the ContentCondition table create the appropriate rule. Record example:

  • Action = “Store”

  • ItemType = null / “VoiceRecord”

  • Target = 0 / instanceKey “RecWebActive” device

  • Rank = 10

  • DeviceRank = InstanceKey “storage” device, see settings for “Storage” device above

Matching iCC

A service, which pairs the metadata in the database (VoiceRecord table) with the information about inbound and outbound calls (InboundCall table). The result is that users are able to play the records, including option to see relevant metadata and corresponding events. That means this service is the connection point between Frontstage and recording service (pairing results in CallRecord table)

Service parameters in appsettings.json :

  • LoadMode - the way of uploading the records from iCC for comparison

    • Full - all the records from the beginning (batch of N records) - size of the batch is determined by MaxCountRecord parameter

    • Realtime - last N minutes of records - time span is determined by MaxMinuteBefore

  • ScoringMode - the way of scoring the records

    • PRONGX - the scoring where important values are local number and external number, time and length of the call

    • VIDICODE - the scoring where important values are local number and external number, call direction, time and length of the call

    • SIPTRUNK - the scoring where important values are external number, call length, call direction. Recording device is located before PBX (recording of all the workplaces, including IVR and transfer)

    • INTERNAL - the scoring where important values are local number, external number and call length. Recording device is located after PBX (recordings of particular workplaces)

    • ISDN - the scoring where important values are external number, call time and call direction. Adjusted for recording device located before PBX.

    • FRAGMENTEDSIPTRUNK - the scoring where important values are external number, call time and call direction. Recording device located before PBX, calls fragmented after N minutes.

  • ProcessMode - the way of processing the scored recordings from the iCC’s perspective

    • N2One - N iCC records can be paired with one recording (primarily for recording located before PBX)

    • One2N - one iCC record can be paired with N recordings (primarily for recording located after PBX)

  • ProcessingDelay - pause between particular comparison runs [ms]

  • ICCConnectionString - “connection string” to iCC database

  • MaxMinuteBefore - delay of loading the records related to actual time [m]

  • MaxCountRecord - maximum number of records in one batch

  • DataMode - the way of loading the records

    • SINGLETICKET - combination of VoiceRecord and Ticket record. If a File record has assigned more than one Call record, every Call record is scored separatelly.

    • GROUPTICEKT - combination of VoiceRecord and Ticket record. If a File record has assigned more than one Call record, Call records will be grouped.

  • NGXOverTime - approximate time overlap used for the iCC record lookup [m]

  • ProNGXConnectionString - connection string for ProNGX database

  • CompareFromDate - date, from which the FULL re-pairing will be performed [DD.MM.YYYY]

  • CheckAttributes - information, which should be used for pairing




    • TIME


  • InstanceKey - only records with appropriate InstanceKey are loaded from SRec, if the value is 0 - parameter is omitted

  • PairingAutoCalls - if TRUE then also automatical outbound calls will be paired

  • CreateTranscriptionRequest - if TRUE then after succesfull pairing text transcription is automatically requested - table Transcription

  • LocalNumberLen - maximum length of compared local number, if the number exceeds the set value, it will be shortened from right

  • ExternalNumberLen - maximum length of compared external number, if the number exceeds the set value, it will be shortened from right

  • PairingLostCalls - pairing also handles Lost calls from InboundCall table


Storage can be set in database, Device table. Storage rules can be set in ContentCondition table.

Storage options:

  • Azure Blob Storage - cloud storage

  • local File system

  • in the database as binary files