---
version: "2.1"
language: "en"
---
# STAGE 2.1
This section describes the intention and general approach of STAGE.
## General Overview
STAGE is Riedel's new generation software platform to manage server-based applications that can run on different types of computer platforms such as mini PCs, on-prem servers and virtual machines.
After the Virtual SmartPanel (VSP), the first product on this new platform, comes SAME -- the Smart Audio \& Mixing Engine. STAGE is used for both Configuration, Operation and Monitoring of these new Riedel products.
STAGE is the central brain that brings various elements together such as SAME, Virtual SmartPanel app, Artist-1024, WebRTC Server, as well as 3rd party authentication system and 3rd party monitoring solutions.
STAGE introduces a new and intuitive browser-based user interface, accessible via off-the-shelf web browsers so there is no need for a client application to be installed on Client computers.
STAGE has the following key functionalities such as:
* The ability to connect to Company User Database using either External User Directory or Identity Provider to support Centralized Authentication services.
* The ability to create individual User as well as Group Permissions to control access to STAGE and Virtual SmartPanel.
* The ability to discover NMOS devices and to process their AES67 / SMPTE ST 2110-30 audio signals using the Smart Audio Mixer Engine (SAME).
* The ability to create Jobs which defines the collection of resources required for a Production or a live event. The configuration of all Devices and Applications as well as connections between inputs (consumers) and outputs (producers) that are specific to a production (or an event) lives inside a Job. Jobs can be activated wherever the necessary resources are available.
* The ability to collect extensive Metrics and Logs that can be integrated into 3rd party tools e.g. to create various monitoring dashboards.
STAGE is a brand-new architecture made of multiple containerized services, which allows it to scale and grow as we continue, in the future, to add support for more devices and services. STAGE follows EBU143 security recommendations.
---
version: "2.1"
language: "en"
---
# Monitoring STAGE with Third Party Applications
List of third-party APIs supported by STAGE in version 2.1.
To be able to use the APIs of third-party providers, it is essential to enable third-party access and assign a password when configuring the suite in the Riedel Software Manager.
| **Name** | **Feature** | **Link** |
|----------------|----------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Prometheus** | Collecting STAGE metrics. | The base authorization access to metrics is via "**https://\[stage-fqdn\]:port/metrics** " and can be enabled via the suite configuration. Link to Homepage: |
| **Loki** | Collecting STAGE log data. | The base authorization access to logging is via "**https://\[stage-fqdn\]:port/logging** " and can be enabled via the suite configuration. Link to Homepage: |
---
version: "2.1"
language: "en"
---
# Adoption Setup
When an **Adoption** is selected in the **Job List**, the following configuration tabs are shown:
Adoption Selection
## Devices Tab
To be able to activate a Job, at least one Adoption must first be created. It defines which System Devices that are available to STAGE will be used as devices for that Job by adopting the Job Devices to System Devices. By having multiple Adoptions, the user has the option to run the same Job using different hardware. This can be useful when wanting the ability to run a Job from various studios or facilities.
### Overview
###  Jobs
Collapsed Jobs section, where the "Default Adoption" of the Job "my new Job" is selected.
The name of the selected "Job / Adoption" is displayed in the header of this Setup tab.
###  Job Devices
|  | Set a filter to display only content whose search text is found in the name. |
|  | Shows/Hides Job Devices that are already adopted to a System Device. |
| **Job Device** | This section lists all Job Devices that have been added in the [Configuring a Job Setup \| Resource Creation Tab](https://manuals.riedel.net/en/stage/2.1/configuring-a-job-setup.md#Resource-Creation-Tab) \> Devices tab. |
| **Device Type** | Shows the type of the Device. |
| **Adopted System Device** | Shows the System Device that is adopted to the corresponding Job Device. The System Devices are added in the System Commissioning: I/O Management \> Virtual Devices |
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
###  Filter (Job Devices)
Filter the Job Devices. See chapter [Getting Familiar with the User Interface \| Filtering](https://manuals.riedel.net/en/stage/2.1/get-familiar-with-the-user-interface.md#Filtering) for more information.
###  Adoption Buttons
|  | Click to unselect all selected Devices. |
|  | Click to adopt the selected Devices. First select a Job Device and a System Device to be adopted. |
|  | Click to remove the adoption of the selected Devices. First select a Job Device and a System Device to be unadopted. |
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------|
###  System Devices
|  | Set a filter to display only content whose search text is found in the name. |
| **Show Incompatible System Devices** | By default, System Devices that are not compatible with a Job Device selected in the Job Devices section are hidden. When this option is enabled, all available System Devices are listed regardless of the selected Job Device. |
|  | Shows/Hides System Devices that are already adopted to a Job Device. |
| **System Device** | This section lists all System Devices (Virtual Devices) that have been added in the [STAGE_ I/O Management](https://riedelcommunications.atlassian.net/wiki/spaces/ROHC/pages/951615746/STAGE_+I+O+Management) tab. |
| **Device Type** | Shows the type of the Device. |
| **Adopted Job Device** | Shows the Job Device that is adopted to the corresponding System Device. |
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
#### Creating an Adoption between a Job Device and a System Device
1. Select an "Adoption" to configure in the Job List.
2. Select the "Devices" tab.
3. Select a Job Device.
4. To create an Adoption for a Device,...
1. drag a **Job Device** onto a **System Device** or
2. select a **System Device** and click the adopt  button.
By doing so, the selected System Device shall be used (if available) when the Job is activated.
## Applications Tab
Applications run on hosts (e.g. SAME DSP Engine ). In this tab, you can verify the availability of Applications provided by registered hosts. In doing so, you can compare the applications requested by a Job against what the entire system is able to provide.
In addition, you can add a location constraint and force STAGE to only adopt Applications coming from registered host(s) in that location.
### Overview
###  Jobs
Collapsed Jobs section, where the "Default Adoption" of the Job "my new Job" is selected.
The name of the selected "Job / Adoption" is displayed in the header of this Setup tab.
###  Location
|  | Set a filter to display only content whose search text is found in the name. |
| **Show All Locations** | By default, Locations that are not involved in the selected Adoption are hidden. When this option is enabled, all Locations are listed regardless of the selected Adoption. |
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
You can add a Location Constraint and force STAGE to only adopt Applications coming from registered host(s) in that location.
#### Setting and Deleting an Constraint
Click on the  open lock icon that appears when hovering the mouse over a Location.
A Constraint is displayed above the Locations and by the  locked icon to the right of the corresponding Location.
Click on the  of the corresponding Contraint to delete it.
###  Application Availability
| **All** | Shows all Application Types. |
| **\[Application Groups\]** | Shows only Applications of the corresponding Type: **Meters and Analyzers** , **Mixers** , **Shufflers** , **Voice Overs** , **Generator and Players**. |
|  | Set a filter to display only content whose search text is found in the name. |
|  | Indicates the availability of the Applications:  : Indicates that the number of available resources is sufficient.  : Indicates that the number of available resources is less than the requested number of job resources.  : Indicates that the resource is not available. |
| **Application Type** | Shows the Application type. |
| **Requested in Job** | Shows how many Applications of that type are defined in the Job. |
| **Used in Job** | Shows how many Applications of that type are currently in used in that Job. This number can only be different from zero if the Job is active. |
| **Available / Total** | **Total:** Shows the total number of Applications of that type that are provided by the various registered hosts (e.g. SAME DSP engine). **Available:** Shows the number of applications of that type that are currently available. This number may be less than the total number if other Jobs are active and are using these Applications. |
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
1. Select an Adoption to configure in the Job List.
2. Verify Application Availability.
3. Compare the list of Applications requested in the Job against the total number of applications in the system.
4. Compare the list of Application requested in the Job against the currently available quantity.
5. Optionally, add a Location constraint.
If STAGE does not have the required processing resources to run the suite of Applications necessary for a Job, you have the following options:
* Modify the Job to use different or fewer number of Applications.
* Remove location constraint, if present, so that STAGE can adopt Applications from a wider range of hosts.
* Go back to System Commissioning, and register additional hosts to increase the the total number of Applications that the system can provide.
* In the case of a SAME DSP Engine, go back to System Commissioning and activate a different volume that provides a different mix of applications.
* Do nothing, as this can be a transitory situation. For example, the **Total** number of applications that the STAGE system provides may be enough, but other Job(s) may be active that reduces the **Available** number of applications.
---
version: "2.1"
language: "en"
---
# Artist-1024 Configuration
For more information about Artist-1024 Host Configuration, see VSP [Artist-1024 Configuration](https://manuals.riedel.net/vsp?contextKey=vsp_-artist-1024-configuration&version=latest&language=default).
---
version: "2.1"
language: "en"
---
# Audio Pilot
This view allows selecting and managing the various DSP configurations to access their control user interfaces across all running Jobs and accessing audio monitoring and selecting the monitoring source when working with SAME Audio Tools within Jobs.
To configure the SAME DSP Engine, see SAME [Audio Pilot](https://manuals.riedel.net/same?contextKey=same_-audio-pilot&version=latest&language=default) and [Audio Pilot Tiles](https://manuals.riedel.net/same?contextKey=same_-audio-pilot-tiles&version=latest&language=default).
---
version: "2.1"
language: "en"
---
# Managing Security Certificates
A running STAGE deployment provides three certificates:
* Management Certificate
* HTTPS Certificate
* User Directory Certificate
## Management Certificate
The Management Certificate is created during the Cluster Setup and is used to encrypt the traffic between Riedel Software Manager and the Cluster.
Whenever RSM wants to connect to a STAGE Cluster, the user needs to provide the **Management Certificate.**
Users need to Download the Management Certificate during Cluster creation or when currently connected to a cluster.
To connect to a Cluster, the URL/IP needs to be known, and the previously downloaded Management Certificate needs to be uploaded to RSM.
The Management Certificate is a RSM specific file that contains both Certificate and Key and has a **.management-certificate** extension, to not be mistaken with other types.
Which installations will need to do this?
* Every installation
When?
* Reconnecting to a running or broken cluster for cluster maintenance:
* Troubleshooting
* Updates
* Monitoring
* Backup/Restore
## HTTPS Certificate
The HTTPS Certificate is created during cluster creation and is used after the STAGE Suite is deployed. It is used to encrypt the data between STAGE Webserver and the PC that is running the browser and the VSP Connections. More usecases might occur in the future.
### Using the self signed certificate
STAGE uses a self signed certificate in the initial deployment which guarantees encryption, but potentially allows Man-in-the-middle attacks, as the Certificate cannot be validated by the Browser or the Phone. This leads to known security warnings.
To get rid of Security Warnings, the HTTPS self signed certificate can be downloaded from RSM and imported into the Browser / VSP.
Importing into Browsers / Phones varies depending on Browser and OS.
The File that is downloaded via RSM is a **.crt**file, including the Public Certificate from the Webserver.
Which installations will need to do this?
* Installations that don't have an official certificate and do not want to see security warnings in browsers.
* VSP users that do not have an official certificate.
When?
* Each new Browser that is used.
* Each new VSP that is used.
Do I need to do something after an update?
* No, if the cluster is untouched, you do not need to redo all the exports.
### Providing an official certificate
Larger customers might have acquired a proper certificate chain from official providers. It is then possible to replace the HTTP Certificate in STAGE with a certificate issued for this installation. Typically Certificates are issued on hostnames, either explicitly or with a wildcard. IP Addresses are also possible but not recommended.
* stage.riedel.net
* \*.riedel.net (not recommended)
* 192.168.1.1 (not recommended)
Customers can then Replace the HTTPS Certificate in a running deployment via the Riedel Software Manger to get rid of security warnings without needing to import the certificate into all browsers
As the Certificate is trustable, Browsers and VSP can validate the signature.
The file that needs to be uploaded, is a **.pem** Certificate **Chain,**including Private key, Server cert, Intermediary ca's and Root ca in that order.
Which installations will need to do this?
* Installations that have an official certificate should do this
* It is a one time action and removes the effort of importing certificates into browsers / VSPs
When?
* After Cluster Creation
Do I need to do something after an update?
* No, if the cluster is untouched, you do not need to redo all the exports.
## User Directory Certificate
The User Directory Certificate is used to encrypt traffic between an external Active Directory and STAGE.
STAGE allows only encrypted connections to external Active Directories.
If a customer uses an Active Directory that is using a self-signed-certificate and not an official one, STAGE needs to be configured to trust this certificate by importing it into the deployment. After import, Connections to the Active Directory can be encrypted based on this trust.
Customers that use an official certificate in their Active Directory, do not need to provide this to STAGE, as STAGE can validate the Certificate out of the box.
Which installations will need to do this?
* Installations that have want to use an external Active Directory.
* The Active Directory does not use a trusted certificate.
When?
* After Suite Deployment, before connecting an Active Directory.
* After each Update, that includes an update of the Keycloak Service.
Do I need to do something after an update?
* Yes, if the Keycloak Service is updated, the Certificate needs to be imported again.
---
version: "2.1"
language: "en"
---
# Client Computer Requirements
## Client Operating System
As the operation of STAGE is browser-based, it is not necessary to use a defined operating system. Any operating system that supports standard internet browsers can be used (e.g. Windows 10/11 (64-bit), macOS 13+, or latest Linux).
## Supported Browser versions
STAGE supports the standard Browsers Microsoft Edge and Google Chrome. Other browsers might work, but have they not been tested.
Minimum version of the web browser:
* Google Chrome 80+
* Microsoft Edge 66+
For secure and stable operation, it is necessary to keep the browser version up to date in accordance with the provider's recommendations.
## Hardware Specifications
### Recommended System Requirements
* **Processor**:
* minimum: Intel i5 8th gen / Ryzen 3 / Apple M1
* recommended: Intel i7 11th gen / Ryzen 5 / Apple M2+
* If several plugins and the WebRTC connection are used for a VSP, it is advisable to have a suitable CPU.
* **Memory (RAM)**:
* minimum: 16 GB
* recommended: 32 GB or more
* **Storage**: 4 GB free disk space
* **Display**: Full HD (1920x1080) or higher
* **Internet Connection**: Stable broadband (10 Mbps+)
* **GPU**: Integrated or discrete GPU for hardware acceleration (optional, for better performance)
---
version: "2.1"
language: "en"
---
# Compatibility List
Overview of the compatible software versions for the respective releases.
| **STAGE Version** | **STAGE Suite File Version** | **SAME DSP-Engine Suite File Version** | **WebRTC Gateway Suite File Version** **(Supported Artist Version)** | **Debian 12 Node File Version** | **Riedel Software Manager File Version** | **Virtual SmartPanel App File Version** |
|-------------------|------------------------------|----------------------------------------|----------------------------------------------------------------------|---------------------------------|------------------------------------------|-----------------------------------------|
| STAGE Version 2 |||||||
| 2.1.0 | 2.**1.0** | 1.**1.8** | 1.2.**3** (8.9 \& 9.0) | 2.**1.0** | 1.**2.0** | Android 1.**1.0** / iOS 1.**1.0** |
| 2.0.1 | 2.0.**1** | 1.0.5 | 1.2.1 (8.8 \& 8.9) | 2.0.0 | 1.1.0 | Android 1.0.2 / iOS 1.0.2 |
| 2.0.0 | 2.0.0 | 1.0.5 | 1.2.1 (8.8 \& 8.9) | 2.0.0 | 1.1.0 | Android 1.0.2 / iOS 1.0.2 |
| STAGE Version 1 |||||||
| 1.0.3 | 1.0.**3** | Not Applicable | 1.1.4 (8.8 \& 8.9) | 1.1.0 | 1.0.1 | Android / iOS 1.0.2 |
| 1.0.2 | 1.0.**2** | Not Applicable | 1.1.**4** (8.8 \& 8.9) | 1.1.0 | 1.0.1 | Android / iOS 1.0.2 |
| 1.0.1 | 1.0.**1** | Not Applicable | 1.1.**2** (8.8 \& 8.9) | 1.1.0 | 1.0.**1** | Android / iOS 1.0.**2** |
| 1.0.0 | 1.0.0 | Not Applicable | 1.1.1 (8.8 \& 8.9) | 1.1.0 | 1.0.0 | Android / iOS 1.0.1 |
Note that Artist is an external dependency that is not part of STAGE. However, the current Artist version must be compatible with the WebRTC version to ensure interoperability for use with the Virtual SmartPanel App.
---
version: "2.1"
language: "en"
---
# Configuring a Job Setup
When a **Job** is selected in the **Job List**, the following configuration tabs are shown:
Job Selection
For more information about Jobs, see [Jobs](https://manuals.riedel.net/en/stage/2.1/jobs.md).
## Resource Creation Tab
This tab is the wish list of items to be used for various productions. Here, it is determined what is to be done in a production by specifying the Devices and Applications to be used.
### Overview
###  Jobs
Collapsed Jobs section, where the Job "my new Job" is selected.
The name of the selected "Job" is displayed in the header of this Setup tab.
###  Resources
| **Roles /** **Devices / Applications** | Tabs to create Roles and assign Roles, Devices and Applications to Jobs. |
|  | Set a filter to display only content whose search text is found in the name. |
|  | Click to delete the selected user defined Role (available for Roles only). Global Roles are edit in the System Management and cannot be deleted in this view. |
|  | Click to add a user defined Role. |
| **Name** | The name of the Role, Device or Application. (Depending on the selected tab.) Double-click the name of a user defined Role to rename it. |
| **Members in Job** **/ In Job** | Shows the number of Members, Devices or Applications assigned to a Job. (Depending on the selected tab.) |
|    | Click to add the set number of Members to Role or Devices/Applications to a Job. (Depending on the selected tab.) |
|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------|
**Member:** Represents a single participant in a Production Event. A Member always has a Role, and a Job can consist of multiple Members using the same or different Roles. For example, Technical Director, Audio Engineer 1, Camera Operator 1, Camera Operator 2.
**Roles:** Categories of people that participate to Productions. Roles are used to create Members.
For example, Technical Directors or Audio Engineers.
A particular Role can be global to entire STAGE system or only exist in the context of a particular Job.
**Device:**Specifies the hardware needed for the Job. During Activation, when a Job is run, the actual available hardware will be used to send and receive audio signals.
**Applications:** Specifies the audio signal processing needed for the job to process, mix, and master sound. Applications emulate classic hardware in software and they run on the SAME DSP-Engine server when the Job is activated.
###  Job Content
| **All** | Shows all Resources assigned to the selected Job. |
| **\[Resource Groups\]** | Shows only Resources of the corresponding Type: **Members, Devices, Applications, Producers /Consumers** |
|  | Set a filter to display only content whose search text is found in the name. |
|  | Click to unassign the selected Resource. |
| **All / In / Out** | In Producers/Consumers tab, filter to show all, incoming or outgoing Prosumers. |
| **Name** | The name of the Role, Device or Application. (Depending on the selected tab.) Double-click the name of a user defined Role to rename it. |
| **\[Column Names\]** | Depending on the selected tab, various columns with corresponding content are available. In total following columns are available: Type, Role, Devices, Applications, Producers/Consumers, Role/Member, Media Group |
|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
#### Right-Click Options
Depending on the selected tab, various options are available for the right mouse button.
| **Collapse All Items** | Only the parent group names will be displayed. |
| **Rename Selected \[...\]** | A dialog box opens, allowing to rename the selected items simultaneously and using automatic numbering. **Label:** New Name of the item. **Start Counting from:** Set the start value, the next values will be increased by one. **Add at Start/End:** Set if the numbering should be added as a prefix or suffix. **Add Leading Zeros:** Set if a zero should be added to one digit numbers. **Search/Replace:** User the Search Text and Replace Text to modify the names according to your requirements. **Add Text:** Set additional Text to be added as prefix or suffix. |
| **Delete Selected \[...\]** | A dialog box opens to confirm the deletion of the selected items. |
|-----------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
###  Filter (Job Content)
Filter the Job Devices. See [Getting Familiar with the User Interface \| Filtering](https://manuals.riedel.net/en/stage/2.1/get-familiar-with-the-user-interface.md#Filtering).
### Using the Resource Creation Tab
#### Adding a Resource to a Job
A Job normally requires resources from each of the tabs in Resource Creation.
1. Select a Job to configure in the Job List.
2. Select the Resource Creation tab.
3. Select a tab under Resource Creation for the resource type you want to add to the Job
(Roles tab / Devices tab / Applications tab).
4. To add a resource,...
1. click a resource and drag it to the **Drop Here** landing spot or
2. enter the number of desired resources and click the **Add Members/Devices/Applications**button.
5. Repeat this for each of the Resource Creation tabs (Roles tab / Devices tab / Applications tab).
## Resource Configuration Tab
Once Applications have been added to a Job in the Resource Creation tab, they can be configured in the Resource Configuration tab.
### Overview
###  Jobs
Collapsed Jobs section, where the Job "my new Job" is selected.
The name of the selected "Job" is displayed in the header of this Setup tab.
###  Job Applications
|  | Set a filter to display only content whose search text is found in the name. |
| **Hide Roles and Members** | Hides the group name to which the Application belongs. |
| **Application Name** | List of all Applications assigned to the selected Job. Click on an Application to display it on the right-hand side in the Application Configuration. |
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------|
###  Application Configuration
This defines the initial configuration of the Application that is to be applied to the adopted Application when the job is activated. For example, faders can be set to a preset level, channels can be muted, metering can be set to be pre-fader or post-fader, snapshots of setting can be created to be later recalled, and so on. By doing this, when a Job is run, the Application starting configuration is suited to the production's needs and workflows.
An overview of all available SAME Applications can be found in Chapter [SAME Application Configuration](https://manuals.riedel.net/same?contextKey=same_-same-application-configuration&version=latest&language=default).
|  | Click to maximize the application to full screen. |
|  | Click to restore the application from full screen. |
|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------|
### Using the Resource Configuration Tab
#### Configuring a Resource
1. Select a Job to configure in the Job List.
2. Select the Resource Configuration tab.
3. Select an Application to configure in the Job Applications List.
4. Configure the Application.
5. Repeat this for each Application in the Job Applications List of a Job.
## Signal Management Tab
The Signal Management tab provides a XY Matrix that is used to connect the I/Os of the various Job Resources (Applications and Devices). The XY Matrix allows to connect a Source (Producer) to a Destination (Consumer).
### Overview
Both the source and destination sections are not flat lists, but follow a structure consisting of Device → Prosumer group → Prosumer. See an example in the graphic above: The expanded Mixer (Destination) consists of a "Channel Input" and an "Insert Return" Consumer group. And the expanded "Channel Input" and "Insert Return" group contain a list of Consumers.
Moreover, the XY Matrix provides additional capabilities such as inserting a processing application (called network plugins) between a connected Source and Destination (i.e. crosspoint).
Finally, the XY Matrix allows to map individual legs when connecting multi-legged producers and consumers. When using this with SAME, this allows to map/shuffle audio channels, for example:
* map any audio source to any destination.
* repeat any any audio channel any number of times.
* establish the position of an audio the channel to any destination.
###  Jobs
Collapsed Jobs section, where the Job "my new Job" is selected.
The name of the selected "Job" is displayed in the header of this Setup tab.
###  Connection Matrix
| **Prosumer Header** ||
| **Search** **Destinations / Sources** | Set a filter to display only content whose search text is found in the corresponding Destination/Source name. |
| **Sources** | The Sources (Producers) are located in rows and their names are displayed on the left-hand side. |
| **Destinations** | The Destinations (Consumers) are located in columns and their names are displayed on the top. |
|  | Click on this icon in the section with the Prosumer names to expand it and show its further sub-elements (e.g., prosumer groups under prosumers; devices under prosumer groups). |
|  | Click on this icon in the section with the Prosumers names to hide the sub-elements (e.g. prosumer groups under a device; prosumers under a prosumer group). |
| **Crosspoint Section** ||
|    | Click on these icons in the crosspoint section to expand and show more of the device's prosumers (i.e. consumers or producers). |
|  | Double-click to create a crosspoint, to connect a source signal to a destination. |
|  | Shows that a crosspoint has been made: all source channels (legs) are mapped to the connected destination. |
|  | Double-click to remove a connection. |
|  | Double-click to create a crosspoint, when there is no one-to-one connection. For example, a source has two channels and a destination is mono. You have to choose how to finalize the crosspoint audio signal connection(s) in the following window that opens.  Typical Crosspoint Process Window: Only one channel of a stereo pair source can be mapped to a mono destination. Here you choose the channel to use. |
|  | Shows that a crosspoint has been made: only some source channels (legs) are mapped to the connected destination. For example, a source has two channels and the destination is mono. |
|  \ Click | Add an effects process to the crosspoint. See [Crosspoint Process below](https://manuals.riedel.net/en/stage/2.1/configuring-a-job-setup.md#Crosspoint-Process). |
|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
### Using the Signal Management Tab
#### Connecting a Source to a Destination
1. Select a Job to configure in the Job List.
2. Select the Signal Management tab.
3. Click  to expand the source and destination signals that you want to connect.
4. Double-click a crosspoint to make the connection between a Source and Destination.
To clear a connection, double-click the crosspoint again.
5. Repeat this for all necessary signal connections.
#### Editing a Crosspoint
Right-click a crosspoint to edit it.
|---------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Connect Straight 1:1** | Select to connect the crosspoint signal straight through. |
| **Crosspoint Patching** | Select to change the crosspoint connection, when there is no one-to-one connection. For example, a source has two channels and a destination is mono. You have to choose how to finalize the crosspoint audio signal connection(s) in the following window that opens. This option allows you to change this setting.  Typical Crosspoint Process Window: Only one channel of a stereo pair source can be mapped to a mono destination. Here you choose the channel to use. |
| **Add/Change Network Plug-in** | Select to edit the network plug-in. See [Crosspoint Process below](https://manuals.riedel.net/en/stage/2.1/configuring-a-job-setup.md#Crosspoint-Process). |
| **Remove Network Plug-in** | Select to remove that network plug-in from this crosspoint. |
| **Disconnect/Reset Crosspoint** | Select to clear / disconnect the crosspoint. |
#### Right Click Context Menu
|------------------------------------------------|-------------------------------------------------------------------------------------------------------|
| Destination Group - \[Destination Group Name\] | Shows the Consumer's group name. |
| Focus on Sources Focus on Destinations | Activates the connections for the selected producer or consumer, when possible. |
| Disconnect all Sources | Disconnect all connections to any Producer from this Consumer, including ones with Network Plug-ins. |
| Disconnect all Destinations | Disconnect all connections to any Consumers from this Producer, including ones with Network Plug-ins. |
| Reset all Filters | Reset all filters which are active on the device's Producer / Consumer groups |
| Collapse Group | Collapses all of the device's Producer / Consumer Groups. |
| Collapse other Groups | Collapses any other expanded Producer / Consumer Groups, but leaves the current one untouched. |
### Crosspoint Process
Certain crosspoints support processing effects. Hold shift while clicking the crosspoint to open a window that shows the available processing effects, when available.
Typical Crosspoint Process
Select a processing effect and then click  .
|----|-----------------------------------|---------------------------------------------------------------------------------------------------------------------------------|
| 1 | **Brickwall Limiter - True Peak** | See SAME [Network Plug-ins](https://manuals.riedel.net/same?contextKey=same_-network-plug-ins&version=latest&language=default). |
| 2 | **Brickwall Limiter** | See SAME [Network Plug-ins](https://manuals.riedel.net/same?contextKey=same_-network-plug-ins&version=latest&language=default). |
| 3 | **Channel Strip Leveller** | See SAME [Network Plug-ins](https://manuals.riedel.net/same?contextKey=same_-network-plug-ins&version=latest&language=default). |
| 4 | **Channel Strip Standard** | See SAME [Network Plug-ins](https://manuals.riedel.net/same?contextKey=same_-network-plug-ins&version=latest&language=default). |
| 4 | **Channel Strip Standard Plus** | See SAME [Network Plug-ins](https://manuals.riedel.net/same?contextKey=same_-network-plug-ins&version=latest&language=default). |
| 5 | **Channel Strip Voice** | See SAME [Network Plug-ins](https://manuals.riedel.net/same?contextKey=same_-network-plug-ins&version=latest&language=default). |
| 6 | **Channel Strip Voice Leveller** | See SAME [Network Plug-ins](https://manuals.riedel.net/same?contextKey=same_-network-plug-ins&version=latest&language=default). |
| 7 | **Compressor / Limiter** | See SAME [Mixer Effects](https://manuals.riedel.net/same?contextKey=same_-same-mixer-effects&version=latest&language=default). |
| 8 | **De-Esser** | See SAME [Mixer Effects](https://manuals.riedel.net/same?contextKey=same_-same-mixer-effects&version=latest&language=default). |
| 9 | **Delay 10 Seconds** | See SAME [Network Plug-ins](https://manuals.riedel.net/same?contextKey=same_-network-plug-ins&version=latest&language=default). |
| 10 | **Expander / Gate** | See SAME [Mixer Effects](https://manuals.riedel.net/same?contextKey=same_-same-mixer-effects&version=latest&language=default). |
| 11 | **K-Leveller** | See SAME [Mixer Effects](https://manuals.riedel.net/same?contextKey=same_-same-mixer-effects&version=latest&language=default). |
| 12 | **Level Perfect** | See SAME [Mixer Effects](https://manuals.riedel.net/same?contextKey=same_-same-mixer-effects&version=latest&language=default). |
| 13 | **Parametric Equalizer** | See SAME [Mixer Effects](https://manuals.riedel.net/same?contextKey=same_-same-mixer-effects&version=latest&language=default). |
| 14 | **Spectra-Match** | See SAME [Mixer Effects](https://manuals.riedel.net/same?contextKey=same_-same-mixer-effects&version=latest&language=default). |
---
version: "2.1"
language: "en"
---
# Default Ports
STAGE uses services that are assigned to use ports for inter-server communication channels at runtime. Once a port has been assigned for use by a service on a server, that port cannot be used by another service when communicating to that server.
See:
* SAME: See SAME [Default Ports](https://manuals.riedel.net/same?contextKey=same_-same-dsp-engine-default-ports&version=latest&language=default).
* Virtual SmartPanel: See VSP [Default Ports](https://manuals.riedel.net/vsp?contextKey=vsp_-virtual-smartpanel-default-ports&version=latest&language=default).
The Riedel Software Manager has specific requirements for the ports that must be open during software deployment, installation, and maintenance. See RSM [Deployment Ports](https://manuals.riedel.net/rsm?contextKey=DeploymentPorts&version=latest&language=default).
---
version: "2.1"
language: "en"
---
# System Commissioning
System Commissioning
Menu
System Commissioning
Home
The System Commissioning consists of the following views:
* [Registration](https://manuals.riedel.net/en/stage/2.1/kj-registering-devices.md)
This view allows registering hosts such as WebRTC Gateway servers, SAME DSP Engines, NMOS, and Artist-1024 devices that have been discovered on the network to make the device's resources available for use within STAGE.
* [Host Configuration](https://manuals.riedel.net/en/stage/2.1/kj-setting-the-device-s-configuration.md)
This view allows setting the configuration parameters of each registered host.
* [I/O Management](https://manuals.riedel.net/en/stage/2.1/i-o-management.md)
I/O Management consists of mapping Hardware Devices to Virtual Devices. Hardware Devices represent the I/O Structure of a registered Host. Virtual Devices are used to represent elements of the real world (for example, a Mono Microphone) that are not directly visible to STAGE.
System Commissioning is normally done during STAGE deployment.
---
version: "2.1"
language: "en"
---
# System Configuration
This view allows configuring basic STAGE system settings and viewing information such as serial number and package versions.
## Overview
System Management - System Configuration
## Using the System Configuration view
### How to change this STAGE Instance's System Name
1. In section [System Configuration \| General Settings](https://manuals.riedel.net/en/stage/2.1/discovery.md#General-Settings), set the new unique name for this STAGE instance in **System Name**.
2. Click **Save**.
### How to Enable / Disable the Use of STAGE's Built-in User Management Identity Provider Database
When using an external Identity Provider or User Directory for login, the creation of Local Users can be disabled to prevent the creation of a hybrid login environment for security reasons.
1. In section [System Configuration \| User Management](https://manuals.riedel.net/en/stage/2.1/discovery.md#User-Management), configure the **Disable Local Users** parameter.
**Set:** Disabled to prevent the creation of a hybrid login environment for security reasons. Only disable Local Users if a functioning Identity Provider or User Directory is configured. See chapters [System Configuration \| User Management](https://manuals.riedel.net/en/stage/2.1/discovery.md#User-Management) and [User Directories](https://manuals.riedel.net/en/stage/2.1/user-directories.md).
**Disable:** Use STAGE's built-in User Management database for User Login. See chapter [STAGE_ User Management](https://riedelcommunications.atlassian.net/wiki/spaces/ROHC/pages/270579469/STAGE_+User+Management) .
2. Click **Save**.
##  STAGE Settings
When you have multiple STAGE instances, each STAGE instance needs a unique name to disambiguate this instance from other instances.
### General Settings
#### STAGE System
This section contains information about this STAGE instance.
|-------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **System Name** | Set the unique name by which this STAGE instance will be known on the network. |
| **Serial Number** | Shows the unique identifier for this STAGE software instance. This identifier is used for licensing purposes to make a one-to-one association between a given license and a specific installation. |
| **System ID** | Shows the unique identifier for the hardware running this STAGE instance. This identifier is used for licensing purposes to make a one-to-one association between a given license and a specific installation. |
#### Versions
An overview of versions of STAGE components used in this instance. To update Riedel STAGE, connect to the Cluster using Riedel Software Manager.
|--------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Suite Version** | Shows the version number for the current STAGE software suite installed on the server(s). |
| **Packages** | Shows the list of individual STAGE packages that form the software suite. |
| **Third Party Licenses** | Clicking the "Open License Information" button will open the "Third-party Notice" website with detailed information about: * Riedel Applications included in the STAGE Suite * General Riedel License Information * Third-party Services * Third-party Licenses used in Riedel Applications * Third-party License Names / Identifiers and their Dependencies |
#### User Management
When using an External User Directory or Identity Provider, local users can be disabled to prevent circumventing centralized login mechanisms.
|-------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Disable Local Users** | When using an external Identity Provider or User Directory for login, the creation of Local Users can be disabled to prevent the creation of a hybrid login environment for security reasons. Only disable Local Users if a functioning Identity Provider or User Directory is configured. See [Identity Providers](https://manuals.riedel.net/en/stage/2.1/identity-providers.md) and [User Directories](https://manuals.riedel.net/en/stage/2.1/user-directories.md). |
### Discovery
#### Riedel Discovery
Discover Riedel Devices to manage them with STAGE.
|-----------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Enable Riedel Discovery** | Set to discover compatible devices using NMOS IS-04 to manage them with STAGE's internal NMOS Registry. |
| **Auto-Discover Riedel Registry** | Set to enable the discovery of supported Riedel hardware devices on the network and supported third-party devices. **Disabled:** Set the NMOS registry connection parameters below. **Enabled:**When your network has a working mDNS server, this allows devices to automatically discover and register themselves with STAGE's NMOS registry. |
| **Static Riedel Registry Host** | When **Auto-Discover Riedel Registry** is disabled, set the IP address of the Director instance to use. If Director is co-located on the STAGE server, use the localhost IP address: `127.0.0.1`. |
| **Static Riedel Registry Port** | When **Auto-Discover Riedel Registry** is disabled, set the port number used by Director. The default port number is: `6050`. |
| **Status** | Indicates whether the connection between STAGE and the Discovery Registry is connected (  ) or disconnected (  ). |
#### AMWA NMOS IS-04 / IS-05 Discovery
Discover and control 3rd party Devices through NMOS IS-04 and IS-05 to manage them with STAGE. This feature relies on a third-party, network-connected AMWA NMOS Registry being made available to STAGE. This can be done by installing the AMWA NMOS Registry component found in the *External Services* Suite, using the Riedel Software Manager (RSM). See [STAGE Installation](https://manuals.riedel.net/en/stage/2.1/stage-installation.md).
|--------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Enable NMOS Discovery** | Set to enable the discovery of the devices currently available in STAGE by an external NMOS Registry. **Disabled:** Set the NMOS registry connection parameters below. **Enabled:**When your network has a working mDNS server, this allows devices to automatically discover and register themselves with the NMOS registry on the network. |
| **Static Registry Protocol** | When **Enable NMOS Discovery** is enabled, set if the connection is to be encrypted or not. **HTTP:**The connection to the registry is unencrypted (clear text). **HTTPS:**The connection to the registry is encrypted to protect against eves-dropping or spoofing. |
| **Static IS-04 Registry Host** | When **Enable NMOS Discovery** is enabled, set the IP address that STAGE is to use to connect to an NMOS registry instance. |
| **Static IS-04 Registry Port** | When **Enable NMOS Discovery** is enabled, set the port number that STAGE is to use to connect to an NMOS registry instance (NMOS IS-04 registration API). The default port number is: `8010`. |
| **Query API Version** | Shows the version of the IS-04 query API that STAGE uses. Devices that use versions of the IS-04 Query API older than the version shown here will not be recognized in STAGE. |
| **Status** | Indicates whether STAGE is registered with the NMOS registry. |
### Metadata
#### Locations
Create, edit or rearrange Locations to organize Hosts and Devices in STAGE.
* Click  to quickly create top-level Locations.
or
* Click  to open the **Edit Locations** dialog to add/duplicate/delete locations and sub-locations.
This section corresponds to the Location settings in the [Registration](https://manuals.riedel.net/en/stage/2.1/kj-registering-devices.md) view and is described in detail there.
#### Global Roles
Roles can hold Members representing persons in a Job. Global Roles defined here will be available in all Jobs.
* Click  to quickly create a Global Role.
or
* Click  to delete the selected Global Role.
* The predefined Global Roles are mandatory and cannot be deleted.
Additional, job-scoped Roles can be created in each Job (see chapter [Job Setup](https://manuals.riedel.net/en/stage/2.1/job-setup.md)).
### Northbound APIs
When a registered host is in **Direct Control Mode**, a Broadcast Control System (BCS) can control it through the STAGE northbound APIs. The following APIs are available.
* NMOS IS-04 / IS-05 Registration
When enabled, this registered host will act as NMOS IS-04 / IS-05 Node that is used by the BCS to patch signals. See [Putting SAME Under Northbound Control](https://manuals.riedel.net/same?contextKey=same_-putting-same-under-northbound-control&version=latest&language=default).
For users of the Adobe Acrobat (PDF) version of this user guide, see *Enabling Northbound AMWA NMOS IS-04 and IS-05* in the **SAME User Guide** . See [STAGE Resources](https://manuals.riedel.net/en/stage/2.1/resources.md).
* STAGE Northbound API
The STAGE Northbound API enables remote control of Applications hosted by a STAGE system. It is available through gRPC and REST. See [STAGE Northbound API](https://manuals.riedel.net/stage?contextKey=stage_-stage-northbound-api&version=latest&language=default).
See [Putting SAME Under Northbound Control](https://manuals.riedel.net/same?contextKey=same_-putting-same-under-northbound-control&version=latest&language=default) for more information about how to set this up.
For users of the Adobe Acrobat (PDF) version of this user guide, see *Putting a SAME DSP Engine Under Northbound Control* in the **SAME User Guide** . See [STAGE Resources](https://manuals.riedel.net/en/stage/2.1/resources.md).
### STUN/TURN
STAGE is typically located behind a firewall (that uses Network Address Translation (NAT)) on your corporate network to protect it from bad-faith actors (hackers) on the public internet who could otherwise interfere with the normal operation of your networked equipment by trying to send commands to your software, with harmful effects.
STAGE communicates with software such as the Virtual SmartPanel (VSP), where it is understood that users will use the public internet in order to interact with STAGE. The following techniques allow STAGE and Virtual SmartPanel to communicate through the NAT to allow Peer-to-Peer (P2P) communication without compromising network security:
* **STUN:** *Session Traversal Utilities for NAT*; a network protocol that allows interactive UDP flows to pass through a NAT.
* **TURN:** *Traversal Using Relays around NAT*; a network protocol that allows STAGE (located behind a firewall) to control the operation of a relay server, that in turn, exchanges packets with Virtual SmartPanel, for example. TURN is used when a P2P connection cannot be established with STUN.
Both STUN and TURN require a server exposed to the internet with the STUN / TURN software running on it. The white paper with more detailed information can be found in the follwing chapter: VSP [Riedel STAGE™ \& Virtual SmartPanel® -- How to Implement STUN and TURN](https://manuals.riedel.net/vsp?contextKey=vsp_-how-to-implement-stun-and-turn&version=latest&language=default)
##  PRODUCT Settings
### VSP
#### AES67
Connected Artist and WebRTC Gateways will use these settings for AES67 media streaming used for Virtual SmartPanel connections.
| **Codec** | Set the audio sampling bit depth. **L16:** Linear PCM 16-bit depth. **L24:** Linear PCM 24-bit depth. |
| **Packet Time** | Set the duration of the audio data captured and transmitted in a single digital packet over a network. See for more information. Select one of: 125, 250, 333 or 1000 µs. |
| **Receive Buffer** | Selection of the size of the AES67 receive buffer to adapt the expected delay of connected panels. The default buffer is 8 × Packet Time. (3 ... 112 x packets) |
| **Preferred Sync Mode** | In **Strict** mode audio packets will be discarded if the PTP timestamp is missing or invalid. Hence only audio signals are output if they are transmitted in a PTP synchronized network. In **Adaptive** mode audio packets without or with invalid PTP timestamps are processed and output, hence this mode can be used in networks without PTP synchronization. This may lead to increased delay and jitter. |
|-------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
---
version: "2.1"
language: "en"
---
# Events
This view allows retrieving simple user information about the processes in the STAGE system, e.g. when a user logs in or when an operating limit has been exceeded (e.g. when more than 80% of the channels of the WebRTC gateway are used).
## Overview
System Health - Events
Filters allow you to quickly narrow-down a list to find a device.
See chapter [Getting familiar with the User Interface #Filtering](https://manuals.riedel.net/en/stage/2.1/get-familiar-with-the-user-interface.md#Filtering) for more information.
## Quicksteps for Displaying and Exporting Event Log Entries
1. If you deactivate the **Auto-Refresh** of entries, you can...
2. select either a **Time Range** or a **Custom Date Search** to narrow down the list of desired entries.
3. Optionally, you can filter for the desired information on the **Severity** , **User** and/or **Origin** tabs to narrow down the list of desired entries.
4. Optionally, you can filter the desired information according to the **Locations** where the event was triggered.
5. Optionally, you can filter by **Description**.
6. View all displayed entries according to the corresponding filter settings. See [Event Log Entries below](https://manuals.riedel.net/en/stage/2.1/events.md#Event-Log-Entries) for the available information.
7. To export the log entries...
1. Click on the **Export Filtered Events** button to save the log entries in a CSV file in the default download folder of your system. Only the currently visible entries are saved according to the current filter setting.
or
2. Click on the **Export System Logs** button to save the log entries in a ZIP file containing the individual log files. The filename is the time stamp of the occurrence of the event. In a dialog you can select the day on which the entries occurred. The existing entries are saved regardless of the current filter setting.
##  System Time, Auto-Refresh \& Export
| **System Time** | Displays the current date and time of the STAGE cluster (and is always UTC). |
| **Auto-Refresh** | Set if the display of event logs are to be automatically refreshed. **Enabled:**Event logs are automatically updated to display the latest log data when new entries are recorded. **Disabled:** Events logs are loaded when you enter this page or refresh the page in your browser, otherwise the logging data is static. The **Time Range** and **Custom Date Search** filters are deactivated if **Auto-Refresh** is switched on. |
| **Export Filtered Events** | Click to save the log entries in a CSV file in the default download folder of your system. Only the currently visible entries are saved according to the current filter setting. See [Event Log Entries below](https://manuals.riedel.net/en/stage/2.1/events.md#Event-Log-Entries) for the information stored in the CSV file. |
| **Export System Logs** | Click to save the log entries in a ZIP file containing the individual log files. The [Export System Logs Dialog below](https://manuals.riedel.net/en/stage/2.1/events.md#Export-System-Logs-Dialog) opens and allows to select the day on which the entries to be saved occurred. The existing entries are saved regardless of the current filter setting. The filename of the log files within the ZIP is the time stamp of the occurrence of the event. |
|----------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
### Export System Logs Dialog
The Export Logs dialog can be opened by clicking the **Export System Logs** button.
Export Logs dialog
|  | Click to set a date or date range for the log files that are to be downloaded. |
| **Collect and Download** | Click to save the log entries in a ZIP file containing the individual log files for the selected time period. |
| **Close** | Click to exit this dialog. |
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------|
##  Time Range and Custom Date Search Filter
Focus the list of entries for a specific time period.
These options are not available if **Auto-Refresh** is activated.
| **Select a Time Range** | Select one of the following options from the drop-down list to reduce the display of entries to the corresponding time range: * Last Minute * Last 5 Minutes * Last Hour * Today |
| **Custom Date Search** | Enter the date and time of the period in which the entries are to be displayed. |
|-------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
##  Severity, User, Origin Filter, \& Trace
Focus the list of entries for **Severity** , **User** , **Origin** ,and/or **Trace**.
| **Severity** | Tick the desired categories that are to be displayed. See [Event Log Severity below](https://manuals.riedel.net/en/stage/2.1/events.md#Event-Log-Severity) for the definition of severity level. |
| **User** | Tick the involved users who triggered the status message. |
| **Origin** | Tick the sources where the condition occurred. |
| **Trace** | Tick to focus on traces. |
|--------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
##  Locations Filter
Focus the list of entries for **Locations**.
|  | Set a filter to display only content whose search text is found in the name. |
| **Location** | Select one or more locations where the event was triggered. |
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------|
##  Event Log Entries
This section displays the existing entries according to the corresponding filter settings.
|  | Set a filter to display only content whose search text is found in the name. |
| **Time** ^**a**^ | Shows the time when the event occurred in your local time zone. |
| **Date** ^**a**^ | Shows the date when the event occurred in your local time zone. |
| **System Time** | Shows the UTC date and time when the event occurred. All timestamps for events and logs come from the STAGE cluster and internally time is tracked in UTC as the time-zone reference. |
| **Severity** | Shows a symbol and text to indicate the event's relative severity. See [Event Log Severity below](https://manuals.riedel.net/en/stage/2.1/events.md#Event-Log-Severity) for the definition of severity level. |
| **Origin** | Shows the event's source. |
| **User** | Shows the user account that triggered the status message. |
| **Trace** | Shows the result of an event. For example, if a user ... * creates another user, this field shows which user was created. * registers a host, this field shows the host name. * imports a license, this field shows the license serial. |
| **Description** | Shows the reason for the log entry. |
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
**a.** This is the localized time and date converted from UTC using your computer's or browser's current time zone setting.
The order and size of the columns can be adjusted by dragging and dropping.
### Event Log Severity
The event log has the following severity levels.
|  | **Emergency** | Indicates that the system is unusable. |
|  | **Alert** | Indicates that immediate action is necessary to resolve a critical issue. |
|  | **Critical** | Signifies critical conditions in the program that demand intervention to prevent system failure. |
|  |
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------|
| **Error** | Indicates error conditions that impair some operation but are less severe than critical situations. |
| **Informational** | Includes messages that provide a record of the normal operation of the system. |
| **Debug** | Intended for logging detailed information about the system for debugging purposes. |
| **Trace** | More debug information that shows every available log output. |
| **Unknown** | Messages that doesn't fit in any other severity level. |
---
version: "2.1"
language: "en"
---
# FAQ
This chapter is intended to provide answers to the most frequently asked questions.
## General
Which new features does STAGE have?
See [Release Notes](https://manuals.riedel.net/en/stage/2.1/release-notes.md).
*** ** * ** ***
## Device Management
Does STAGE 2.0 support additional types of equipment ?
Yes. It adds the support of SAME DSP Engine as well as NMOS Devices.
What is a Virtual Device ?
A device that STAGE does not discover, control or monitor, but that provides AV I/Os. A User can tell STAGE that a Virtual Device exist (such as a Microphone or a 5.1 speaker array) so that it can represented in various STAGE UI (ex. Audio Mixer UI). A Virtual Device is connected to a Hardware Device (Ex. NSA).
Why map Virtual Devices to Hardware devices ?
This is necessary so that STAGE knows where the Virtual devices are connected so they can be properly represented in various Operational UI (ex. Audio Mixer UI).
What is an Unmanaged Host and why should I care ?
A hardware host that STAGE does not discover or control. An Unmanaged host provides ST2110 / AES67 signals, which a User can tell STAGE exist so that these signals coming from an Unmanaged host can be routed to Riedel products, such as SAME.
What does Mapping refer to ?
This is the process of linking an Hardware Device to a Virtual Device.
Does STAGE support NMOS ?
Yes. NMOS is used to communicate with Riedel NSA box. It is also used to communicate with 3rd party NMOS devices. For instance, NMOS can be used to route SAME signals to/from 3rd party NMOS receivers/senders.
*** ** * ** ***
## Jobs
What is a Job ?
A job is the overarching configuration of an entire Production.
Why do I need Job ?
A job is needed to define all the elements required for a Live Production event inside STAGE. Jobs are required when using SAME.
Can I use STAGE without Jobs ?
Jobs are required when using SAME. However, VSP does not use Jobs.
What does Adoption refers to ?
This refers to the process by which system resources (e.g. hardware devices) are chosen for a Job. Multiple adoptions can be created for the same job. This can provide additional flexibility to the user (e.g. ability to run a production from various studios).
What does it mean to activate a Job ?
Activating Job allows a User to indicate that he is starting the Production event. Upon activation of a Job, STAGE will reserve the system resources defined in the Job adoption (if not already in use) so that no one else can use them while the job is active.
How can I guarantee that when I activate a Job, it will have enough resources (e.g. IO devices, Processing blocks) to run ?
Before activating a Job, the User is presented with a Job activation summary UI that shows him if all the resources he needs are avaiable. If some resources are missing (e.g. I/O devices such as NSA, Processing blocks coming from SAME Engine), the User will know exactly which resource is missing. User will have the option to activate the job even if not all resources are available.
*** ** * ** ***
## Licensing
How can I monitor license usage ?
From STAGE UI (see System Management -\> License Management), it is possible to see the license usage (or consumption) of all license options installed on a STAGE instance, including VSP and SAME licenses.
Are subscription-based (i.e time-based) licenses supported ?
Yes. STAGE supports licenses with a Start Date and End Date, which are therefore only valid for a specific duration. These types of licenses are available for SAME.
*** ** * ** ***
## Connectivity
Which TCP/UDP ports need to be open for STAGE to work?
Please refer to STAGE User Guide ([-\> VSP Default Ports](https://manuals.riedel.net/vsp?contextKey=vsp_-virtual-smartpanel-default-ports&version=latest&language=default)) for a complete list of all network ports.
*** ** * ** ***
## Installation
What are the system requirements to run STAGE software ?
Please refer to STAGE User Guide ([-\> System Requirements](https://manuals.riedel.net/en/stage/2.1/requirements.md)) for a detailed list of hardware requirements.
---
version: "2.1"
language: "en"
---
# Further Unmanaged Host Registration Details
The following Registration details apply to SAME only.
## Unmanaged Host
An unmanaged host represents in STAGE a device that STAGE is unable to configure or control. However, this host can send and receive AES67 audio stream(s). These types of devices must be added through one of the following methods:
* Manually to add their audio stream IP addresses.
* Using the device's SDP file.
Once an unmanaged host has been added to STAGE:
* It is understood that the audio stream IP addresses will not change (remain static).
* The STAGE network ports for the Host must be configured in Configuration. It is important to set the Network Scope for each Host Ethernet connection. See chapter [Host Configuration](https://manuals.riedel.net/en/stage/2.1/kj-setting-the-device-s-configuration.md).
| **Create Unmanaged Host** | Click to add an unmanaged host. **Create Manually:** Use the device's static stream IP addresses that have been previously configured on the device by adopting them into STAGE as named audio streams. This adds the host as an Unmanaged Host to STAGE. **Create From SDP File:** Use the host's SDP file to add the host as an Unmanaged Host to STAGE. |
|---------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
### Manually Create an Unmanaged Host
This option assigns the device's static stream IP addresses that have been previously configured on the device by adopting them into STAGE as named audio streams.
| **Host Name Template** | Set the name by which this unmangaged host will be known by throughout STAGE. |
| **Amount** | Set the number of audio stream interfaces the host supports / that you want to use. |
| **Name** | Shows the automatically generated name for each audio stream by which it will be know by throughout STAGE. |
| **Control IP Address** | Set the static unicast Control IP Address of the unmanaged host. |
|------------------------|------------------------------------------------------------------------------------------------------------|
### Create an Unmanaged Host through its SDP File
This option uses an SDP file that has been generated for the device to make the device's streams available in STAGE.
#### By Pasting an SDP File's Contents
In the **Paste SDP** tab, copy the SDP file contents and paste it into STAGE.
#### By Uploading an SDP File
In the **Upload SDP Files** tab, find the device's SDP file on your filesystem and upload the file into STAGE.
| **Host Name** | Set the name by which this unmangaged host will be known by throughout STAGE. |
| **IP Address** | Set the static IP address for the audio stream. |
| **Clipboard** | Paste into this field the contents of the device's SDP file. |
| **SDP File Upload** | Click Browse to find and select the device's SDP file on your PC's filesystem. |
| **Close** | Click to cancel this operation. |
| **Confirm** | Click to proceed. |
|---------------------|--------------------------------------------------------------------------------|
---
version: "2.1"
language: "en"
---
# Further VSP Registration Details
The following Registration details apply to Virtual SmartPanel only.
## Automatic Device Discovery
Here are the typical sequence of events for automatic host discovery.
|---|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| 1 | The device boots and tries to connect to a DHCP server. |
| 2 | The device retrieves the DNS server address. |
| 3 | The device connects to the DNS server to resolve the `_riedel-register` (Riedel Registration) service. |
| 4 | The DNS server replies with the Service description for the STAGE Riedel Registration service endpoint. |
| 5 | The device connects to STAGE and is added as an entry in the Riedel Registry. Once a device or software service has been added to the Riedel Registry, it appears as a discovered host in System Commissioning. |
If the device is unable to resolve the Riedel Registration Service through the DNS server, or the DNS server is unavailable, the device may fallback to using mDNS to attempt to connect with the STAGE Riedel Registration service.
### Manual Mode
When installing a product such as the WebRTC Gateway through the Riedel Software Manager (RSM), you configure where it is to find the Riedel Registry.
## Artist-1024 Setup
In order for an Artist-1024 to be recognized as a Discovered Host and Artist-1024 ports to be used in STAGE, the following configurations must first be set up in the Director.
Proceed as follows:
### Editing the Web Properties
Open the web properties. See chapter 'Web' Properties in the Director manual.
* Assign a Net address.
* Enter the Registration URL of the STAGE installation.
* Enter the Base URL of the STAGE installation.
* Click the **OK** button to confirm.
### Creation of the STAGE ports
Open the workspace of an AES67-UIC of an Artist-1024 by double-clicking on the corresponding AES67-UIC in the 'Networks' navigation bar.
Create the desired number of STAGE ports (Miscellaneous \> STAGE) on the Media Interface 1 of the AES67 UIC.
See chapter 'Adding a New Port' in the Director manual.
The Media Interface 2 and the redundant SMPTE 2022-7 operation will be available in a later version.
### Editing names in the properties window
The names can be customized in the properties window of the STAGE port.
Open the properties window of a STAGE port by right-clicking on the desired port and selecting "Properties".
Customize the names (**Long Name** , **Local** and **16-char Subtitle**) according to your requirements.
The ports are displayed in Stage as **Intercom Resources** with the names defined here.
This completes the configuration of the STAGE ports on the Director side.
---
version: "2.1"
language: "en"
---
# General Information
Under General Information, you will find information on the following topics:
* [Technical Specification](https://manuals.riedel.net/en/stage/2.1/technical-specification.md)
* [Known Limitations](https://manuals.riedel.net/en/stage/2.1/release-notes-1.md)
* [FAQ](https://manuals.riedel.net/en/stage/2.1/faq.md)
* [Glossary](https://manuals.riedel.net/en/stage/2.1/glossary.md)
---
version: "2.1"
language: "en"
---
# Getting Familiar with the User Interface
## Landing Page
When you connect to the STAGE user interface, the [Home](https://manuals.riedel.net/en/stage/2.1/home.md) view appears. This view contains links to the most important [Views](https://manuals.riedel.net/en/stage/2.1/views.md) of the STAGE user interface.
Home view
## Menu
The [Menu](https://manuals.riedel.net/en/stage/2.1/main-menu.md) allows you to switch to all available STAGE user interface views.
This menu is displayed on the left-hand side and is collapsed by default. To view all menu items, click on the menu icon at the top left.
A description of the individual views can be found in chapter [Views](https://manuals.riedel.net/en/stage/2.1/views.md).
Menu -- collapsed
Menu -- expanded
## Collapsing/Expanding Column Sections
You can recognize column sections by the right  or left  arrow symbol at the top right of a section.
Clicking on an arrow expands or collapses the column section.
Column Section -- collapsed
Column Section -- expanded
## Filtering
Filters allow you to focus on pertinent content, which is useful when encountering information-heavy lists and tables.
Depending on the selected view, filters are available at the top of tables and/or in an expandable column on the left-hand side.
### Filters on the Top
Enter characters in the text field above the desired table.
Only content containing the search text are displayed in corresponding tables (case-insensitive).
Click  delete icon to clear the filter.
Filters on the Top
### Filters on the Left-hand Side
Depending on the selected view, various filters are available in subsections and/or tabs.
The symbols at the top enable the following functions:
|  | Click to clear all tick marks. |
|  | Click to toggles all tick marks. |
|  | Click to disable the respective filter. |
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------|
Filters on the left-hand side
## Sorting
Table content can be sorted by clicking a column heading. Click again to sort in the opposite direction. Multiple sorting is possible by holding the `CTRL` or `SHIFT` on the keyboards while clicking again on another column heading.
Sorting
## Selecting Items in a List
### Single Selection
Single entries can be selected / deselected by click on it once.
### Multiple Selection
In a table, where multiple selection is allowed, you can use the `CTRL` and `SHIFT` keys while clicking on items to expand the selection to two or more items. The two methods can be combined where you first `SHIFT`-select a range and then use `CTRL`-select to further add or remove items to or from the selection.
Select a Range of Items (SHIFT-select)
Select a range of consecutive items in a list as follows.
1. Click to select the first item.
2. Hold `SHIFT` and click the last item.
All list items from the first to the last are added to the selection.
Select Multiple Items (CTRL-select)
Select two or more items in any order as follows.
1. Click to select the first item.
2. Hold `CTRL` and click another item.
3. `CTRL`-clicking a previously selected item de-selects it.
Each clicked list element is added to the selection.
## Enable / Disable Toggle Switches
The enable / disable switches turn a feature on or off.
| **Disabled** | **Enabled** | **Description** |
|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------|
|  |  | Click to toggle a feature on or off. Once you have changed this setting, you must click Apply/Save to activate the change. |
## Status Indicators and General Buttons
Status indicators report the health or availability of a:
* Parameter as to whether it is within acceptable operating limits.
* Link or signal as to whether it is present and available for use.
* Software option.
Cautions and warnings are a range of alerts concerning the current operational status.
Status indicators show their current status through color coded icons.
Some icons are used as buttons to accept or reject changes.
| **Status Indicators** |||
| **Online** |  | The status means: device is online, sufficient resources available or user is logged in, for example. |
| **Offline** |  | The status means: device is offline or the user is not logged in, for example. |
| **Emergency** |  | The status means: device is reporting an error or insufficient resources, for example. The software has become unstable. |
| **Alert** |  | Immediate action is required. |
| **Critical** |  | An error that cannot be be ignored. |
| **Warning** |  | A potential problem or condition that might lead to a fault condition. |
| **Informational** |  | A status message to provide feedback about a process or action without indicating a problem or requiring you to intervene. |
| **Warning** |  | The status means: device reports an error, for example. A Host, server, or service is currently unavailable / offline. |
| **Yes / No** |   | The value is true or false. |
| **Rotating Green Dot** |  | The status is: a long operation is in progress. |
| **Rotating Blue Dot** |  | The status is: Evaluating or Connecting. |
| **Resource not available** |  | The status is: This resource is not available to this STAGE instance. This resource exists on the network, but is currently being used by another STAGE instance. To use this resource, you must first remove it from the other STAGE instance. |
|----------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Icons** |||
| **Power Status** |  | The current power status of a device or host. |
| **Status** |  | The current connection status. |
| **Server Available Status** |  | The current availability of a server to provide the required software services. |
|-----------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------|
| **General Buttons** |||
| **Settings** |  | Click to open a settings window. |
| **Tick** |   | The entry is selected (activated, switched on) or not selected (deactivated/switched off). |
| **Garbage Bin** |  | Click to discard changed settings. |
| **Delete** |  | Click to delete a resource. |
| **Clear Selection** |  | Click to clear the selection of any selected items, in a list of devices for example. |
| **Toggle Selection** |  | Click to toggle the selection of all items. Selected items become de-selected and de-selected items become selected. |
| **Question mark** |  | Moving the mouse pointer over the question mark displays a short tooltip about this parameter. |
| **Expand / Collapse** |   | Click to collapse/expand a configuration item. |
| **Expand / Collapse Branch** |   | Click these icons to expand or collapse a branch in a tree list. |
| **Collapse / Expand Column** |   | Click to collapse/expand a column. |
| **Hide / Show** |   | Click to hide/show the selected device. |
| **Add Item** |  | Click to add an item to a list such as a device or location. |
| **Filter** |  | Type text to filter the results in a list or table. See [Filtering above](https://manuals.riedel.net/en/stage/2.1/get-familiar-with-the-user-interface.md#Filtering). |
| **Edit Item** |    | Click to open a window for managing (adding, renaming, duplicating, or deleting) the selected list item. |
| **Alphabetical Sort** |  | Click to change the sort order of the items in a table. See [Sorting above](https://manuals.riedel.net/en/stage/2.1/get-familiar-with-the-user-interface.md#Sorting) . |
| **Disable Filter** |  | Click to clear any filtering action. |
| **Calendar** |  | Click to set a date or date range. |
| **Sort by Date** |  | Click to sort a list by each entry's creation date or time. |
| **Copy** |  | Click to copy the text in a field. |
| **Role Filter** |  | Click to filter the list according to the selected Roles. |
| **Member Filter** |  | Click to filter the list according to the members. |
| **Device Filter** |  | Click to filter the list according to the devices. |
| **Application Filter** |  | Click to filter the list according to the applications. |
| **Reset to default settings** |  | Click to reset any changes you have made to the default settings. |
| **Accept** |  | Click to accept your modifications and close the window. |
| **Cancel** |  | Click to reject your modifications and close the window. |
|-------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------|
---
version: "2.1"
language: "en"
---
# Glossary
## General
| **Term** | **Description** |
|----------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Cluster Setup** | A set of one or multiple Nodes (servers, computers, virtual machines) working together as a single system. Multiple Nodes can provide high availability to a server setup. |
| **FQDN** | Fully Qualified Domain Name |
| **High Availability Mode** | If a Server Setup consists of three nodes, it can provide high-availability as it is protected against the failure of one of these nodes. |
| **Node** | Each single node can be a server, a computer or a virtual machine. |
| **RR** | RTCP Receiver Report |
| **RSM** | Riedel Software Manager |
| **RTCP** | Real-time Transport Control Protocol |
| **RTP** | Real-time Transport Protocol |
| **Server Configuration** | Specifies the application and its configuration parameters, which can then be installed on a Cluster Setup. |
| **Server Setup** | A set of one or multiple Nodes (servers, computers, virtual machines) working together as a single system. Multiple Nodes can provide high availability to a server setup. |
| **SR** | RTCP Sender Report |
| **SSRC** | Synchronization Source |
| **UI** | User Interface |
| **Node File** | A file containing all required software packages to create a Cluster Setup on nodes which have been prepared with the factory default setup of an operation system only. |
| **Suite File** | A file containing all required software packages for the application specified in a Server Configuration. |
| **Host** | Hardware Platform which is connected on the IP network. * A Host can be a COTS Platform (for example, a server) or a a purpose-built platform (for example, a Riedel MuoN devcie). * A host can run one or many software applications. * A host has a *Host Type* which cannot be changed. * A host is formed from one or more Hardware Devices. For example: * COTS server * Riedel MuoN * Riedel FusioN * An NMOS Node Note: A host corresponds to an [AWMA NMOS Node](https://specs.amwa.tv/nmos/branches/main/docs/Technical_Overview.html#:~:text=In%20NMOS%20specifications%20a%20Device,Device). |
| **Discovery** | Process by which Hosts are discovered over the IP network. |
| **Riedel Discovery** | Process by which Hosts are discovered over the IP network using the Riedel Discovery protocol. |
| **NMOS Discovery** | Process by which Hosts are discovered over the IP network using NMOS IS-04 mechanisms. |
| **NMOS Host** | Any media device that runs NMOS-enabled software and participates in the Networked Media Open Specifications (NMOS) ecosystem by making its resources and services discoverable and manageable over a network. Refer to [AMWA NMOS](https://specs.amwa.tv/nmos/branches/main/docs/Technical_Overview.html#nmos-model-and-terminology). |
| **NMOS Device** | NMOS specifications, such as IS-04 for discovery and IS-05 for connection management, allow different manufacturers' devices to automatically discover each other, register their capabilities, and establish media connections on an IP network, facilitating easier system integration in broadcast and AV environments. Refer to [AMWA NMOS](https://specs.amwa.tv/nmos/branches/main/docs/Technical_Overview.html#nmos-model-and-terminology). |
| **Network Scope** | Represents a section of an IP Network that is configured in such a way that Hosts having network interfaces within this Network Scope can communicate with each other; they have IP connectivity. For example, networks can be segmented into the following Network Scopes: * Management network * Media Red network * Media Blue network |
| **Packet Time** | The duration of the audio data captured and transmitted in a single digital packet over a network. See for more information. |
## STAGE
### General
|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Host Type** | The Host Type establishes the driver(s) STAGE uses to communicate with the Hosts and the corresponding features that are available in STAGE to support a given Host Type. |
| **Discovered Host** | Host that has been discovered over the IP Network and is visible to a STAGE instance. |
| **Registration** | Process by which a Host is added to a STAGE instance so it can be managed by STAGE. |
| **Registered Host** | Host registered to a STAGE instance. A Registered Host will appear in Discovered Hosts in other STAGE instances, but cannot be registered in another STAGE instance. The STAGE instance a Host is registered to has exclusive control of that Host. |
| **Unmanaged Host** | Host that STAGE cannot discover nor control. |
| **Location** | Locations are metadata representing actual physical locations of equipment in a system managed by STAGE. Locations can be arranged in a Tree structure. Hosts, Hardware Devices, and Virtual Devices can be assigned to a Location to simplify finding them in larger systems. For example: Amsterdam, Studio 1, France, Control Room 2, Ground floor. |
| **Host Configuration** | Basic, non-operational configuration settings specific to a Host. For example: IP Address, PTP Settings. |
| **Matching \[a Host\]** | Refers to the process of assigning a *Discovered Host* to a *Prepared Host.*The Prepared Host instance then becomes a Registered Host. |
| **System Resources** | A Class of Devices and Hosts that are used in System Commissioning, representing physical realities of the system STAGE is controlling. The Types of System Resources are: * Hardware Devices * Virtual Devices * Hosts The counterpart to System Resources are Job Resources (see below). |
| **(System) Hardware Device** | The I/O Structure and the available features on a Host. Simple Hosts (for example, an MNIP SDI/IP Gateway) will present only one Hardware Device with the Inputs and Outputs of the Gateway. Complex Hosts might expose multiple Hardware Devices. For example, a Riedel SmartPanel through NMOS will expose the Audio Monitoring App and the Control Panel App as separate Devices. The I/O Structure is defined by the Host and cannot be edited. Note: A Hardware Device corresponds to an AMWA NMOS [Device](https://specs.amwa.tv/nmos/branches/main/docs/Technical_Overview.html#:~:text=In%20NMOS%20specifications%20a%20Device,Device). |
| **(System) Virtual Device** | Virtual Devices are used to represent elements of the real world. For example, a Mono Microphone. It is an I/O Structure of a set of features that are not directly visible to STAGE through Hosts. By creating Virtual Devices and mapping their I/O structures to Hardware Device I/O structures, you can create abstract elements you can use for Signal Management and other Workflows. |
|  **I/O Structure** *This term is not used in STAGE; it is only used in this glossary.* | Representation of the Audio/Video Input/Output structure of a Hardware Devices or Virtual Devices. A Device's I/O Structure is a hierarchical representation composed of *Prosumer Groups* , *Prosumers,* and *Legs.* For example: * Device A * Prosumer Group A * Producer 1 * Leg A * Leg B * Producer 2 * Leg A * Leg B * Consumer 3 * Leg A * Leg B * Prosumer Group B * Consumer 4 * Leg A  |
| **Producer** | A Producer represents one or more channels that are created on a Host and each channel is represented as a *leg*. Note: This is the equivalent of an AWMA NMOS [Sender](https://specs.amwa.tv/nmos/branches/main/docs/Technical_Overview.html#:~:text=In%20NMOS%20specifications%20a%20Device,Device), although not every Producer directly corresponds to a Sender on a Host. |
| **Consumer** | A Consumer represents one or more signals that are to be received on a Host and can have one or more *legs*. Note: This is comparable to AWMA NMOS [Receiver](https://specs.amwa.tv/nmos/branches/main/docs/Technical_Overview.html#:~:text=In%20NMOS%20specifications%20a%20Device,Device), although not every Consumer actually corresponds to a Receiver on a Host. |
| **Leg** | A discrete channel in a Producer or a Consumer. Note: This corresponds to an AMWA NMOS Channel in IS-08. |
| **Prosumer** | Abbreviation referring to either a *Producer* or a *Consumer.* |
| **Prosumer Group** | A group of one or many Prosumers. Used to organize Prosumers in Devices. |
| **Prosumer Type** | The signal type of a Producer or Consumer. For example, this can be one of Video, Audio, or Ancillary, when supported. |
| **I/O Mapping** | Association of a (System) Hardware Device and a (System) Virtual Device. The Mapping is stored on the leg level, and individual Legs of a Virtual Device Prosumer can be mapped to Legs of Hardware Device Prosumers. |
| **Unmanaged Device** | I/O Structure of a set of functionalities present by an Unmanaged Host. Since an Unmanaged Host cannot be controlled, the Unmanaged device it provides can only have producers. Since an Unmanaged Host cannot be discovered, the I/O Structure of the Unmanaged device is manually defined. |
| **Workplace** | A special type of a Location that contains devices that are meant to be used by an Operator. |
### Job Management
|------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Job** | Overarching configuration of a production event. All Configuration of Devices, Connections, that is specific to a production or an event lives inside a Job. For example, a Job can be named for it production: "News Hour" or "Phantom of the Opera". |
| **Operator** (also known as a Job Participant) | Representing a person participating in a live Production. For example, Video Mixer Operator, Audio Mixer Operator, Video Shader Operator, or Replay Operator. |
| **Job Resource** | Describes everything that can be put in a Job, such as Roles, Members, Job Devices and Applications. |
| **Role** | Categories of people that participate to Productions. Roles are used to create Members. For example, Technical Directors or Audio Engineers. |
| **System Roles** | Roles global to entire STAGE instance. System Roles are available to all Jobs of a STAGE instance and typically represent categories of people in the environment where STAGE is used. For example, Audio Engineers or Technical Directory. |
| **Job Roles** | Roles created for a specific Job. Job Roles can be added to a specific Job, if for a specific Job the globally defined System Roles are not sufficient. For example, Space Field Reporter. |
| **Member** | Represents a single participant in a Production Event. A Member always has a Role, and a Job can consist of multiple Members of Multiple Roles. For example, Technical Director, Audio Engineer 1 (A1), Camera Operator 1, Camera Operator 2. |
| **Job Device** | Device created inside a Job. A Device can belong to a Member or to a the Job itself. Job Devices can be divided into: * Job Virtual Devices. * Job Hardware Devices. |
| **Job Virtual Device** | Device created in a Job corresponding to a System Virtual Device. This involves adding Microphones, Line Ins, and so on to a Job Member or the Job itself. |
| **Job Hardware Device** | Device created in a Job corresponding to a System Hardware Device. For example, adding an NSA-Box to a Job Member or the Job itself. |
| **Application** | A piece of processing software designed to perform specific tasks or functions in a Job. An Application requires a Host to run when the Job is activated. For example, a JPEG-XS APP or an Audio Mixer APP. |
| **Job Setup** | Process by which Job Resources are added to a job and configured. |
| **Job Adoption** | Plan that defines which System Resources are chosen for each of the Job Resources of a particular job. Job Adoption is split in two parts: * Device Adoption (relies on a Manual Adoption) * Application Adoption (relies on Automatic Adoption) While a Job can have multiple Adoptions, only one Adoption can be loaded at the same time. |
| **Manual Adoption** | Process by which a User responsible for a Production event has to manually select the System Resources to use for each Job Resource. |
| **Automatic Adoption** | Process by which STAGE is able to identify and select the Hosts to run the Job Resources from. For example, the automatic selection of the Audio Mixer App on SAME Engine Host. |
| **Job Activation** | Process by which the User responsible for a Production event indicates that the Production event is starting. The Job Adoption plan is executed upon Job Activation. For Example, "News Hour" triggers the Adoptions of "Studio A" and "Studio B". |
### System Management
|--------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **System Management** | Category of tasks that include the adjustment of settings global to the entire STAGE instance. |
| **License Management** | STAGE uses licensing to make certain features available for use. An overview allows you to see what licenses are available and know the quantity of licensed features currently being used, any expiry time warnings for time specific licenses. |
| **License Verification** | STAGE must validate the authenticity of a license before applying it. |
| **License Option** | Optional features can be electronically enabled through a licensing scheme. For example, one or more feature can be made available for a given time period or in a permanent fashion. One or more licenses can be applied to STAGE to make one of more features available for use. |
| **System Settings** | Global settings for the STAGE platform (core application). |
| **Product Settings** | Settings for the individual applications that are part of the STAGE product portfolio. |
### User Management
Category of tasks that include the management of Users and User Groups, as well as the setup of connections to Identity Providers or to User Directories.
|----------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **User** | A specific individual, who has potential access to any part of STAGE. A user may be part of of one of more User Groups. For example, John Smith. |
| **Local User** | A user who is onsite and is using the local network to connect. |
| **Remote User** | A user who is offsite, and has to connect from the World Wide Web to STAGE though a firewall. |
| **User Group** | A named collection of users who share a common goal or job category within an organization. Members of the User Group (Users) can be managed as a unit with regards to their collective permissions to certain features, configuration pages, and so on. |
| **User Directories** | STAGE's database that stores Users and User Groups for managing access to STAGE. This database manages User credentials, roles (User Groups), and permissions. |
| **Identity Providers** | An external service that creates, stores, and manages digital user identities. |
| **Permission (or Access Level)** | Determines a User's or User Group's access to use certain features, configuration pages, and so on. |
### System Health
A category of tasks that include the review of Events and monitoring of Live Metrics collected from managed devices and services.
|----------------------|---------------------------------------------------------------------------------------------------------------|
| **Events** | STAGE flags and logs anomalous operations as events. These logs can be reviewed for troubleshooting purposes. |
| **\[Live\] Metrics** | Live measurement data. |
---
version: "2.1"
language: "en"
---
# Server Hardware Requirements
STAGE is installed using the [Riedel Software Manager](https://manuals.riedel.net/rsm?contextKey=RSM&version=latest&language=en), which will install a set of software packages (Suite and Node files) on one or more servers.
Both physical servers and virtual machines are supported for the installation of STAGE.
## Server Operating System
STAGE can be deployed on the following server operating system:
* Debian "bookworm" release 12.x ([the latest stable released version 12.x](https://www.debian.org/releases/bookworm/index.en.html))
## System requirements for the host machine(s)
The CPU and RAM requirements shown below set the minimum server capacities to be reserved to run the application.
For all systems, the host requires a minimum of:
* 6 physical CPU cores with a total of 32 GHz clock frequency
* 40 GB of available free disk space (this is enforced during installation and the installer will not proceed without enough space).
To accommodate the storage of logs and metrics and software updates, we recommend to have a larger disk size to allow for some headroom: for example, 80 GB of free disk space.
* 24 GB of RAM reserved to run the application. If cores with a lower clock frequency are used, for example, virtual machine CPUs with 2.5 GHz clock frequency, then more cores will be needed to obtain a total of 32 GHz clock frequency.
The host CPU must support the SSE4.2 instruction set, which is the case for most x86 or x64 CPU types. When deploying to virtual machines, make sure to not simulate a legacy CPU without this instruction set.
If you are using a virtual host on a virtual machine, make sure, that other applications on that host do not consume these requirements.
### Host HDD Storage Device Requirements
* The disk type must be an SSD capable of 100,000 4k IOPS read/write or faster.
* The disk must be formatted with a single system partition. The HDD requirements shown below set the minimum amount of storage space to be made available on that partition to run the application.
### STAGE Server Requirements
When selecting the hardware for the servers, the planned user capacity must be taken into account:
| | **1 ... 64** **Users** | **64 ... 128** **Users** | **128 ... 250** **Users** | **\>250** **Users** |
| **CPU** | 6 Cores / 32 GHz | 8 Cores / 42 GHz | 12 Cores / 64 GHz | Please contact Riedel Customer Success Service |
| **RAM** | 24 GB | 32 GB | 64 GB | Please contact Riedel Customer Success Service |
| **HDD** | 80 GB | 80 GB | 100 GB | Please contact Riedel Customer Success Service |
|---------|------------------------|--------------------------|---------------------------|------------------------------------------------|
At least one network interface is required. For redundancy, two network interfaces are required; each interface being connected to separate network switches. See chapter [Network Architecture Requirements](https://manuals.riedel.net/en/stage/2.1/networking-considerations.md).
### WebRTC Gateway Server Requirements
The WebRTC gateway server runs on a Debian Linux server which connects to the Artist-1024 device via ST-2110 IP network connections and provides conversion from Artist-1024 streams to OPUS encoded WebRTC streams.
When selecting the hardware for the servers, the planned user capacity must be taken into account:
| | **1 ... 64** **Users** | **64 ... 128** **Users** | **128 ... 250** **Users** | **\>250** **Users** |
| **CPU** | Intel® Core™ i7-1260P 12 Cores / 16 T | Intel® Xeon® Silver 4314 16 Cores / 32 T | Intel® Xeon® Silver 4314 16 Cores / 32 T | Please contact Riedel Customer Success Service |
| **RAM** | 32 GB DDR4 | 32 GB DDR4 | 32 GB DDR4 | Please contact Riedel Customer Success Service |
| **HDD** | 80 GB | 80 GB | 80 GB | Please contact Riedel Customer Success Service |
| **NIC** | 1×Intel® I226-V/LM 2.5 GbE | 1×Intel® X710 Dual Port 10 GbE | 1×Intel® X710 Dual Port 10 GbE | Please contact Riedel Customer Success Service |
|---------|---------------------------------------|------------------------------------------|------------------------------------------|------------------------------------------------|
#### **WebRTC Gateway Server Requirements "Gray List"**
The following table contains examples of server specifications currently used in live production environments. However, these have not been officially tested by Riedel and therefore cannot be guaranteed to function completely as intended.
|--------|------------|---------------------------------------------------------------------------------------------------|
| **#1** | **CPU** | 2× Intel® Xeon® CPU E5-2640 v3 @ 2.60GHz |
| **#1** | **RAM** | 128 GB DDR4 |
| **#1** | **HDD** | 1× 480 GB (SSD RAID1) |
| **#1** | **NIC** | 1× Intel® Ethernet Converged Network Adapter X710-2 |
| **#2** | **Users** | 25 ... 64 |
| **#2** | **CPU** | 1× ASUS® NUC 12 Pro Intel® i7-1260P |
| **#2** | **RAM** | 64 GB DDR4 |
| **#2** | **HDD** | 1× 1 TB NVMe |
| **#2** | **NIC** | 1× Intel® I226 2.5 GbE |
| **#3** | **Users** | 25 ... 64 |
| **#3** | **Server** | PowerEdge R660 Server |
| **#3** | **CPU** | 1× Intel® Xeon® Silver 4510 12 Core / 24T / 2.4 Ghz |
| **#3** | **RAM** | 32 GB RAM |
| **#3** | **HDD** | 1× 960 GB SSD SATA Drive SSD , No Raid Controller |
| **#3** | **NIC** | 1× Intel® X710-T4L Quad Port 10GbE Base-T, OCP 3.0 Version 2 1× Broadcom® 5720 Dual Port 1GbE LOM |
| **#4** | **Users** | 128 ... 250 |
| **#4** | **Server** | PowerEdge R660 Server |
| **#4** | **CPU** | 1× Intel® Xeon® Gold 6542Y, 24 Core / 48T / 2.9 GHz |
| **#4** | **RAM** | 32 GB RAM |
| **#4** | **HDD** | 1× 960 GB SSD SATA Drive SSD, No Raid Controller |
| **#4** | **NIC** | 1× Intel® X710-T4L Quad Port 10GbE Base-T, OCP 3.0 Version 2 1× Broadcom® 5720 Dual Port 1GbE LOM |
### SAME DSP-Engine Processing Server Requirements
The SAME DSP-Engine processing server runs on a Debian Linux server.
|--------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| CPU | Intel CPU is required, however dual CPUs are not supported yet! **Server:** * Base Frequency 2 GHz or higher * Intel Xeon Silver minimum 14 Cores (for example, 4314) * Intel Xeon Gold minimum 14 Cores (for example, 5318N) Maximum number of Channels per SAME DSP-Engine: 700 Maximum number of Streams per Network Interface: 200 **Intel/Asus NUC:** * Intel i7 1260P (recommended!) Maximum number of Channels per SAME DSP-Engine: 700 Maximum number of Streams per Network Interface: 32 |
| RAM | DDR4 RDIMM, 3200MT/s, Dual Rank **Intel Xeon Silver:** * 32 GB **Intel Xeon Gold:** * 32 GB **Intel i7 1260P:** * 32 GB |
| Hard disc | Min. 1× 200 GB SSD (6 Gbps) |
| Network Card | Network card, supporting PTP Timestamping (IEEE 1588) \& XDP (express data path) Recommended: Intel I350 Chipset |
A separate NIC for Control is not required but strongly recommended.
PTP and Media can run on same network card.
---
version: "2.1"
language: "en"
---
# Home
The Home view contains topic blocks with links to the main views of the STAGE user interface.
## Overview
Users logged into STAGE are welcomed on the Home view with their first and last names. Topic blocks with links to available views are displayed depending on the user's authorization level.
See chapter [Users \| Permissions Tab](https://manuals.riedel.net/en/stage/2.1/users.md#Permissions-Tab).
## Using the Home view
###  Home
Clicking on the Riedel logo opens the Home view, regardless of which view is currently displayed.
Home
###  Topic Blocks
By moving the mouse over the various topic blocks, links to the respective available views are displayed.
Click on the desired link to open its view.
###  STAGE Version
The STAGE software version is indicated on the top right of the Home view. The version is also displayed in the [Menu \| STAGE Version](https://manuals.riedel.net/en/stage/2.1/main-menu.md#STAGE-Version) .
Version -- top right in the Home view
---
version: "2.1"
language: "en"
---
# How to...
* [STAGE Northbound API](https://manuals.riedel.net/en/stage/2.1/stage-northbound-api.md)
* [Monitoring STAGE with Third Party Applications](https://manuals.riedel.net/en/stage/2.1/3rd-party.md)
List of third-party APIs supported by STAGE in version 2.1.
* [Managing Security Certificates](https://manuals.riedel.net/en/stage/2.1/certificates-in-a-stage-deployment.md)
---
version: "2.1"
language: "en"
---
# I/O Management
I/O Management consists of mapping Hardware Devices to Virtual Devices. Hardware Devices represent the I/O Structure of a registered Host. Virtual Devices are used to represent elements of the real world (for example, a Mono Microphone) that are not directly visible to STAGE.
A Virtual Device is used to map a Host's I/O Structure is a hierarchical representation composed of *Prosumer Groups* , *Prosumers,* and *Legs.*
A Virtual Device Structures Host Inputs and Outputs into Devices, Prosumer Groups, Prosumers, and Legs
It is important to devise a naming scheme that allows you to trace a virtual signal back the hardware I/O for troubleshooting purposes. Consider keeping spare inputs and outputs:
* For future expansion needs.
* To have extra I/Os should there to be a need for a last second signal swap.
Once an input or output is mapped to a virtual device, the I/O is available to be used by any Job (anywhere in STAGE). Multiple Jobs can use the same I/Os, but not at the same time.
In I/O Management:
* You create one or more Virtual Devices for each Hardware Device (Registered Hosts discovered in the Registration tab or Unmanaged Hosts created in the Configuration tab).
* Virtual Devices model and virtually represent the underlying hardware layer within STAGE.
* When STAGE routes a Virtual Device's audio signals, all the legs (individual audio channels) are routed together as a package.
* You assign the hardware device's audio inputs and outputs to Virtual Devices. This requires the linking of the hardware inputs and outputs to the equivalent STAGE Virtual Device inputs and outputs.
For example:
* This determines that a specific hardware input is used for presenter one's microphone. Once this input is linked to a virtual device, it can be labelled as **Presenter #1**in the Virtual Device.
* If a Hardware Device has 16 audio inputs, this can be represented as:
* 8 × stereo Virtual Devices.
* 2 × 5.1 Virtual Devices and 3 stereo Virtual Devices.
## Overview
System Commissioning - I/O Management
##  Locations
This section lists all locations defined in the STAGE system. To add or edit locations, see chapter [Registration \| Locations](https://manuals.riedel.net/en/stage/2.1/kj-registering-devices.md#Locations).
|  | Set a filter to display only content whose search text is found in the name. |
| **Locations** | If one or more locations are selected, only host types that are located at the selected locations are displayed in the Host types section. Other host types are hidden. If no location is selected, all host types available in the STAGE system are displayed. |
|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
##  Virtual Devices
This section:
* Allows you to add Virtual Devices as necessary to represent each Registered Host discovered in the Registration tab. A virtual device can group a two or more audio signals together to represent the signal's application (5.1, stereo, or 16 channels for example) so that STAGE can route the audio signals as a group together. Each individual audio channel is called a **Leg**.
* Lists all the Virtual Devices that are available in the STAGE system. The Virtual Devices displayed may be reduced if one or more locations are selected in the Locations section.
|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|  | Set a filter to display only content whose search text is found in the name. |
|  | Click to delete the selected Virtual Device. |
|  | Click to add a Virtual Device. See below. |
| **Name** | Select a Virtual Device to show its available inputs / outputs in the I/O Mapping section. |
| **Map** | Shows  when the leg of a virtual device has been mapped. |
### Adding a Virtual Device
For each Hardware Device, you need to create a Virtual Device.
1. Select the Location in which the Hardware Device is located.
2. Click  to add a virtual device.
3. Select the Hardware Device's signal application (5.1, stereo, or 16 channels for example), line in, or line out.
4. Set the number of these Virtual Device instances to create.
5. Click **Create X Virtual Device(s)**.
6. Double-click the Virtual Device's Name to rename it.
##  I/O Mapping
This section lists the inputs and outputs for the selected Virtual Device and for the selected Hardware Device. Connections are made through:
* A drag and drop action, where you click on an Virtual Device input / output and drag it to the equivalent Hardware Device input / output leg.
* By making the connections between multiple Virtual Device inputs / outputs and their equivalent Hardware Device input / output legs in bulk.
When you have the same hardware in two studios (identical Registered Hosts but located in two different studios), map the I/Os in the same way in both studios. This allows Jobs to run in either studio: If one studio is closed for technical reasons, you can continue the production in the other studio using the same Job in the new Location.
Making a Drag and Drop connection. The Virtual Devices are on the left side and Hardware Devices are on the right side.
I/O Mapping has the following filters.
|----------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Signal Direction** | All: Show producers and consumers. :triangle: IN: Show producers (inputs) only. OUT :triangle:: Show consumers (outputs) only. |
| **Prosumer Type** | All: Show all types of producers and consumers.  : Show audio producers or consumers only.  : Show video producers or consumers only. |
| **Mapping State** | All: Show both mapped and unmapped producers and consumers.  : Show only mapped Producers or Consumers.  : Show only unmapped Producers or Consumers. |
I/O Mapping has the following map and unmap buttons.
|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------|
|  | Click to map the selected Virtual Device and Hardware Device leg(s). |
|  | Click to unmap the selected Virtual Device and Hardware Device leg(s). |
##  Inspector
This lists the I/O Mappings to and from the selected Virtual device or selected Hardware device.
|--------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Virtual Device** | Shows the Virtual Device's name. |
| **Device** | Shows the Hardware Device's name. |
| **Group** | Shows the signal direction. **Inputs** / **Audio Consumer**: This is an audio stream destination. **Outputs** / **Audio Producer**: This is an audio stream source. |
| **Prosumer** | Shows the group name for one or more legs. |
| **Leg** | Shows the discrete channel name / identifier. |
### Bulk Renaming
A number of bulk actions are available in Inspector by right-clicking a row.
When renaming, the following window opens.
|--------------------------------------------|---------------------------------------------------------------------------------------------|
| **Add Numbers** **Start Counting From** | Set to serialize the names from a starting number. |
| **Add at Start** **Add at End** | Set where the counter or text is to be added. |
| **Add Leading Zeros** **Number of Digits** | Set to enable the padding of zeros to the serialization. |
| **Search Text** **Replace Text** | Set to replace specific text in the name. |
| **Add Text** | Set to add text to the name. |
| **Apply** | Click to apply your change to the New Name column where you can preview your modifications. |
| **Reset** | Click to clear all changes. |
| **Cancel** | Click to cancel your changes and close this window. |
| **Save** | Click to apply your changes and close this window. |
##  Hardware Devices
Hardware Devices are:
* Registered Hosts discovered in the Registration tab and;
* Unmanaged Hosts created in the Configuration tab.
|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|   | Show / hide location without Hardware Devices. |
| **Show Devices in child Locations** | Set to show all Hardware Devices at the selected Location and the subordinate Locations in the Hardware Devices list. Clear to show only the Hardware Devices at the selected Location in the Hardware Devices list. |
|  | Set a filter to display only content whose search text is found in the name. |
|  | Click to sort list items by date, to show the most recently created items first. |
| **Name** | Select a Hardware Device to show its available inputs / outputs in the I/O Mapping section. |
| **Related Host** | Shows the registered host's name which the hardware device comes from. |
| **Map** | Shows the current leg status:  : All legs (inputs / outputs) of a virtual device have been mapped.  : The legs of a virtual device have been partially mapped. This means that there are legs (inputs / outputs) that are free to be used. |
## Mapping Audio Hardware Devices to Virtual Devices
Map audio hardware inputs and outputs to Virtual Devices as follows.
1. Optional: In Hardware Devices, Locations, select a location in which the Hardware Device is located to narrow the list of Hardware Devices being shown.
2. Select a Hardware Device that you want to assign legs to a Virtual Device.
3. In Virtual Devices, click  and create one or more Virtual Devices. See [Adding a Virtual Device above](https://manuals.riedel.net/en/stage/2.1/i-o-management.md#Adding-a-Virtual-Device).
4. Map the Hardware Device to the Virtual Device. See [I/O Mapping above](https://manuals.riedel.net/en/stage/2.1/i-o-management.md#I/O-Mapping).
## Batch Mapping
Many Virtual Device and Hardware Device legs can be mapped at once.
1. Select the Virtual Device and Hardware Device legs you want to map.
2. Click Map  .
When selecting multiple producers and consumers for mapping, there are two mapping modes:
* Align by Producer/Consumer
* Align by Audio Leg
The Mapping Preview window appears to show the change to be made.
If you are satisfied, click **Apply Mapping**.
Align by Producer/Consumer
Align by Audio Leg
## Unmapping Audio Hardware Devices from Virtual Devices
The mapping of audio hardware inputs and outputs to Virtual Devices can be broken as follows.
1. Select a Virtual Device or a Hardware Device leg to unmap.
2. To unmap,...
1. click Unmap  or
2. click on  that appears when moving the mouse over the circle connector.
---
version: "2.1"
language: "en"
---
# Identity Providers
This view allows adding Identity Providers to the STAGE system. Instead of STAGE validating a user's identity, STAGE uses one or more external Identity Provider services that provide user authentication for STAGE. In this scenario, STAGE does not store passwords or provide a 2-factor authentication mechanism for these users as this part is externalized by the Identity Provider for them.
STAGE shares information with the Identity Provider. However, there are a number of different Identity Providers that are supported and the way you need to configure the Identity Provider will be different and the way users are stored in a given Identity Provider will also be different from one to the next. In all cases, STAGE uses SAML v2.0 to communicate with the Identity Provider. This is an advanced configuration task that requires an in-depth knowledge of your Identity Provider's configuration and operation.
At minimum, STAGE always maintains the **Admin** account which cannot be deleted, so that access to the STAGE configuration remains available at all times. This ensures that should the connection to an identity provider become disrupted, access to configure STAGE configuration remains available, by the STAGE system administrator.
PREREQUISITE: These configuration procedures can only be carried out by an experienced administrator of your Identity Provider service.
## Overview
User Management - Identity Provider
The DETAILS section on the right can be expanded/collapsed by clicking on the left  or right  arrow symbols.
## Using the Identity Providers view
### Adding an Identity Provider
To add an Identity Provider, you must set the connection details from the Identity Provider, and then provide STAGE's connection details to the Identity Provider. The procedure below makes reference to Keycloak as an example of an Identity Provider. The Identity Provider you use will be similar, but not the same.
1. Click  . See section [#Configured-Identity-Providers](https://manuals.riedel.net/en/stage/2.1/identity-providers.md#Configured-Identity-Providers).
2. Select the `SAML 2.0` interface.
3. In the **Identity Provider Details** section in the **Setup** tab, enter a **Name** and an **Alias** for the identity provider. See section [#Identity-Provider-Configuration](https://manuals.riedel.net/en/stage/2.1/identity-providers.md#Identity-Provider-Configuration).
4. Import the SAML 2 connection details using one of the following methods:
1. From a URL:
1. Select the **Import from URL** option to import the Identity Provider's connection information from a URL supplied by the Identity Provider.
2. Enter the URL to the Identity Provider's XML metadata in **Metadata URL** . This URL comes from the Identity Provider's configuration. For example, with Keycloak, this is found under **Realm settings** , **Endpoints**. Refer to your identity provider's documentation.
3. Click  .
2. From an XML file:
1. From your Identity Provider's configuration, save the connection metadata as an XML file to your PC. This XML file comes from the Identity Provider's configuration. For example, with Keycloak, this is found under **Realm settings** , **Endpoints**. Refer to your identity provider's documentation.
2. Select the **Import from XML**option to import the Identity Provider's connection information from an XML file supplied by the Identity Provider.
3. Click  .
4. Select the XML file on your computer that has the Identity Provider's connection metadata.
5. Click  .
3. By manually entering the connection details:
1. Select the **Manual Setup**option where you have to configure the Identity Provider's connection details.
2. Click  .
3. In the **Connection** tab, enter the relevant connection information about the Identity Provider in all fields. See section [#Connection-Tab](/en/stage/2.1/identity-providers.md#Connection-Tab).
4. Click  .
5. In the **Setup** tab, click  .
6. In the **Setup** tab, the **Status** should become **Enabled**.
7. Export STAGE's Identity Provider SAML 2.0 metadata XML file to your PC: Click **Export to File** in the **Setup**tab.
8. The Identity Provider needs STAGE's SAML Metadata to make the connection between STAGE and the Identity Provider complete. In your Identity Provider's configuration, import a client:
1. In the Identity Provider's client list, import a new client.
2. Browse for STAGE's SAML 2.0 metadata XML file (resource file).
3. Click **Save**.
STAGE is added as a client in your Identity Provider under the name you defined in step #3 above.
9. In your Identity Provider's configuration for the STAGE connection, add mappers for certain STAGE client properties. For example, in your Identity Provider, you need to add mapping for **email** , **givenName** ,**surname** , and **username**.
Example mappers created in Keycloak
10. In Keycloak for example, the mapper type to use for **username** is **User Attribute For NameID**.
Example mapper for **username**
11. In the STAGE**Identity Provider Management** , **Property / Group Mapping** tab, add the equivalent SAML Attributes as they are defined in your Identity Provider under the **SAML Attribute** column. In this example, the Identity Provider uses the following attributes: **email** , **givenName** , and **surname**.
Mapping the Identity Provider's SAML attributes
12. Click **Save**.
13. In the **Setup** tab, click **Enable** . The **Status** should become **Enabled** . In Users (see chapter [Users](https://manuals.riedel.net/en/stage/2.1/users.md)), the users from the Identity Provider have been added to the user list and are identified as **Identity Provider** in the **Origin**column.
14. Assign these users to **Groups** or give them **Permissions** to access STAGE. See chapter [Users](https://manuals.riedel.net/en/stage/2.1/users.md).
15. Logout of STAGE and then log back in. This new Identity Provider has been added to the login screen under the name you defined in step #3 above, under **Or sign in with**.
Typical login screen showing access to the external Identity Provider **my-identity-provider**
16. Click the Identity Provider. You are taken to the Identity Provider's sign in page where you sign in with your credentials you have previously established with the Identity Provider. See chapter [Start \& Login](https://manuals.riedel.net/en/stage/2.1/start-login.md).
### Mapping Identity Provider Users to a User Group in STAGE
User identities from an Identity Provider can be mapped into STAGE User Groups when Users have already been assigned to one or more groups in the Identity Provider. These user groups are mapped into STAGE User Groups where they have access to STAGE according to the permissions assigned to the User Group.
PREREQUISITE: You must have created one or more User Groups in STAGE. See chapter [User Groups](https://manuals.riedel.net/en/stage/2.1/user-groups.md). One or more groups in the Identity Provider must have been created. User identities in the Identity Provider should be assigned to one or more groups.
1. In the **Setup** tab, if the connection status is **Enabled** , click **Disable**to break the connection between STAGE and the Identity Provider. This action will cause an outage for users trying to authenticate themselves with the Identity Provider. Only perform this action during off hours.
2. In **Group Mapping** , click **Add**.
3. In **Group Mapping** , select a STAGE User Group in the **STAGE Group** column.
4. In **Attribute** , set the name the Identity Provider uses for a group. For example, this is often **group** or **groups**.
5. In **Attribute Value**, set the name of the group used in Identity Provider to map to the selected group in STAGE.
6. Click **Save**.
7. In the **Setup** tab, click **Enable**to re-establish the connection between STAGE and the Identity Provider.
##  Configured Identity Providers
Configures Identity Providers
The table lists all the Identity Providers set up in the STAGE setup.
By clicking on an Identity Provider, **Details** are displayed on the right-hand side.
|  | Set a filter to display only identity providers whose search text is found in the name. |
|  | Click to change the order of the selected identity provider in the list and in the user login screen. Each Identity Provider appears as a separate button in the user login page. The order of the Identity Providers shown here will be reflected in the order the buttons are shown in the login screen. |
|  | Click to add a new identity provider. See section [#Adding-an-Identity-Provider](https://manuals.riedel.net/en/stage/2.1/identity-providers.md#Adding-an-Identity-Provider). |
|  | Indicates whether the current identity provider is enabled (  ) or disabled (  ). |
| **Name** | Shows the name of the identity provider. |
| **Identity Provider** | Shows the Protocol used by STAGE to connect to the identity provider. |
|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
##  Identity Provider Configuration
The **Details** section on the right-hand side displays full information about the selected identity provider.
* Any changes in this section need to be confirmed by clicking the  button.
* Click the  button to discard any changes.
* The  button removes the selected identity provider after confirmation.
### Setup Tab
Identity Povider - Setup Tab
This section is specific to using SAML 2.0 as identity provider.
#### Identity Provider Details
| **Name** | Set the Name for this identity provider. This alphanumeric string should only use URL-safe characters as it may be used in the login redirect URL to the identity provider. |
| **Alias** | Set the Alias for this identity provider. This alphanumeric string should only use URL-safe characters as it may be used in the login redirect URL to the identity provider. For example, redirect URL = "https://stage-cluster.riedel.net/service/auth/realms/UE/broker/**Alias**/endpoint" |
| **Status** | Indicates whether the current identity provider is enabled (  ) or disabled (  ). Click on  /  to change the current status. |
| **SAML Metadata** | Click on the  button to save the content in an XML file in the standard download folder of your browser. This XML file also contains the Redirect URL built using the **Alias**text you set above. |
|-------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
#### Import
This section is visible after clicking on  an Identity Provider.
| **Import (SAML 2.0)** | To connect to an Identity Provider, set the SAML 2 import the Identity Provider's XML metadata connection details. See section [#Adding-an-Identity-Provider](https://manuals.riedel.net/en/stage/2.1/identity-providers.md#Adding-an-Identity-Provider). **Import From URL:** Import the Identity Provider's XML metadata connection settings from a URL. Set the URL to import in **Metadata URL**. **Import From XML:** Import the Identity Provider's XML metadata connection settings from a XML file. Click Browse to locate the XML file to import on your PC. **Manual Setup:** provide settings in the **Connection** tab manually. See section [#Connection-Tab](https://manuals.riedel.net/en/stage/2.1/identity-providers.md#Connection-Tab). |
|-----------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
### Connection Tab
When you have selected the **Manual Setup** option in the **Setup** tab, you must manually add the connection details about the Identity Provider, by entering the values for the fields in this tab. See section [#Adding-an-Identity-Provider](https://manuals.riedel.net/en/stage/2.1/identity-providers.md#Adding-an-Identity-Provider).
If you have already added an Identity Provider, this tab shows the Identity Provider's current configuration parameters.
Identity Provider - Connection Tab
#### URL
| **Endpoint URL** | Set the endpoint URL. |
|------------------|-----------------------|
#### Connection Details
| **Entity ID** | Set the Entity ID. |
| **Single-Sign-On URL** | Set the Single-Sign-On URL. |
| **Logout URL** | Set the logout URL. |
| **NameID Policy Format** | Set the NameID policy format. |
| **Signing Certificate** | Set to enable / disable how the signing certificate is to be validated. **Enabled:**Validate certificate signature form IdP. **Disabled:** Use the signing certificate you enter in the text box shown below. |
| **Signing Certificate** |
|------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Set the signing certificate to use when **Signing Certificate** is disabled. |
### Property / Group Mapping Tab
To manage user group memberships in your SAML system, STAGE needs a way to find out how they are mapped as attributes in a SAML system which are not fixed. As such, you have to map attribute names used in the SAML system for STAGE parameters such as email, first name, and last name.
For every STAGE User Group (as configured in the **User Groups** tab), you need to provide an attribute and a value under **Property Mapping**.
STAGE will then check with the SAML system for every user:
* If the attribute exists.
* If the value of the attribute contains the value provided. When true, the user is allowed to be part of the group
Identity Provider - Property / Group Mapping Tab
| **Property Mapping** | **Property** | Map the following properties to their equivalent SAML attribute: **Email** , **First Name** , and **Last Name**. |
| **Property Mapping** |
|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------|
| **SAML Attribute** | Set the corresponding SAML attribute for the **Property**. |
|  | Click to remove the mapping of the selected group. |
|  | Click to map a user group. |
| **Stage Group** | Shows the STAGE User Group that the SAML group members are part of. |
| **Attribute** | Shows the SAML attribute for the group. |
| **Attribute Value** | Shows the value of the SAML attribute. |
---
version: "2.1"
language: "en"
---
# STAGE Software Installation Overview
## Before Installation
Please also note the following basic specifications and considerations.
* [STAGE System Requirements](https://manuals.riedel.net/en/stage/2.1/requirements.md)
* [STAGE Resources](https://manuals.riedel.net/en/stage/2.1/resources.md)
## Preparations
Before installation, the following preparations must be made in Riedel Software Manager (RSM).
The use of the Riedel Software Manager is documented in a separate manual.
See chapter [Riedel Software Manager](https://manuals.riedel.net/rsm?contextKey=RSM&version=latest&language=en).
* [Preparation (RSM)](https://manuals.riedel.net/rsm?contextKey=Preparation&version=latest&language=en)
* Prepare Operating Systems
* Download required Assets
* [Usage (RSM)](https://manuals.riedel.net/rsm?contextKey=Usage&version=latest&language=en)
## Installation
The following subchapters provide a brief summary of:
* [++Installation of STAGE++](https://manuals.riedel.net/stage?contextKey=stage_-stage-installation&version=latest&language=default)
* [Installation of WebRTC](https://manuals.riedel.net/vsp?contextKey=vsp_-webrtc-installation&version=latest&language=default)
* [Installation of SAME](https://manuals.riedel.net/same?contextKey=same_-same-installation&version=latest&language=default)
---
version: "2.1"
language: "en"
---
# Job Activation
Job Activation is how you start a Production session.
When a Job is activated, the system resources specified in the Job Adoption are allocated to the Job so that no other Jobs can access them. When a Job is deactivated, these system resources are released so that they can be used by other Jobs.
## Overview
##  Jobs
Select a Job and the desired Adoption.
This section is identical in the Setup and Activation views and is described in chapter [Job Setup](https://manuals.riedel.net/en/stage/2.1/job-setup.md).
##  Job Resources
This section gives an overview of all the resources defined in the Job as well as an indication of the adopted system resources.
| **All** | Shows all Application Types. status indicators for each Job resource |
| **\[Job Resources Groups\]** | Shows only Job Resources of the corresponding Type: **Members** , **Devices** and **Applications**. |
|  | Set a filter to display only content whose search text is found in the name. |
| **Location Constraint:** | |
| **Show Issues Only** | If enabled, only Job Resources with issues are listed. |
|  | Indicates the availability of the Job Resources:  : Indicates that the Job Resource is available.  : Indicates Warnings of Job Resources. |
| **Job Resource** | Name and group of the Job Resource. |
| **System Resource** | Shows the name of the **Virtual Device** that is created and mapped to the Hardware Device in [I/O Management \| \[mediaInline\] Virtual Devices](https://manuals.riedel.net/en/stage/2.1/i-o-management.md#%25E2%2580%258B%255BmediaInline%255D-%25E2%2580%258BVirtual-Devices). |
| **Location** | Shows the name of the **Location** where the Virtual Device is registered [I/O Management \| \[mediaInline\] Locations](https://manuals.riedel.net/en/stage/2.1/i-o-management.md#%255BmediaInline%255D--Locations). |
| **Type** | Shows the type of the Job Resource. |
| **Description** | Shows a brief description of the warnings about Job Resources. |
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
##  Filter (Job Resources)
Filter the Job Resources. See chapter [Getting Familiar with the User Interface \| Filtering](https://manuals.riedel.net/en/stage/2.1/get-familiar-with-the-user-interface.md#Filtering) for more information.
##  Resources Inspector
### Resource Information
This section provides detail warning and error messages of the selected Job Resource.
If nothing is selected in the Job Resources section, the inspector displays all elements for the currently selected Job with the corresponding Adoption.
| **Insufficient Resources** | The Job contains a quantity of Applications of a type that exceeds the number of Applications of this type in the system (e.g., a user added 50 limiters to the Job, the same engines registered and the volumes loaded to these engines only provide 40 limiters, in this case 10 limiters are missing). |
| **Resources Consumed** | The Job contains a quantity of Applications of a type that exceeds the currently available number of Applications of this type (e.g., a user added 50 limiters to the Job, the same engines registered and the volumes loaded to these engines provide 80 limiters, but 40 are already used in other Jobs, in this case 10 limiters are missing). |
| **Insufficient Licenses for this Application** | The Job contains a quantity of Applications of a type requiring a number of license quantities (e.g. SAME PROCs) that exceeds the total number of license quantities of this type in the system (e.g., a user added 50 limiters and 2 mixers to the Job. The Limiters require 5 PROC licenses each, the mixers 20 PROC licenses each, resulting in a total quantity of 290 PROCs required for this Job. There is only 200 SAME PROC licenses available in the system, in this case 90 are missing). |
| **Licenses Consumed** | The Job contains a quantity of Applications of a type requiring a number of license quantities (e.g. SAME PROCs) that exceeds the **currently**available number of license quantities of this type (e.g., a user added 20 limiters and 2 mixers to the Job. The Limiters require 5 PROC licenses each, the mixers 20 PROC licenses each, resulting in a total quantity of 140 PROCs required for this Job. There is 200 SAME PROC licenses available in the system, but 100 are already consumed by other Jobs, in this case 40 are missing). |
| **No Adoption for Device** | The Job Device is not adopted to a System Device in the currently selected Adoption preset. |
| **Device used in another Job** | The Job Device is adopted to a System Device, some consumers of this Device are already in use by another Job Device in the same or another Job. |
| **System Device Mapping incomplete** | The Job Device is adopted to a system Virtual Device, but that Virtual Device has an incomplete mapping. |
| **System Device Mapping missing** | The Job Device is adopted to a system Virtual Device, but that Virtual Device has an no mapping at all. |
| **Device partly used in another Job** | Only in an active Job: marks where adoption failed for Consumer (Legs) because they are in use somewhere else (which might be another Job or also within the same Job). |
| **Adopted Host Offline** | The Job Device is adopted a System Device or a system Virtual Device that belongs to a Host that is offline. |
|------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
### Application Details
This section provides Device details of the selected Job Resource.
| **Adopted System Devices** | Shows the name of the **Virtual Device** that is created and mapped to the Hardware Device in [I/O Management \| \[mediaInline\] Virtual Devices](https://manuals.riedel.net/en/stage/2.1/i-o-management.md#%25E2%2580%258B%255BmediaInline%255D-%25E2%2580%258BVirtual-Devices). |
| **System Device Location** | Shows the name of the **Location** where the Virtual Device is registered [I/O Management \| \[mediaInline\] Locations](https://manuals.riedel.net/en/stage/2.1/i-o-management.md#%255BmediaInline%255D--Locations). |
| **Mapped Hardware Device** | Shows the name of the **Hardware Device** that is mapped to the Virtual Device in [I/O Management \| \[mediaInline\] Hardware Devices](https://manuals.riedel.net/en/stage/2.1/i-o-management.md#%255BmediaInline%255D-Hardware-Devices). |
| **Related Hosts** | Shows the name of the **Registered Host** that belongs to the Hardware Device, that is registered to STAGE in [Registration \| \[inlineExtension\] Registered Hosts](https://manuals.riedel.net/en/stage/2.1/kj-registering-devices.md#%255BinlineExtension%255D-Registered-Hosts). |
|----------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
##  Information Bar
This section is identical in the Setup and Activation views and is described in chapter [Setup](https://manuals.riedel.net/en/stage/2.1/job-setup.md).
##  Activation / Deactivation
|  | By activating the selected Job and its Adoption, the specified system resources are allocated to the Job and blocked for other Jobs. |
|  | By deactivating the selected Job and its Adoption, the system resources allocated to the Job are released and are thus available again for other Jobs. |
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------|
---
version: "2.1"
language: "en"
---
# Job Setup
In Job Setup, you create a list of Jobs that are to be made available to STAGE operators.
Each Job defines the resources and configuration required for a production or live event.
* Production personnel involved in the event (for example, audio engineers, producers, directors): the Members
* The audio inputs, outputs, and connected devices: the Devices.
* The processing resources such as DSP functions or audio mixing applications: the Applications.
Configured Jobs can then be activated from the Activation tab for STAGE users to use.
## Overview
##  Jobs
Create Jobs and their associated Adoptions. A Job can have one or more Adoptions.
* **Job:**This groups which system resources STAGE will use.
* **Adoption:** This defines which system resources STAGE will use when the Job is activated.
The content in the "Job/Adoption Setup" section changes according to whether a Job or an Adoption is selected in this "Jobs" section.
Typical Job List showing Jobs and Adoptions (shown with a Job selected )
|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------|
|  | Set a filter to display only content whose search text is found in the name. |
|  | Click to delete the selected Job or Adoption. Default Adoptions cannot be deleted. |
|  | Click to add a Job or Adoption. Each new job automatically includes a Default Adoption. |
|  | Indicates if the Job is active. |
| **Name** | The name of a Job or Adoption. In the tree, double-click the name of a Job or Adoption to rename it. |
|  | Loads the selected Adoption into the active Job. |
##  Job Setup / Adoption Setup
Depending on the selection in the Jobs section (a Job or an Adoption), the following configuration tabs will be displayed, which are described in the subchapters.
* [Configuring a Job Setup](https://manuals.riedel.net/en/stage/2.1/configuring-a-job-setup.md)
* [Adoption Setup](https://manuals.riedel.net/en/stage/2.1/adoption-setup.md)
##  Information Bar
##  Go to Activation
Once you have configured a Job, you need to activate it to make it run.
This is done in the Activation Tab. Click to go to the [Job Activation](https://manuals.riedel.net/en/stage/2.1/job-activation.md) tab.
---
version: "2.1"
language: "en"
---
# Jobs
Jobs
Menu
Jobs
Home
The Jobs consists of the following views:
* [Job Setup](https://manuals.riedel.net/en/stage/2.1/job-setup.md)
In Job Setup, you create a list of Jobs that are to be made available to STAGE operators. Each Job defines the resources and configuration required for a production or live event.
* [Job Activation](https://manuals.riedel.net/en/stage/2.1/job-activation.md)
Job Activation is how you start a Production session.
## What is a Job?
A Job defines the collection of resources required for a production or a live event.
Resources consist of Devices, Applications (i.e. Processing functions), as well as people (called members).
The configuration of these resources as well as the connections between inputs (consumers) and outputs (producers) provided by these resources also live inside a Job and are specific to a production.
## Definitions of the Components that Form a Job
### Roles
* Define operational responsibilities within a production.
* Examples: A1, Producer, Commentator, Engineer.
* Roles determine permissions and workflow access.
* System Roles are available across the entire STAGE environment.
* Job Roles exist only within a specific production.
### Job Devices
* Hardware, software, and virtual resources are assigned to the production.
* Examples: StageLink devices, DSP applications, audio processing resources.
### Job Members
* Personnel assigned to the production.
* Each member is assigned one or more roles.
* Multiple members may share the same role within a Job.
## Organizing Jobs into a Hierarchy
Jobs resources can be organized into a hierarchy, where Members own the resources.
As of STAGE 2.0, the use of members and the assignment of devices or applications to these members is exclusively for organizational purposes. In future versions, this information could also be used to restrict access to Job resources.
A Job is completely independent from the System it lives in, and is adopted into the System each time it is used. This means that a Job of a specific configuration can be reused in various parts of the System without having to do anything to the configuration itself. The connection between the Job and the System is achieved by adopting the Resources in the Job to Resources in the System that have the same Device types.
---
version: "2.1"
language: "en"
---
# Registration
This view allows registering hosts such as WebRTC Gateway servers, SAME DSP Engines, NMOS, and Artist-1024 devices that have been discovered on the network to make the device's resources available for use within STAGE.
This workflow includes:
* Creation of main and sub-locations that represents where equipment is physically located.
* Assignment of Discovered Hosts to their locations.
Registered hosts are used as follows:
* Artist-1024 hosts are used with Virtual SmartPanels through WebRTC Gateways.
* NMOS devices are used with SAME DSP-Engine processing servers.
* Unmanaged hosts (non-NMOS devices that STAGE is unable to configure or control) are used with SAME DSP-Engine processing servers with the help of the device's SDP file.
Hosts to be registered in STAGE must be powered on, configured, network connected, and be ready to be deployed.
**Prerequisite:** To discover and Register NMOS devices in STAGE, NMOS Discovery must be configured and enabled in STAGE. See [System Configuration](https://manuals.riedel.net/en/stage/2.1/discovery.md). STAGE relies on an external NMOS Registry that is available on the network.
## Overview
System Commissioning - Registration
Filters allow you to quickly narrow-down a list to find a device.
See chapter [Getting Familiar with the User Interface \| Filtering](https://manuals.riedel.net/en/stage/2.1/get-familiar-with-the-user-interface.md#Filtering) for more information.
## Quicksteps for Registration of Hosts
Host registration adds hosts to STAGE to allow them to be controlled and monitored. By assigning hosts to locations, STAGE is able to represent how the system is physically organized in the real world.
Proceed as follows.
1. **Optional:** Create one or more locations that represent where the equipment is physically located. See section [Edit / Add Locations below](https://manuals.riedel.net/en/stage/2.1/kj-registering-devices.md#Edit-Add-Locations).
2. Your hosts should automatically be discovered. Select one or more hosts to be assigned to a location. See section [Discovered Hosts below](https://manuals.riedel.net/en/stage/2.1/kj-registering-devices.md#Discovered-Hosts).
3. Select a Location in which the selected hosts will be registered. By assigning a host to a geographic location, STAGE's users have a view of where hosts are physically located. You can then focus your attention on the hosts situated at a specific location. See section [Locations below](https://manuals.riedel.net/en/stage/2.1/kj-registering-devices.md#Locations).
4. Click **Register Host(s) in Selected Location**.
5. Once a host is registered to a location, it is removed from **Discovered Hosts** to be now listed in **Registered Hosts** . See section [Registered Hosts below](https://manuals.riedel.net/en/stage/2.1/kj-registering-devices.md#Registered-Hosts).
6. You can filter the **Registered Hosts** by host type. See section [Host Types below](https://manuals.riedel.net/en/stage/2.1/kj-registering-devices.md#Host-Types).
##  Edit/Add Locations
To assign a host to a location, you must first create the location. Proceed as follows. See also section [Locations below](https://manuals.riedel.net/en/stage/2.1/kj-registering-devices.md#Locations).
1. Click  to quickly create top-level locations
or
2. Click  to open the **Edit Locations** dialog. See also section [Edit Locations Dialog below](https://manuals.riedel.net/en/stage/2.1/kj-registering-devices.md#Edit-Locations-Dialog).
1. Click  to add locations and sub-locations.
2. Click **Duplicate** to duplicate the selected location.
3. Click **Delete** to delete the selected location.
4. Double-click on a location to edit its name.
5. Close the window:
1. Click **Confirm** to apply all changes
or
2. Click **Close** to discard all changes.
##  Discovered Hosts
This section displays all hosts that can be found in the STAGE network through the use of the Discovery protocol. STAGE can discover the following host types:
* A SAME DSP Engine
* NMOS IS-04 compatible devices.
* Unmanaged hosts; this is usually imported using an SDP file for the device.
|  | Indicates whether the host is online (  ), offline (  ) or not available (  ). |
| **Name** | Shows the host name that comes from the host. This name is configured on the host. |
| **IP Address** | Shows the IP address of the hosts. |
|  | Click to register the selected Host(s) in the selected location. Hosts that have been assigned for use by other STAGE instances are also shown. Normally, you have enough hosts available to meet the needs for all productions. However, you can take the host from the other STAGE instance by accepting the following warning:  **Cancel:** Leave the host to run with the other STAGE instance. **Force Register:** Force the host from being used by the other STAGE instance, for it to be used with this STAGE instance. NOTE: This can break the operation of the other STAGE instance. This option should only be used when reconfiguring STAGE or as part of a system recovery procedure instance if it is currently needed by the other STAGE instance. This action can knock a production off the air. This option should only be used when reconfiguring STAGE or as part of a system recovery procedure. |
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
**Prerequisites:**
* Hosts being registered must have network connectivity with STAGE.
See chapter [Network Architecture Requirements](https://manuals.riedel.net/en/stage/2.1/networking-considerations.md) and [Host Discovery below](https://manuals.riedel.net/en/stage/2.1/kj-registering-devices.md#%255BinlineExtension%255D-Host-Discovery).
* Artist-1024 devices that are to be used with STAGE must have been previously configured in Director to have one or more **STAGE Ports** . See section [Further VSP Registration Details](https://manuals.riedel.net/en/stage/2.1/further-vsp-registration-details.md). Stage Ports are required by the Virtual SmartPanel for use as intercom ports, to allow inter-operability with the Artist system.
* WebRTC Gateway devices must have been previously configured.
See [++Installation of WebRTC++](https://manuals.riedel.net/vsp?contextKey=vsp_-webrtc-installation&version=latest&language=default).
* SAME devices must have been previously configured.
See [Installation of SAME](https://manuals.riedel.net/same?contextKey=same_-same-installation&version=latest&language=default).
##  Locations
This section specifies the location/sub-location to which the discovered hosts are assigned.
A location is metadata that gives an indication where the registered hosts are located. For example, a location can represent a country, a city or a building, while a sub-location can be more specific and represent a building, a floor or an equipment room. Users can use the locations in the way that suits them best.
By default, STAGE uses the **Unassigned Location** option, which allows users to register a host if they do not want to register it at a specific location.
|  | Click to open a window for editing (adding, renaming, duplicating or deleting) top-level and sub-locations. See section [Edit Locations Dialog below](https://manuals.riedel.net/en/stage/2.1/kj-registering-devices.md#Edit-Locations-Dialog). |
|  | Click to add a top-level location. |
| **Locations** | If a location is selected, the **Registered Hosts** list only shows hosts that are assigned to that location. Sub-locations can be displayed/hidden by clicking on the right  or down  symbol. |
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
### Edit Locations Dialog
This **Edit Locations** dialog can be opened by clicking the  icon in the Locations section.
Edit Locations dialog
|  | Set a filter to display only content whose search text is found in the name. |
|  | Click to add locations and sub-locations. |
| **Delete** | Click to delete the selected location. |
| **Duplicate** | Click to duplicate the selected location. |
| **Double-click** | Double-click on a location to edit its name. |
| **Confirm** | Click to exit this dialog and apply all changes. |
| **Close** | Click to exit this dialog and discard all changes. |
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------|
##  Register Host(s) in Selected Location
Proceed as follows to register hosts in a location.
1. **Optional:** Focus the list of **Discovered Hosts** to hosts found in the system by selecting the search and All/Online/Offline filters. See also section [Discovered Hosts above](https://manuals.riedel.net/en/stage/2.1/kj-registering-devices.md#Discovered-Hosts).
2. **Optional:** Focus the list of **Locations** to a location by selecting a location in **Locations** . See also section [Locations above](https://manuals.riedel.net/en/stage/2.1/kj-registering-devices.md#Locations).
3. In **Discovered Hosts** , select one of more registered Hosts. See also section [Discovered Hosts above](https://manuals.riedel.net/en/stage/2.1/kj-registering-devices.md#Discovered-Hosts).
4. In Locations, select one location. See also section [Locations above](https://manuals.riedel.net/en/stage/2.1/kj-registering-devices.md#Locations).
5. Click **Register Host(s) in Selected Location**.
* On the left, the discovered Host will disappear in the section **Discovered Hosts**.
* On the right, the registered Host will appear in the section **Registered Hosts**.
##  Registered Hosts
This section lists all hosts that are currently registered at the selected location.
|  | Set a filter to display only content whose search text is found in the name. |
| **Create Unmanaged Host** | Click to add a host that STAGE is unable to configure or control, but this host's AES67 audio stream(s) can be used by STAGE. See [Unmanaged Host Configuration](https://manuals.riedel.net/en/stage/2.1/unmanaged-host-configuration.md). |
|  | Indicates whether the host is online (  ), offline (  ) or not available (  ). |
| **Name** | Shows the name of the registered host. |
| **IP Address** | Displays the IP address of the registered host. |
| **Host Type** | Shows the type of the registered host. |
| **Location** | Shows the assigned location for this host. |
|  | Click to deregister the selected host(s) from the selected location. |
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
##  Host Types
Focus the list of **Registered Hosts** to a host type (for example, Artist-1024, or WebRTC Gateway) by selecting a host in **Host Types**.
This section lists all host types that are available in the STAGE system.
|  | Set a filter to display only content whose search text is found in the name. |
| **Host Types** | If a **Host Type** selected, the**Registered Hosts** list only shows that host type. |
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------|
##  Deregister Host(s)
Proceed as follows to deregister hosts from a location.
1. **Optional:** Focus the list of **Registered Hosts** to hosts found in a location by selecting a location in **Locations** . See also section [Locations above](https://manuals.riedel.net/en/stage/2.1/kj-registering-devices.md#Locations).
2. **Optional:** Focus the list of **Registered Hosts** to a host type (for example, Artist-1024, or WebRTC Gateway) by selecting a host in **Host Types** . See also section [Host Types above](https://manuals.riedel.net/en/stage/2.1/kj-registering-devices.md#Host-Types).
3. In **Registered Hosts** , select one of more registered Hosts. See also section [Registered Hosts above](https://manuals.riedel.net/en/stage/2.1/kj-registering-devices.md#Registered-Hosts).
4. Click **Deregister Host(s)**.
5. Click **Deregister**.
* On the right, the deregistered Host will disappear in the section **Registered Hosts**.
* On the left, the deregistered Host will appear in the section **Discovered Hosts**.
## Host Discovery
This is an overview of how STAGE typically discovers network-connected host instances, to add them to the Riedel Registry. This makes the host available for use in STAGE.
Riedel hosts use common network services such as DHCP and DNS to find STAGE in an automatic fashion resulting in STAGE being able to register them.
For certain hosts, you will have to manually configure them with STAGE's IP address so that they appear in the section **Discovered Hosts**.
### Prerequisites
The host to be discovered must have IP connectivity with:
* **For automatic discovery:** the following network servers:
* DHCP server.
* DNS server.
* STAGE server.
* **For a manually configured connection:** the STAGE server.
## Further Registration Configuration Details
See:
* [Further VSP Registration Details](https://manuals.riedel.net/en/stage/2.1/further-vsp-registration-details.md)
* [Further Unmanaged Host Registration Details](https://manuals.riedel.net/en/stage/2.1/further-unmanaged-host-registration-details.md)
---
version: "2.1"
language: "en"
---
# Host Configuration
This view allows setting the configuration parameters of each registered host.
To register a host, see chapter [Registration](https://manuals.riedel.net/en/stage/2.1/kj-registering-devices.md).
## Overview
System Commissioning - Configuration
Filters allow you to quickly narrow-down a list to find a device.
See chapter [Getting Familiar with the User Interface \| Filtering](https://manuals.riedel.net/en/stage/2.1/get-familiar-with-the-user-interface.md#Filtering) for more information.
## Quicksteps for Host Configuration
Proceed as follows.
1. In **Locations** , select a location where the host is located to focus the list in **Host Types** to the host you want to configure.
2. In **Host Types**, select the host type you want to configure.
3. Select a host.
4. According to the host type you have selected, set the host's parameters in the right-hand panel.
| **Host Type** | **Applies to VSP** | **Applies to SAME** | **See Chapter** |
|-----------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Artist-1024 |  | | VSP [Artist-1024 Configuration](https://manuals.riedel.net/vsp?contextKey=vsp_-artist-1024-configuration&version=latest&language=default). For users of the Adobe Acrobat (PDF) version of this user guide, see *Artist-1024 Configuration* in the **VSP User Guide** . See [STAGE Resources](https://manuals.riedel.net/en/stage/2.1/resources.md). |
| WebRTC Gateway |  | | VSP [WebRTC Gateway Configuration](https://manuals.riedel.net/vsp?contextKey=vsp_-webrtc-gateway-configuration&version=latest&language=default). For users of the Adobe Acrobat (PDF) version of this user guide, see *WebRTC Gateway Configuration* in the **VSP User Guide** . See [STAGE Resources](https://manuals.riedel.net/en/stage/2.1/resources.md). |
| SAME DSP-Engine | |  | SAME [SAME DSP Engine Configuration](https://manuals.riedel.net/same?contextKey=same_-same-dsp-engine-configuration&version=latest&language=default). When the SAME DSP Engine is in Direct Control Mode, see SAME [Putting a SAME DSP Engine Under Northbound Control](https://manuals.riedel.net/same?contextKey=same_-putting-same-under-northbound-control&version=latest&language=default). For users of the Adobe Acrobat (PDF) version of this user guide, see *SAME DSP Engine Configuration* and *Putting a SAME DSP Engine Under Northbound Control* in the **SAME User Guide** . See [STAGE Resources](https://manuals.riedel.net/en/stage/2.1/resources.md). |
| Unmanaged Host | |  | [Unmanaged Host Configuration](https://manuals.riedel.net/en/stage/2.1/unmanaged-host-configuration.md) |
| NMOS-IS04 | |  | [NMOS-IS04 Configuration](https://manuals.riedel.net/en/stage/2.1/nmos-is04-configuration.md) |
##  Locations
This section lists all locations defined in the STAGE system. To add or edit locations, see chapter [STAGE_ Registration \| Locations](https://manuals.riedel.net/en/stage/2.1/kj-registering-devices.md#%255BmediaInline%255D-Locations).
|  | Set a filter to display only content whose search text is found in the name. |
| **Locations** | If one or more locations are selected, only host types that are located at the selected locations are displayed in the Host types section. Other host types are hidden. If no location is selected, all host types available in the STAGE system are displayed. |
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
##  Host Types
This section lists all host types that are available in the STAGE system. The host types displayed may be reduced if one or more locations are selected in the Locations section.
|  | Set a filter to display only content whose search text is found in the name. |
| **Host Types** | Select one host type to show available hosts in the Hosts section. |
| **Items** | Displays the number of available host types (at the filtered locations). |
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------|
##  Host Selection
This section lists all hosts of the selected host type that are available in the STAGE system.
|  | Set a filter to display only content whose search text is found in the name. |
|  | Indicates whether the host is online (  ) or offline (  ). |
| **Name** | Select one host to show the available configuration details in the Setup section. |
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
##  Setup
Depending on the selected host type, the available parameters differ, as described in the following subchapters.
* [Artist-1024 Configuration](https://manuals.riedel.net/en/stage/2.1/artist-1024-configuration.md)
* [WebRTC Gateway Configuration](https://manuals.riedel.net/en/stage/2.1/webrtc-gateway-configuration.md)
* [SAME DSP Engine Configuration](https://manuals.riedel.net/en/stage/2.1/same-dsp-engine-configuration.md)
* [Unmanaged Host Configuration](https://manuals.riedel.net/en/stage/2.1/unmanaged-host-configuration.md)
* [NMOS-IS04 Configuration](https://manuals.riedel.net/en/stage/2.1/nmos-is04-configuration.md)
---
version: "2.1"
language: "en"
---
# Legal Notice
Under the copyright laws, this manual may not be copied, in whole or in part, without the written consent of Riedel. Every effort has been made to ensure that the information in this manual is accurate. Riedel is not responsible for printing or clerical errors. All trademarks are the property of their respective owners.
This manual, as well as the software and any examples contained herein are provided "as is" and are subject to change without notice. The content of this manual is for informational purpose only and should not be construed as a commitment by Riedel Communications GmbH or its suppliers. Riedel Communications GmbH gives no warranty of any kind with regard to this manual or the software, including, but not limited to, the implied warranties of merchantability and fitness for a particular purpose.
Riedel Communications GmbH shall not be liable for any errors, inaccuracies or for incidental or consequential damages in connection with the furnishing, performance or use of this manual, the software or the examples herein. Riedel Communications GmbH reserves all patent, proprietary design, title and intellectual property rights contained herein, including, but not limited to, any images, text, photographs incorporated into the manual or software.
All title and intellectual property rights in and to the content that is accessed through use of the products is the property of the respective owner and may be protected by applicable copyright or other intellectual property laws and treaties.
In addition, some content on this website may be owned by a third party and is protected by any applicable copyrights governing its use. Riedel is not responsible for content and compilation of external linked pages of third parties and is therefore not liable for those pages.
---
version: "2.1"
language: "en"
---
# License Management
This view allows managing and validating STAGE licensing.
Certain STAGE features require a license in order to use them.
## Overview
System Management - License Management
License Management has the following sections:
* **License Settings:** Manage license import and update. When a license in license options is selected, this shows more information about that license. See section [License Management \| About License Parameters](https://manuals.riedel.net/en/stage/2.1/license-management.md#About-License-Parameters) .
* **License Options:** shows an overview of the current licenses, their status and details. See section [License Management \| License Options](https://manuals.riedel.net/en/stage/2.1/license-management.md#License-Options) .
## About Licensing
To assign a user to a port, see chapter VSP [User / Port Assignment](https://manuals.riedel.net/vsp?contextKey=vsp_-userport-assignment&version=latest&language=default).
A license (.lic) file must have been previously purchased and retrieved from the Riedel Customer License portal before you can apply it to STAGE. Contact your sales representative for more information about licensing options.
Applying a license to STAGE involves the following steps.
1. The license (.lic) must be uploaded to STAGE.
2. The license must be verified.
Only once this second step is complete will the license be activated.
License verification will need to happen after uploading the License on STAGE. In addition, periodical license verification is also required for a License to remain active over time. Please refer to [License Management \| License Verification](https://manuals.riedel.net/en/stage/2.1/license-management.md#License-Verification) for more details.
### Virtual SmartPanel Licensing
The license defines the maximum number of ports that can be in use by Virtual SmartPanel users on a first come, first served basis as users login to the Virtual SmartPanel. To release a license, a user must log out of their Virtual SmartPanel instance. Licenses can be reserved for one or more users such that these users will have priority access to using their Virtual SmartPanel. A reserved license is permanently blocked by its assigned user and is unavailable for use by any other user.
### SAME DSP-Engine Licensing
The SAME DSP-Engine licensing has the following components:
* *SAME Base license* option is mandatory for SAME to operate.
* *SAME PROC*license scale the amount of Volumes that can be activated at one time. Any SAME PROC licenses are invalid when the SAME Base license option is absent.
How licensing is applied depends on whether the SAME DSP-Engine is in third party mode or native mode.
* If a SAME Volume is loaded on a SAME engine in third party mode, PROC licenses are consumed for all parts of the SAME volume.
* If a SAME Volume is loaded on a SAME engine in native mode, then SAME PROC licenses are only consumed when the corresponding SAME processing functions are in use by an active Job.
## Managing your STAGE License
### Uploading a License
A license is applied to STAGE by uploading a license file from your PC. This must only be carried out during off hours as it will cause a service outage.
##  License Settings
### License Details
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Licensed to** | Shows the Account name to which the license is linked. **No License:** No license has been uploaded to STAGE. When STAGE does not hold licenses, then features referred to by those licenses shall be disabled. Contact your sales representative for more information about licensing options. **License Verified:** A license has been uploaded to STAGE. Please refer to [License Management \| License Options](https://manuals.riedel.net/en/stage/2.1/license-management.md#License-Options) for more information about the licensed features and supported capacity. **License not Verified:** A license has been successfully uploaded to STAGE, however license verification has not been performed. Refer to [License Management \| License Verification](https://manuals.riedel.net/en/stage/2.1/license-management.md#License-Verification) for more details. |
|  | Click for more information about the uploaded license.  **Licensed to:** Shows the Account name to which the license is linked. **Identifier:** The Identifier corresponds to the Serial Number of the STAGE system, which is also visible under [System Configuration](https://manuals.riedel.net/en/stage/2.1/discovery.md) . **Valid:** Shows the current license status with internal license information. **Identity Lease:** Shows the current lease status with detailed information about request, renewal and expiration dates and times of the license. **Host signature:** Shows the status of the host's signature. |
|  | **Upload License / Replace License:** Click to upload a (new) license. When a license is currently active, this will replace the current license with a new license. See section [License Management \| Uploading a License](https://manuals.riedel.net/en/stage/2.1/license-management.md#Uploading-a-License). |
|  | Click to force a license verification with the Riedel Licensing service. When successful, this updates STAGE with the latest available licensing, which should be done if the license options part of the license have changed. This could happen if additional license options have been added to the license or if the license option quantities were modified. |
### License Verification
|-----------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Riedel Online License Service** | Shows the connection status to the Riedel Licensing service. When STAGE does not have internet access to the Riedel Licensing service, you have to manually verify the uploaded license file (.lic). See **Manual License Verification** below. |
| **Mode** | Shows the license verification status. **Not verified:** STAGE failed to verify the system's identity with the Riedel Licensing Service. **Periodical Verification:**STAGE successfully verified the system's identity. |
| **License Verfification Status** | Shows the status of the license verification including the date (mm/dd/yyyy) until when the license is considered verified. Beyond that date, the license will become inactive. |
| **Manual License Verification** | When STAGE does not have internet access to the Riedel Licensing service, you have to manually verify STAGE licenses.  Download a license request file (.ilr) onto your PC.  Upload a license file (.ilc) into STAGE. |
1. Contact your sales representative to obtain a license file.
2. If the license is in a .ZIP file, unzip the contents to extract the .lic file.
3. Click **Upload License** / **Replace License**.
4. Click **Browse**to select the license file from Riedel to install your licensed features.
5. Click **Upload License**to install your new license.
#### Automatic License Verification
If STAGE has internet connectivity, the uploaded license shall be verified with Riedel Online Licensing Service to ensure that it is only used for a single STAGE instance. A license becomes active only once it has been verified. This process binds the license to the this STAGE instance so that it cannot be activated on another STAGE instance.
#### Manual License Verification
When STAGE cannot automatically verify an uploaded license (the **Riedel Online Licensing Service** status is **Unavailable**), you must manually do this to ensure continued operation.
1. Click **Download Request File** (.ilr)and save the file to your PC.
2. Go to Riedel Client License Portal to verify the License Request file (.ilr).
3. Retrieve the Confirmation file (.ilc) from Riedel Customer License Portal that has been generated for this specific STAGE installation.
4. Click **Upload Confirmation File**and select the confirmation file from Riedel to activate your licensed features.
5. Click **OK**.
##  License Options
### License Consumption
This shows details of the currently active licenses.
A horizontal bar indicates the total number of licenses. The dark blue portion shows the number of licenses currently in use, the light blue portion shows the number of reserved licenses, and the green portion shows the number of available licenses.
### License Options
This shows information about licenses that have already been enabled in STAGE and the current license status.
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------|
|  | Enter keywords or text to filter the table on pertinent content. |
|  | Shows the license's status. See chapter [Getting Familiar with the User Interface](https://manuals.riedel.net/en/stage/2.1/get-familiar-with-the-user-interface.md). |
| **License Option** | Shows the feature being licensed. |
| **Quantity** | Shows the number users or hardware (panels, servers, and so on) that are included in the license. |
| **License Information** | Shows information about the license. |
| **Start Date** | The date from which the license is valid is displayed if the license is only valid for a limited period of time. |
| **End Date** | The date until which the license is valid is displayed if the license is only valid for a limited period of time. |
| **Remaining Days** | Shows the number of days remaining until the license expires if the license is only valid for a limited period of time. Otherwise, this shows **Perpetual**. |
### License Warnings
This section provides information which is especially relevant for license options that are valid for a limited period of time.
The information displayed in this table indicates the total quantity of a given license option available at a specific date. A new row is added each time the total quantity of a given license option changes.
For example, if STAGE initially holds 1000 SAME Proc license options and that an additional 2000 SAME Proc license options become active on 12.1.2026, then the License Warning table will show a first row a quantity of a 1000 SAME Proc license options before 12.1.2026, and then show an additional row indicating 3000 SAME Proc license on 12.1.2026."
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------|
|  | Enter keywords or text to filter the table on pertinent content. |
|  | Shows the license's status. See chapter [Getting Familiar with the User Interface](https://manuals.riedel.net/en/stage/2.1/get-familiar-with-the-user-interface.md). |
| **License Option** | Shows the feature being licensed. |
| **Quantity** | Shows the number users or hardware (panels, servers, and so on) that are included in the license. |
| **Warning Information** | Shows information about the license option at the indicated date. |
| **Date** | Shows the date that corresponds to the mentioned quantity. |
---
version: "2.1"
language: "en"
---
# Menu
The menu is located on the left-hand side of the window and contains links to all views of the STAGE user interface. Clicking on an icon opens the corresponding view.
## Collapsed Menu
The menu is collapsed by default and only shows the main icons of the user interface.
If the mouse pointer is moved over an icon, the title of the view is displayed as a tooltip.
Menu -- Collapsed
## Expand Menu
The complete menu is expanded by clicking on the menu icon at the top left.
The expanded menu is automatically collapsed by clicking in another section of the window or by clicking on the  symbol at the top right of the window.
Expand Menu
## Expanded Menu
### STAGE Version
On top of the expanded menu the STAGE software version is indicated. The version is also displayed in the view [Home \| STAGE Version](https://manuals.riedel.net/en/stage/2.1/home.md#STAGE-Version) .
### Main Icons \& Views
The expanded menu also lists the individual views that are available under the main icons and can be accessed directly by clicking on them.
### User Manual
By clicking on the  button, the online help on the Riedel website can be accessed.
### Logout
By clicking on the  button at the bottom, the currently logged in user can log out of the STAGE system. The Logout is also possible in the collapsed menu by clicking on the  icon.
Menu -- Expanded
---
version: "2.1"
language: "en"
---
# Live Metrics
This view allows retrieving live measurement data from connected systems (e.g. the CPU load of a WebRTC gateway).
## Overview
System Health - Live Metrics
Filters allow you to quickly narrow-down a list to find a device.
See chapter [Getting Familiar with the User Interface \| Filtering](https://manuals.riedel.net/en/stage/2.1/get-familiar-with-the-user-interface.md#Filtering) for more information.
## Quicksteps for Retrieving Host Information
1. Optionally, you can use filters by **Locations** to narrow down the list of desired entries.
2. Optionally, you can use filters by **Host Types** to narrow down the list of desired entries.
3. Select one or more hosts from which information is to be retrieved.
Optionally, you can filter by **Name**.
4. Select the desired tab to display the required information. See [Metrics below](https://manuals.riedel.net/en/stage/2.1/metrics.md#Metrics) for the available information.
##  Locations Filter
Focus the list of entries for **Locations**.
|  | Set a filter to display only content whose search text is found in the name. |
| **Location** | Select one or more locations where the hosts whose metrics are to be displayed are located. |
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
##  Host Types Filter
Focus the list of entries for **Host Types**.
|  | Set a filter to display only content whose search text is found in the name. |
|  | Button for unchecking ticked boxes. (At the top for all boxes or in the corresponding section.) |
|  | Button for changing the status of the boxes. (Ticked boxes are discarded, unticked boxes are ticked). |
|  | Button for deactivating the filter without changing the ticked boxes. Click on this symbol again to reactivate the filter with the same settings. |
| **Host Types** | Tick the desired host type thar are to be displayed. |
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------|
##  Hosts Selection
Focus the list of entries for **Hosts** and select one or more hosts from which information is to be retrieved.
|  | Set a filter to display only content whose search text is found in the name. |
|  | Shows the host's current status. See chapter [Getting Familiar with the User Interface \| Status Indicators and Icons](https://manuals.riedel.net/en/stage/2.1/get-familiar-with-the-user-interface.md#Status-Indicators-and-Icons). |
| **Name** | Name of the host. |
| **Host Type** | Type of the host. |
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
##  Metrics
The following information is available on the corresponding tabs:
| **Tab** | **Column** | **Description** |
| **Host** |  | Shows the host's current status. This column is displayed on every tab. See chapter [Getting Familiar with the User Interface \| Status Indicators and Icons](https://manuals.riedel.net/en/stage/2.1/get-familiar-with-the-user-interface.md#Status-Indicators-and-Icons). |
| **Host** |
| **Host** |
| **Host** |
| **Host** |
| **Host** |
|----------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| **Host** | Shows the name of the host. This column is displayed on every tab. |
| **Memory Usage** | Shows the current memory usage in gigabytes. |
| **Total Memory** | Shows the current total memory in gigabytes. |
| **Filesystem Size** | Shows the current total disk size in gigabytes. |
| **Filesystem Usage** | Shows the current disk size usage in gigabytes. |
| **CPU Usage** | Shows the CPU's current usage as a percentage. |
| **State** | Shows the power supply's current status. |
| **Voltage** | Shows the power supply's current voltage. |
| **Temperatures** | Shows the device's temperature in °C. |
| **Rotation** | Shows the fan's current rate of rotation in RPM. |
| **SFP Type** | Shows the type of SFP module that has been plugged in. |
| **SFP Presence** | Shows whether the SFP is present or not. |
| **RX / TX Power** | Shows the optical input (RX) / output (TX) power in dBm. |
| **Signal Presence** | Shows whether the SFP receives a signal or not. |
| **Temperature** | Shows the SFP's temperature in °C. |
| **Type** | This device 's clock estimates the time offset from the PTP primary clock to attempt to align its own time to that of the primary clock. **Unknown:** The current PTP status is offline or unavailable. **PtpOrdinary:** This device is a PTP TimeReceiver and is not a PTP TimeTransmitter. **PtpBoundary:** This device is a PTP TimeReceiver and is also a PTP TimeTransmitter to other devices. **PtpTransparent:** This device simply forwards PTP messages to other devices, as such, it is not a PTP TimeTransmitter. NOTE: This mode does not work between different VLANs. **PtpManagementNode:**This device can manage and monitor PTP parameters without an out-of-band monitoring system. In most cases, any Host registered in STAGE will be a PTP Ordinary Clock. |
| **Grandmaster** | Shows the PTP Grandmaster ID of the received PTP clock (Boundary clock). |
| **Lock State** | Shows the device's current PTP synchronization state. **Unknown** : The lock state could not be determined. **UnLocked** : PTP is not locked. **HoldOver** : The PTP synchronization state is not locked, the device has transitioned out of synchronization state and the Holdover time has not expired. **Locking** : PTP source found and the clock is aligned. **LockedCoarse** : At least one PTP source is coarse locked. **LockedFine** : At least one PTP source is fine locked. **PtpNone** : No PTP clock available. **PtpInitializing** : Clock is initialized to synchronize to PTP. **PtpFaulty** : Clock wasn't able to lock to PTP. **PtpDisabled** : PTP clock disabled. **PtpListening** : The PTP synchronization state is waiting for the announceReceiptTimeout to expire or to receive an Announce message from the PTP TimeTransmitter. **PtpPreTimeTransmitter** : The PTP synchronization state is the PTP TimeTransmitter has not sent any messages, except for signaling or management messages. **PtpTimeTransmitter** : PTP clock is used for time distribution. **PtpPassive** : The PTP synchronization state is the PTP TimeTransmitter is not sending any messages. **PtpUncalibrated** : The PTP synchornization state is one or more master ports have been detected in the domain. The appropriate master port has been selected, and the device is preparing to synchronize to the selected master port. This is a transient state to initiate the servo synchronization, datasets updates, and other implementation-specific activities. **PtpTimeReceiver** : PTP clock is received and used as system clock. **PtpGrandTimeTransmitter**: PTP clock is GrandMaster. |
| **Mean Delay** | Shows the mean time in nanoseconds that PTP packets take to travel between the PTP TimeTransmitter and the device. |
| **Offset** | Shows the current timing offset in nanoseconds. Ideally, this should be near zero. |
| **Offset** | Shows the current time offset of this interface compared to the clock. |
| **Speed** | Shows the current connection speed of the network port. |
| **Link State** | Shows if the link has been established. |
| **RX Speed /** **TX Speed** | Shows the speed currently used in the respective direction. |
| **RX Packets/s /** **TX Packets/s** | Shows the packets currently received (RX) / transmited (TX) per second. |
| **RX Octets** **/** **TX Octets** | Shows the number bytes that have been received (RX) / transmitted (TX). |
| **RX Error Packets** **/** **TX Error Packets** | Shows the number of faulty packets on the receive (RX) /transmit (TX) side. |
| **RX Dropped Packets** **/** **TX Dropped Packets** | Shows the number of discarded packets on the receive (RX) / transmit (TX) side. |
| **Total RX Errors /** **Total TX Errors** | Shows the total number of failing packets on the receive (RX) / transmit (TX) side. |
| **Leg** | Shows the leg of the transmitted stream. |
| **PTP Offset** | Shows the current time offset in nanoseconds of the transmitter compared to the PTP clock. |
| **TX Packets/s** | Shows the packets currently transmitted per second. |
| **Bitrate** | Shows the bit rate in megabits per second on the transmit side. |
| **Leg** | Shows the leg of the received stream. |
| **Connected Sender** | Shows the ID of the connected sender. |
| **PTP Offset** | Shows the current time offset in nanoseconds of the receiver compared to the clock. |
| **RX Packets/s** | Shows the packets currently received per second. |
| **Bitrate** | Shows the bit rate in megabits per second on the receive side. |
| **Corrupt Packets** | Shows the number of faulty packets on the receive side. |
| **Reordered Packets** | Shows the number of reordered packets on the receive side. |
| **Lost Packets** | Shows the number of lost packets on the receive side. |
| **Connection State** | Shows the connection state to the WebRTC server: **New** , **Connecting** , **Connected** , **Disconnected** , **Failed** , **Closed**. |
| **Inbound Packets RX /** **Outbound Packets TX** | Total number of RTP packets received (RX) / transmitted (TX) for this SSRC. This includes retransmissions. |
| **Inbound Last packet Received Timestamp** | Represents the timestamp at which the last packet was received on this particular candidate pair, excluding STUN packets. |
| **Inbound Bytes RX /** **Outbound Bytes TX** | Total number of bytes received (RX) / transmitted (TX) for this SSRC. |
| **Remote Inbound Packets RX /** **Remote Outbound Packets TX** | Number of Bytes that have been received (RX) / transmitted (TX). |
| **Remote Inbound Packets Lost** | Number of lost packets on the receive side. |
| **Remote Outbound Bytes TX** | Number of bytes that have been transmitted (TX). |
| **Remote Inbound RTT** | Estimated round trip time for this SSRC, based on the RTCP timestamps in the RTCP Receiver Report (RR) and measured in seconds. |
| **Remote Outbound RTT** | Estimated turnaround time for this SSRC based on the last RTCP transmitter report (SR) containing a DLRR report block. |
| **Remote Inbound Total RTT /** **Remote Outbound Total RTT** | Represents the cumulative sum of all round trip time measurements in seconds since the beginning of the session. |
| **Remote Inbound RTT Measurement** | Represents the total number of RTCP RR blocks received for this SSRC that contain a valid round trip time. |
| **Remote Outbound RTT Measurement** | Represents the total number of RTCP Sender Report (SR) blocks received for this SSRC that contain a DLRR report block that can derive a valid round trip time. |
| **Remote Inbound Fraction Lost** | The fraction packet loss reported for this SSRC. |
---
version: "2.1"
language: "en"
---
# Network Architecture Requirements
Networking connectivity is required for STAGE to communicate with devices under STAGE's control, to provide the user interface to the operators and engineers and also to provide northbound APIs to other systems communicating with STAGE.
## Network Data Types
In an intercom / broadcast network, in general, there are two categories of data being carried on IP networks:
* Management data that consists of the signalling, control, and health information communicated with connected endpoint devices. This data is used by a control network to operate these devices, in this case through STAGE.
* Media data that consists of high-bandwidth SMPTE ST 2110 audio, video, and ancillary flows.
## Interface Types
### Management Interface
Network interfaces used for management purposes typically are connected to a control network which connects the management interfaces of other endpoint devices in the system. In the simplest case, the server hosting the STAGE system will be connected with a single network interface to a management network.
Ensure that Network Interface used for the management network has its gateway set.
#### Using Multiple Management Interfaces
In some scenarios, it might be required to have network connectivity with multiple networks from the same STAGE instance for network segmentation. For this, multiple network interfaces must be configured at the Linux host level.
If you are using multiple network interfaces, make sure at least one of them has its gateway set and it is always available.
### Media Interface(s)
STAGE itself does not perform media processing, so connections to media networks (e.g. "RED" and "BLUE" networks) are generally not required for STAGE nodes, except in use cases where in-band management traffic is required (see following chapter).
### In-band vs. Out-of-Band Management
Most devices have two or more network interfaces that are connected to separate network segments (switches). One network interface is used for management purposes (out-of-band management) by connecting it to the management network segment. The remaining network interfaces are used for media streaming. STAGE nodes will have their network interfaces connected to the management network segment to provide connectivity to the management interface of all device endpoints.
Some devices may not have a separate network interface for management purposes. In this case, the management functionality is combined into the media interface(s) (in-band management). In this scenario, STAGE's management interfaces will need to have connectivity to the device's media interfaces (for example, through an appropriate routing set up in the network itself) or the STAGE host must be connected with a dedicated network interface to these network segments.
*** ** * ** ***
See also for:
* SAME DSP Engine:
*
* [SAME_ SAME DSP-Engine Network Architecture](https://manuals.riedel.net/same?contextKey=same_-same-dsp-engine-network-architecture&version=latest&language=default)
* Virtual SmartPanel:
* [Virtual SmartPanel Network Architecture](https://manuals.riedel.net/vsp?contextKey=vsp_-virtual-smartpanel-network-architecture&version=latest&language=default)
* [Network Setup in High-Availability Scenarios](https://manuals.riedel.net/vsp?contextKey=vsp_-network-setup-in-high-availability-scenarios&version=latest&language=default)
---
version: "2.1"
language: "en"
---
# NMOS-IS04 Configuration
## Introduction
STAGE can discover AMWA NMOS devices that are available on the network. STAGE relies on an external NMOS Registry to do this. First, you must configure STAGE's connection to the NMOS Registry; see chapter [System Configuration \| NMOS IS 04 / IS 05 Discovery](https://manuals.riedel.net/en/stage/2.1/discovery.md#NMOS-IS-04-/-IS-05-Discovery).
Once this has been configured, discovered NMOS hosts appear in [Registration \| \[mediaInline\] Discovered Hosts](https://manuals.riedel.net/en/stage/2.1/kj-registering-devices.md#%255BmediaInline%255D--Discovered-Hosts).
In order to configure an NMOS host, it must first be registered in STAGE. See chapter [Registration](https://manuals.riedel.net/en/stage/2.1/kj-registering-devices.md). NMOS host configuration is limited. You can:
* Edit its name and description.
* Assign a network scope to individual Network interfaces.
All other host configuration parameters are read-only in STAGE; this configuration information comes from the NMOS host having been configured by its third-party software, or by the NMOS Registry.
## How the Number of Audio Channels in STAGE works with AMWA NMOS
NMOS does not describe the number of audio channels of a receiver. The reason is that NMOS expects most receivers to be flexible in regards to the actual audio channel count being sent; this means the receiver should adapt to the channel count of the connected sender. Since STAGE will set up dedicated senders to be patched on receivers, STAGE needs to know how many audio channels are necessary to be set up. This is why it is important for you to *configure* the number of channels that a given NMOS receiver should have. By default, this is set to 8, but you can set another channel count as needed under **Leg Count**.
Since NMOS does not manage or transfer this information, this can lead to confusion: if you setup a third party device to use a certain channel count for a receiver, STAGE will not know the expected number of channels and will only show the locally configured channel count number configured in STAGE.
## Overview
## Setup Tab
### Settings
Depending on the selected item in the Settings section  , the available parameters on the right-hand section  changes.
#### General Settings
##### Main
| **Name** | Set a friendly name for this host. This host will be identified throughout STAGE by this name. |
| **Description** | Set a meaningful description for this host. |
|-----------------|------------------------------------------------------------------------------------------------|
##### NMOS Node Information
| **Manufacturer** | This section provides read-only information from the NMOS *Node* Object. Fields that may be useful to copy (e.g., the Node ID or Instance ID) are read-only input fields to simplify the copying process. |
| **Product Name** | This section provides read-only information from the NMOS *Node* Object. Fields that may be useful to copy (e.g., the Node ID or Instance ID) are read-only input fields to simplify the copying process. |
| **Function** | This section provides read-only information from the NMOS *Node* Object. Fields that may be useful to copy (e.g., the Node ID or Instance ID) are read-only input fields to simplify the copying process. |
| **Instance ID** | This section provides read-only information from the NMOS *Node* Object. Fields that may be useful to copy (e.g., the Node ID or Instance ID) are read-only input fields to simplify the copying process. |
| **Label** | This section provides read-only information from the NMOS *Node* Object. Fields that may be useful to copy (e.g., the Node ID or Instance ID) are read-only input fields to simplify the copying process. |
| **Description** | This section provides read-only information from the NMOS *Node* Object. Fields that may be useful to copy (e.g., the Node ID or Instance ID) are read-only input fields to simplify the copying process. |
| **Node ID** | This section provides read-only information from the NMOS *Node* Object. Fields that may be useful to copy (e.g., the Node ID or Instance ID) are read-only input fields to simplify the copying process. |
| **Tags** | This section provides read-only information from the NMOS *Node* Object. Fields that may be useful to copy (e.g., the Node ID or Instance ID) are read-only input fields to simplify the copying process. |
|------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
#### Network Interfaces
##### Network Management
| **Network Scope** | Set the type of traffic to exchange on this interface. See also [Network Architecture Requirements](https://manuals.riedel.net/en/stage/2.1/networking-considerations.md) for more information about the different network types used by STAGE. See also chapter [Network Scopes](https://manuals.riedel.net/en/stage/2.1/stage_-network-scopes.md) for more information about how to configure the different network scopes used by STAGE. * unassigned *  Management *  Media Main: For SMPTE ST 2022-7 network redundancy, this the RED network on which SMPTE ST 2110 streams are sent. *  Media Redundant: For SMPTE ST 2022-7 network redundancy, this the BLUE network on which SMPTE ST 2110 streams are sent. * Any other Network Scope that has been added to STAGE. When two network interfaces are set to the same network scope, STAGE assumes that the network is capable of routing packets between those interfaces. That is, if you have one sender on a network scope and a receiver on the same network scope, then the network will pass multicast traffic flows between these hosts. This setting must represent the real world network topography for each host. |
|-------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
##### NMOS Information
| **Chassis ID** | This section provides information about the Chassis ID and Port ID of the selected NMOS interface, as well as the connected variants that reflect the MAC address and ports of the connected switch. |
| **Port ID** | This section provides information about the Chassis ID and Port ID of the selected NMOS interface, as well as the connected variants that reflect the MAC address and ports of the connected switch. |
| **Connected Chassis ID** | This section provides information about the Chassis ID and Port ID of the selected NMOS interface, as well as the connected variants that reflect the MAC address and ports of the connected switch. |
| **Connected Port ID** | This section provides information about the Chassis ID and Port ID of the selected NMOS interface, as well as the connected variants that reflect the MAC address and ports of the connected switch. |
|--------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
## Resources Tab
### Resources
|  | Set a filter to display only content whose search text is found in the name. |
|  | Indicates wheter a sender/receiver is active. |
| **STAGE Resource** | Name of the Resource used in STAGE. |
| **NMOS Resource** | Name of the Resource used in NMOS. |
| **Type** | Displays the items type: Device, Prosumer Group, Audio Producer, Audio Consumer, Number of Legs |
|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------|
### STAGE Device Information
| **Label** | Field to rename the related System Hardware Device. |
| **Type** | The type of the selected resource is a Device. |
|-----------|-----------------------------------------------------|
### NMOS Device Information
| **Manufacturer** | This section provides information about the selected NMOS device. This information is read-only and is for informational purposes only. The user also sets up the preferred control endpoints for this NMOS Device. STAGE automatically selects reachable control endpoints for NMOS Hosts when they are registered, but the user can manually change this endpoint later. A status indicator shows whether the selected endpoint is available or not. |
| **Product** | This section provides information about the selected NMOS device. This information is read-only and is for informational purposes only. The user also sets up the preferred control endpoints for this NMOS Device. STAGE automatically selects reachable control endpoints for NMOS Hosts when they are registered, but the user can manually change this endpoint later. A status indicator shows whether the selected endpoint is available or not. |
| **Function** | This section provides information about the selected NMOS device. This information is read-only and is for informational purposes only. The user also sets up the preferred control endpoints for this NMOS Device. STAGE automatically selects reachable control endpoints for NMOS Hosts when they are registered, but the user can manually change this endpoint later. A status indicator shows whether the selected endpoint is available or not. |
| **Instance Identifier** | This section provides information about the selected NMOS device. This information is read-only and is for informational purposes only. The user also sets up the preferred control endpoints for this NMOS Device. STAGE automatically selects reachable control endpoints for NMOS Hosts when they are registered, but the user can manually change this endpoint later. A status indicator shows whether the selected endpoint is available or not. |
| **Label** | This section provides information about the selected NMOS device. This information is read-only and is for informational purposes only. The user also sets up the preferred control endpoints for this NMOS Device. STAGE automatically selects reachable control endpoints for NMOS Hosts when they are registered, but the user can manually change this endpoint later. A status indicator shows whether the selected endpoint is available or not. |
| **Description** | This section provides information about the selected NMOS device. This information is read-only and is for informational purposes only. The user also sets up the preferred control endpoints for this NMOS Device. STAGE automatically selects reachable control endpoints for NMOS Hosts when they are registered, but the user can manually change this endpoint later. A status indicator shows whether the selected endpoint is available or not. |
| **Type** | This section provides information about the selected NMOS device. This information is read-only and is for informational purposes only. The user also sets up the preferred control endpoints for this NMOS Device. STAGE automatically selects reachable control endpoints for NMOS Hosts when they are registered, but the user can manually change this endpoint later. A status indicator shows whether the selected endpoint is available or not. |
| **Device ID** | This section provides information about the selected NMOS device. This information is read-only and is for informational purposes only. The user also sets up the preferred control endpoints for this NMOS Device. STAGE automatically selects reachable control endpoints for NMOS Hosts when they are registered, but the user can manually change this endpoint later. A status indicator shows whether the selected endpoint is available or not. |
| **IS-05 Connection API Endpoint** | This section provides information about the selected NMOS device. This information is read-only and is for informational purposes only. The user also sets up the preferred control endpoints for this NMOS Device. STAGE automatically selects reachable control endpoints for NMOS Hosts when they are registered, but the user can manually change this endpoint later. A status indicator shows whether the selected endpoint is available or not. |
| **Tags** | This section provides information about the selected NMOS device. This information is read-only and is for informational purposes only. The user also sets up the preferred control endpoints for this NMOS Device. STAGE automatically selects reachable control endpoints for NMOS Hosts when they are registered, but the user can manually change this endpoint later. A status indicator shows whether the selected endpoint is available or not. |
|-----------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
### STAGE Consumer / Sender Information
| **Label** | This section has an input field where the selected Consumer/Sender can be renamed and the type of the selected item (Audio Consumer/Producer) is displayed. |
| **Type** | This section has an input field where the selected Consumer/Sender can be renamed and the type of the selected item (Audio Consumer/Producer) is displayed. |
| **Leg Count** For STAGE Consumer Information configuration table only | Set the number of audio channels (legs) that STAGE allocates for this Audio Consumer. Since NMOS does not communicate the expected channel count of a Receiver, this value must be configured locally in STAGE. The default value is 8 channels but can be adjusted as required. A warning is displayed when the sender currently connected to this receiver contains a different number of audio channels than the configured Leg Count. Changes made to the channel count in third-party NMOS devices are not visible to STAGE and may result in a mismatch between the displayed and actual configuration. See below. |
|-----------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
#### Audio Channel Count (Leg Count) Handling
NMOS does not provide a dedicated parameter that describes how many audio channels an NMOS Receiver is currently configured to. This is because NMOS generally assumes that Receivers are flexible and can adapt to the channel count of a connected Sender on the fly. However, STAGE creates and manages its own audio routing resources and therefore must know how many audio channels to allocate for each Receiver. For this reason, STAGE requires a configured **Leg Count** value for every Audio Consumer (Receiver). The default value is 8 channels, but it can be adjusted to match the Receiver's intended use.
Because this information is not exchanged through NMOS, STAGE cannot detect channel count changes made in third-party management systems. As a result, the Leg Count shown in STAGE may differ from the channel count configured elsewhere. You should ensure that the configured Leg Count in STAGE matches the actual Receiver configuration to avoid unexpected routing behavior.
### STAGE Sender Information
| **Label** | This section has an input field where the selected Consumer/Sender can be renamed and the type of the selected item (Audio Consumer/Producer) is displayed. |
| **Type** | This section has an input field where the selected Consumer/Sender can be renamed and the type of the selected item (Audio Consumer/Producer) is displayed. |
|-----------|-------------------------------------------------------------------------------------------------------------------------------------------------------------|
### NMOS Receiver/Sender Information
| **Receiver/Sender State** | The NMOS Receiver and Connected Sender Information sections show information about the related NMOS *Receiver* and a connected *Sender* if something is connected. This information is read-only and is for informational purposes only. |
| **Label** | The NMOS Receiver and Connected Sender Information sections show information about the related NMOS *Receiver* and a connected *Sender* if something is connected. This information is read-only and is for informational purposes only. |
| **Description** | The NMOS Receiver and Connected Sender Information sections show information about the related NMOS *Receiver* and a connected *Sender* if something is connected. This information is read-only and is for informational purposes only. |
| **Receiver/Sender ID** | The NMOS Receiver and Connected Sender Information sections show information about the related NMOS *Receiver* and a connected *Sender* if something is connected. This information is read-only and is for informational purposes only. |
| **Media Types** | The NMOS Receiver and Connected Sender Information sections show information about the related NMOS *Receiver* and a connected *Sender* if something is connected. This information is read-only and is for informational purposes only. |
| **Tags** | The NMOS Receiver and Connected Sender Information sections show information about the related NMOS *Receiver* and a connected *Sender* if something is connected. This information is read-only and is for informational purposes only. |
| **Interface Bindings** | The NMOS Receiver and Connected Sender Information sections show information about the related NMOS *Receiver* and a connected *Sender* if something is connected. This information is read-only and is for informational purposes only. |
| **Audio Channels** | The NMOS Receiver and Connected Sender Information sections show information about the related NMOS *Receiver* and a connected *Sender* if something is connected. This information is read-only and is for informational purposes only. |
| **Source / Destination** | The Connected Sender information section also offers a download for the related SDP (transport file) of the connected sender (direct link to the according NMOS resource). |
| **Transport File** | The Connected Sender information section also offers a download for the related SDP (transport file) of the connected sender (direct link to the according NMOS resource). |
|---------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
### Related NMOS Flow Information
| **Label** | This section shows information about the related *Flow*. This information is read-only and is for informational purposes only. |
| **Description** | This section shows information about the related *Flow*. This information is read-only and is for informational purposes only. |
| **Flow ID** | This section shows information about the related *Flow*. This information is read-only and is for informational purposes only. |
| **Media Types** | This section shows information about the related *Flow*. This information is read-only and is for informational purposes only. |
| **Tags** | This section shows information about the related *Flow*. This information is read-only and is for informational purposes only. |
| **Sample Rate** | This section shows information about the related *Flow*. This information is read-only and is for informational purposes only. |
|-----------------|--------------------------------------------------------------------------------------------------------------------------------|
---
version: "2.1"
language: "en"
---
# Operation
Operation
Menu
Operation
Home
The Operation consists of the following views:
* [Virtual SmartPanel Browser](https://manuals.riedel.net/en/stage/2.1/virtual-smart-panel-browser-app.md)
This view allows operating a configured Virtual SmartPanel in a browser.
* [Audio Pilot](https://manuals.riedel.net/en/stage/2.1/audio-pilot.md)
This view allows selecting and managing the various DSP configurations to access their control user interfaces across all running Jobs and accessing audio monitoring and selecting the monitoring source when working with SAME Audio Tools within Jobs.
---
version: "2.1"
language: "en"
---
# Preface
This document provides detailed information about STAGE 2.1.
For further information, please refer to the [Riedel Website](http://www.riedel.net/) or contact your local distributor or the Riedel headquarters in Wuppertal.
In this preface, you will find information on the following topics:
* [Revision History](https://manuals.riedel.net/en/stage/2.1/revision-history.md)
* [Compatibility List](https://manuals.riedel.net/en/stage/2.1/compatibility-list.md)
* [Release Notes](https://manuals.riedel.net/en/stage/2.1/release-notes.md)
* [Symbols](https://manuals.riedel.net/en/stage/2.1/symbols.md)
* [Legal Notice](https://manuals.riedel.net/en/stage/2.1/legal-notes.md)
* [Risk Context](https://manuals.riedel.net/en/stage/2.1/risk-context.md)
---
version: "2.1"
language: "en"
---
# Release Notes
The STAGE Release Notes list for any given software release for:
* New Features, Enhancements, and Improvements.
* Bugfixes, Performance, and Stability Improvements.
See also [Known Limitations](https://manuals.riedel.net/en/stage/2.1/release-notes-1.md) and [Compatibility List](https://manuals.riedel.net/en/stage/2.1/compatibility-list.md).
The following STAGE versions are found here:
## STAGE Release 2.1.0
### New Features, Enhancements, and Improvements
* Introduces a baseline northbound control API that can be used by different Riedel products as they are integrated in STAGE.
* Introduces a first version of a boilerplate integration toolkit to help various Riedel development teams to integrate their product in STAGE.
### Bugfixes, Performance, Stability Improvements
CVE-2026-65600: Security vulnerability bug fix for the STAGE Suite file.
STAGE version 2.0.1 and lower of the STAGE server endpoint is vulnerable to an authentication bypass via path traversal in the ReplacePathRegex middleware of Traefik. This release fixes this critical security issue and should be applied without delay.
Filtering for "Unassigned Location" in Event View
A Bug in the User Interface of STAGE prevents the user from filtering for the "Unassigned Location". When the "Unassigned Location" is selected in the filter section, the result in the Event List will not be updated. This release fixes this issue.
Can not use NMOS Senders / Receivers without a redundant interface binding if redundant network scopes are configured on the NMOS Host
When the network interfaces of an NMOS Host in STAGE are assigned to at least two Network Scopes that are marked as Main and Redundant, STAGE will only use senders and receivers on the Host that have redundant network interface bindings. This release fixes this issue.
Syncing large Active Directories
When connecting to large Active Directory instances with 1000+ users, the initial synchronization process might take longer than indicated in the UI. On first synchronization, allow a few minutes for the process to complete. This release fixes this issue.
Re-arranging Locations that are already part of an existing Location may duplicate Locations
In some cases, when editing the Location structure, Locations can get duplicated. This occurs more often when moving locations that are already part of a parent Location to another parent Location. To avoid duplicate Locations, consider creating a new Location in the desired position, move Hosts and Devices to this new Location and then delete the previous Location. This release fixes this issue.
STAGE temporarily consuming a second multicast address from the pool when activating already configured sender
When activating a new sender on Job Activation or Job Configuration changes, STAGE will temporarily consume a new address from the multicast address ranges configured in the assigned network scope of the interface, even if the sender is already configured with a valid multicast address. This can lead to an exhaustion of the multicast address pool if the size of the pool does not provide enough headroom. When using a custom configuration for the multicast address ranges on a network scope, make sure the number of addresses is at least twice the number of active senders across all jobs in STAGE. This release fixes this issue.
Multicast Address Allocations for deregistered Hosts only freed after STAGE reboot
When a Host is unregistered, while still having senders that are using multicast addresses from the configured ranges of the assigned network scopes, these addresses are only released on the next STAGE reboot. This can lead to an exhaustion of the multicast address pool if the ranges are very small and large hosts are registered and unregistered multiple times. When using a custom configuration for the multicast address ranges on a network scope, make sure the number of addresses is sufficient. This release fixes this issue.
*** ** * ** ***
## STAGE Release 2.0.1
### New Features, Enhancements, and Improvements
* N/A
### Bugfixes, Performance, Stability Improvements
* Security vulnerability bug fix for the STAGE Suite file. STAGE version 2.0.0 of the STAGE server endpoint is vulnerable to HTTP Request Smuggling through a header-injection de-synchronization using Expect: 100-continue. An unauthenticated attacker can poison the request queue (RQP) to redirect legitimate user traffic, capture session cookies and authentication tokens from live users' requests, and trigger server-side requests to arbitrary hosts. This release fixes this critical security issue and should be applied without delay.
*** ** * ** ***
## STAGE Release 2.0.0
### New Features, Enhancements, and Improvements
* **Job Management:** Added the ability to define a collection of resources required for a production or live event.
* **NMOS Device Support:** Added discovery of AMWA NMOS devices capable of providing AES67 senders and receivers.
* **SAME Support:** Added support for Riedel SAME DSP Engines within a STAGE system.
* **Virtual Devices:** Added the ability to define and map real-world elements, such as a mono microphone, that are not directly visible to STAGE.
* **Unmanaged Hosts:** Added support for devices that are not managed by STAGE but can provide AES67 streams.
### Bugfixes, Performance, Stability Improvements
* N/A
*** ** * ** ***
## STAGE Release 1.0.3
### New Features, Enhancements, and Improvements
* N/A
### Bugfixes, Performance, Stability Improvements
* Security vulnerability bug fix for the STAGE Suite file. STAGE Versions 1.0.2 and lower of the STAGE server endpoint is vulnerable to HTTP Request Smuggling through a header-injection de-synchronization using Expect: 100-continue. An unauthenticated attacker can poison the request queue (RQP) to redirect legitimate user traffic, capture session cookies and authentication tokens from live users' requests, and trigger server-side requests to arbitrary hosts. This release fixes this critical security issue and should be applied without delay.
*** ** * ** ***
## STAGE Release 1.0.2
### New Features, Enhancements, and Improvements
* N/A
### Bugfixes, Performance, Stability Improvements
* Fixed an issue where STAGE cannot load more than 50 Active Directory users in the user management view
* Fixed an issue that prevents the user from changing the TURN server configuration
* Fixed an issue where custom group filters of the Active Directory are not applied correctly
*** ** * ** ***
## STAGE Release 1.0.1
### New Features, Enhancements, and Improvements
* N/A
### Bugfixes, Performance, Stability Improvements
* N/A
*** ** * ** ***
## STAGE Release 1.0.0
* Initial Release.
---
version: "2.1"
language: "en"
---
# Known Limitations
In the STAGE version 2.1 the following limitations exist:
## **STAGE**
Changes to users managed outside of STAGE can briefly lead to blank Login Page
In some circumstances, a user may be presented with a blank screen instead of a Login page. This can be resolved by refreshing the browser window (pressing F5 or clicking the refresh button). This can happen in cases where a user is logged in via an external Identity Provider and changes are done to the user in the Identity Provider system while the user is logged in. After a manual logout or a session timeout, the user will be navigated back to the login screen, which in some cases can appear empty.
Job multicast allocation fails when multicast range is split up
When configuring two or more STAGE Jobs that have multicast ranges that overlap, the Job might never become fully allocated until the Job is restarted. For example, create a first job with the multicast allocation x.x.0.100 for one device. Now create a second job with a multicast allocation range set as x.x.0.99 to x.x.0.101 for two devices. One of the Jobs will not be fully allocated with devices as expected.
**Workaround:** Restart the Jobs.
Missing user feedback when Stage server is booting
While a STAGE cluster is rebooting, the STAGE Web User Interface may become temporarily unresponsive or display a 414 Request-URI Too Long error; this condition resolves automatically once the cluster startup process is complete, which may take several minutes depending on the hardware.
---
version: "2.1"
language: "en"
---
# STAGE System Requirements
Description of the hardware and software requirements (server and client) as well as considerations regarding the network environment that must be taken into account for the operation of STAGE.
* [Client Computer Requirements](https://manuals.riedel.net/en/stage/2.1/client-computer-specifications.md)
Description of the requirements for the client hardware and software to ensure the functional and smooth operation of STAGE.
* [Server Hardware Requirements](https://manuals.riedel.net/en/stage/2.1/hardware-considerations.md)
Description of the requirements for the hardware on which STAGE is to run.
* [Default Ports](https://manuals.riedel.net/en/stage/2.1/default-ports.md)
List of network ports that STAGE uses by default.
* [Network Architecture Requirements](https://manuals.riedel.net/en/stage/2.1/networking-considerations.md)
Description of the network considerations for the execution of STAGE.
---
version: "2.1"
language: "en"
---
# STAGE Resources
List of software and documentation relevant to the installation of STAGE.
## Related Software
Use the following software to configure and control STAGE equipment. Riedel Communications is only suggesting that you use any of the third-party software listed below; all support for third-party software is provided by the software creator.
Always download and use the latest software to access the latest features and for performance and stability enhancements. Please reach out to Riedel Customer Success Team to have access to various software files.
|-------------------------------|---------------------------------------------------------------------------------------------------------|
| **Software** | **Description** |
| STAGE suite file | File containing all required software packages for STAGE application. |
| SAME DSP Engine | Software to deploy the Riedel Smart Audio Mixer Engine (SAME) on a server. |
| WebRTC Gateway suite file | File containing all required software packages for WebRTC Gateway application. |
| Debian 12 Node file | File containing all required software packages to create a cluster setup on Debian 12 operating system. |
| Riedel Software Manager (RSM) | Software to deploy Riedel software on a server. |
| VSP | Software to deploy the Riedel Virtual SmartPanel on a server. |
## Related Documentation
Use the following documentation to configure and use STAGE, and to make better use of its features.
Always use the latest documentation, which is available on the Riedel Communications website as online help ([https://manuals.riedel.net](https://manuals.riedel.net/)) or as a pdf download ().
|--------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------|
| **Documentation** | **Description** | **Format** |
| RSM User Manual | Software to deploy Riedel software on a server. | * [Online Help](https://manuals.riedel.net/rsm?contextKey=RSM&version=latest&language=en) * [PDF](https://my.riedel.net/) |
| STAGE User Manual | Processing infrastructure that supports product applications such as SAME, Virtual SmartPanel app, Artist-1024, WebRTC Server, as well as third-party authentication system and third-party monitoring solutions. | * [Online Help](https://manuals.riedel.net/stage?contextKey=STAGE&version=latest&language=en) * [PDF](https://my.riedel.net/) |
| Northbound gRPC and REST API Documentation | An OpenAPI specification for the REST API. | [STAGE Northbound API \| About the API Toolkit](https://manuals.riedel.net/en/stage/2.1/stage-northbound-api.md#About-the-API-Toolkit) |
| SAME User Manual | Software for a low latency audio processing platform based on COTS servers for audio mixer DSP applications. | * [Online Help](https://manuals.riedel.net/same?contextKey=SAME&version=latest&language=default) |
| Virtual SmartPanel User Guide | Software to virtualize the core capabilities of the 1200 Series SmartPanel within a secure, COTS server‑based environment. It empowers flexible, user-centric remote production workflows across LAN and WAN infrastructures. | * [Online Help](https://manuals.riedel.net/vsp?contextKey=VSP&version=latest&language=default) |
| Director User Manual | Software to configure and setup the environment of Artist-1024 devices. | * [PDF](https://my.riedel.net/) |
| Artist-1024 User manual | Provides detailed information about the Artist-1024 system, pin outs, mechanical andelectrical data. | * [PDF](https://my.riedel.net/) |
| Datasheets | Technical specifications about the product. | * [PDF](https://my.riedel.net/) |
---
version: "2.1"
language: "en"
---
# Revision History
Overview of the released STAGE versions.
| **Release** | **Date (D/M/Y)** | **Remark** | **Date of Documentation** |
|-------------|------------------|------------------------------------------------------------------------------------------|---------------------------|
| STAGE 2.1.0 | 01.09.2026 | Support for the new features; see [Release Notes](https://manuals.riedel.net/en/stage/2.1/release-notes.md). | 03.09.2026 |
| STAGE 2.0.1 | 03.06.2026 | Bug fix release | - |
| STAGE 2.0.0 | 03.02.2026 | SAME 1.0 (Jobs, Virtual Devices, NMOS Hosts, Unmanaged Hosts, Audio Pilot, SAME Support) | 13.02.2026 |
| STAGE 1.0.3 | 03.06.2026 | Bug fix release | - |
| STAGE 1.0.2 | 15.12.2025 | Bug fix release | - |
| STAGE 1.0.1 | 02.12.2025 | Bug fix release | - |
| STAGE 1.0.0 | 03.11.2025 | Corrections to documentation | - |
| STAGE 1.0.0 | 24.06.2025 | Initial release | 30.06.2025 |
---
version: "2.1"
language: "en"
---
# Risk Context
## Intended Purpose
* Provide a common user interface to configure, operate and monitor Riedel Products.
* Provide centralized capabilities (i.e. user management, license management, telemetry, northbound APIs) on behalf of Riedel Products.
* Act as a middleware to enable integration of Riedel Products with 3rd party systems.
* Provide a shared environment where multiple people use STAGE at the same time to perform various operational tasks related to managed Riedel products.
### Operational Environment
STAGE is expected to operate:
* Indoors within controlled professional environments.
* On managed wired Ethernet networks.
* Within secured corporate, production, or broadcast infrastructures.
* In installations where physical access is limited to authorized personnel.
### Intended Target Users
* System Administrators
* Technical Administrators
* Audio/Video Engineers
* Audio/Video Operators
### Usage Scenarios
STAGE is designed as a multi-user environment and therefore supports multiple simultaneous users with various access levels and permissions.
### Expected Duration of Use
STAGE is designed for continuous long-term operation and is expected to remain operational throughout the supported product lifecycle, including software maintenance and security updates.
## Reasonably Foreseeable Use
Reasonably foreseeable use includes:
* **Centralized Management of Distributed Riedel Systems**: customers may use STAGE to discover, register, configure, and monitor Riedel products deployed across multiple facilities, venues, studios, or production sites.
* **Remote Administration and Operations** customers may provide remote access to STAGE for administrators, operators, engineers, system integrators, and support teams (ex. through VPN, corporate network).
* **Integration with multiple vendors:** customers may use STAGE as the integration point between Riedel products and 3rd party broadcast control systems, monitoring systems, identity providers (e.g. okta) and/or enterprise user database (e.g. Active Directory).
* **Automation and Orchestration**: customers may use northbound APIs to automate provisioning of Riedel products.
* **Collection and export of telemetry data**: customers use STAGE as a centralized repository for operational logs and telemetry that are exported to enterprise monitoring platforms (ex. Grafana, Splunk).
* **Remote Administration and Operations** customers may provide remote access to STAGE for administrators, operators, engineers, system integrators, and support teams (ex. through VPN, corporate network).
## Foreseeable Misuse
The manufacturer reasonably foresees that some users may use the STAGE contrary to the provided instructions or stated limitations, including:
* **Deployment on untrusted network:**Deploying STAGE on an untrusted network without adequate network security controls.
* **Use of Shared User Accounts:**Multiple individuals utilize the same user account, reducing accountability and traceability of actions.
* **Assignment of Excessive Permissions:**Users are granted permissions beyond those required to perform their responsibilities.
* **Overly Broad Access to Monitoring Data:**Administrators granting monitoring information access to a broader set of external systems than intended.
* **Use of Shared API Credentials**: Multiple external systems using the same northbound API client account, making it difficult to attribute actions to a specific system or integration.
**Important:** Such use falls outside the intended purpose of the product and may lead to increased cybersecurity risks.
## **Reporting a Security Vulnerability**
Riedel Communications is committed to the security of its products. If you believe you have identified a security vulnerability in this product, please report it to us at [**https://my.riedel.net/vulnerability**](https://my.riedel.net/vulnerability). There you'll find guidance on how to submit a report, what details to include so we can investigate promptly, and what to expect from us once a report is received. We ask that you report suspected vulnerabilities in good faith and allow us a reasonable opportunity to assess and address the issue before any public disclosure.
The same page lists known and publicly disclosed vulnerabilities affecting Riedel products, along with available guidance, workarounds, and security updates. We recommend checking this page periodically and subscribing to any available notifications to stay informed of security issues relevant to your equipment.
---
version: "2.1"
language: "en"
---
# SAME Application Configuration
To configure the SAME DSP Engine, see [SAME Application Configuration](https://manuals.riedel.net/same?contextKey=same_-same-application-configuration&version=latest&language=default).
---
version: "2.1"
language: "en"
---
# SAME DSP Engine Configuration
To configure the SAME DSP Engine, see [SAME DSP Engine Configuration](https://manuals.riedel.net/same?contextKey=same_-same-dsp-engine-configuration&version=latest&language=default) and [SAME DSP Engine Volume Activation Tab](https://manuals.riedel.net/same?contextKey=same_-same-dsp-engine-volume-activation-tab&version=latest&language=default).
---
version: "2.1"
language: "en"
---
# SAME Installation
This chapter describes the installation of a SAME.
To install SAME, see [SAME Installation](https://manuals.riedel.net/same?contextKey=same_-same-installation&version=latest&language=default).
For more information about software installation, see RSM [Riedel Software Manager](https://manuals.riedel.net/rsm?contextKey=RSM&version=latest&language=default).
---
version: "2.1"
language: "en"
---
# STAGE Installation
This chapter describes the installation of STAGE using the [Riedel Software Manager](https://manuals.riedel.net/rsm?contextKey=RSM&version=latest&language=en).
For users of the Adobe Acrobat (PDF) version of this user guide, see the **Riedel Software Manager User Guide** . See [STAGE Resources](https://manuals.riedel.net/en/stage/2.1/resources.md).
## RSM - Configurations View
1. In the **Configurations** section, click **Create**.
2. Enter a name for the Server Configuration, for example, `My STAGE Config`.
3. In the **Suites** section, click on **Manage Suites...** .
4. In the **Manage Suites** dialog, click **Import Suite** , then find the `*.suite` file on your local computer and upload it to the Riedel Software Manager, e.g. 'stage-1.0.0.suite'.
5. When the upload is completed, click **Close** to return to the Suite Configuration.
6. Click the new Suite to select it and to see available packages that will appear on the right side. Packages with a  yellow icon are required in this suite and have to be configured and enabled to create a valid Server Configuration. Click the package to select it and to view its settings on the right, e.g. 'Riedel STAGE 1.0.0'.
7. Enter required package settings.
1. Set the credentials that are to be used when the administrator logs into the STAGE Web Interface for the first time.
2. Set the HTTPS port to be used to connect to the user interface, which can be accessed through a web browser (e.g. Google Chrome or Microsoft Edge). Default: 443
3. Set if third party access should be enabled with credentials and the Port to be used (default: 8089).
8. Click **Save and Enable** .
## RSM - Clusters View
1. In the **Clusters** section, click **Create...**.
A wizard will appear which guides through the creation:
### Type tab
1. Enter a name (without spaces) for the Cluster Setup, for example, `My-STAGE-Cluster`.
2. Choose whether you want to use
1. no high availability (single node)
2. high availability (3 nodes)
3. Click **Next**.
### Connectivity tab
1. Select whether you want to address your nodes via domain names (resolved by DNS) or via IP addresses.
2. Click **Next**.
### Nodes tab
1. If required, you can edit the Node Names by clicking on them.
2. Depending on the selection in the previous Connectivity tab, enter the name(s) or IP address(es) of the node(s).
For FQDN mode, either use static addresses in the background or ensure that the addresses are reserved in a DHCP server.
3. Enter the SSH credentials of the node(s).
After entering the information, the connection is verified and RSM will check if the corresponding node file has been provides before. Information about that is displayed in the status column.
4. If  appears, click the  upload icon and follow the wizard for importing the `*.node` file from your computer that corresponds to the operating system on your server, e.g. `ues-node-1.0.0-debian-12-bookworm_amd64.node`.
5. If all SSH connections are established and the corresponding node files are  available, click **Next**.
### FQDN tab
1. If necessary, edit the domain / IP address of the cluster.
2. Click **Next**.
### Summary tab
1. Review the provided information. Click on **Back** to switch to the corresponding tab to correct it.
2. Click **Create Cluster** to start preparing the servers or virtual machines according the Cluster setup.
### Creation tab
1. Riedel Software Manager is now creating the Cluster Setup and adding the specified servers or virtual machines to it. During this process it will install the required packages on the servers to form the Cluster Setup.
2. Once all nodes show the "Online" Status, the process is finished. Click **Next** to proceed.
### Certificate tab
1. Click **Export Management Certificate**to download it. This certificate is the "key" to connect to this Cluster with Riedel Software Manager at a later time or from another computer.
2. After confirming the download of the certificate by ticking the checkbox, click **Next**.
3. During the installation, a self-signed certificate was generated. This certificate may trigger security warnings in browsers or other applications when connecting to the cluster. To avoid these warnings, you can export the certificate and add it to your browser's trusted certificates, or you can import a certificate provided by your organization for the cluster to use.
Click **Close** to exit the wizard.
## Installing a Server Configuration on a Cluster Setup
1. Select a Server Configuration on the left and a Cluster Setup in the middle and click **Install Configuration on selected Cluster** at the bottom left.
2. The license agreement of the Application you are installing is shown.
Accept the terms by ticking the checkbox. Click **Install** to start the installation.
4. Riedel Software Manager is now installing the selected Configuration on the selected Cluster. This process can take a few minutes depending on the speed of your network connection.
5. Once the installation has been finished, the servers are started.
6. After all services are started, you can proceed to open the web interface of the application or close the wizard.
This completes the installation of STAGE.
After the installation is finished you can proceed to open the web interface of the application or close the wizard.
---
version: "2.1"
language: "en"
---
# STAGE Northbound API
## Introduction
### Purpose of the API
The STAGE Northbound API enables remote control of Applications hosted by a STAGE system. It is designed to allow external systems such as broadcast controllers, automation systems, or custom software solutions to interact programmatically with STAGE.
Typical use cases include:
* Controlling Application behavior from external control systems
* Changing Parameters of Applications running in STAGE
* Accessing Meter data, particularly for audio‑related Applications
The API can be used both for:
* Dedicated integrations into larger control or automation systems
* Small‑scoped, project‑based or ad‑hoc integrations, where only a limited subset of functionality is required
### Intended Audience
This documentation is intended for:
* Software developers working on broadcast or media control systems
* System integrators creating custom integrations involving STAGE
* Technical teams building project‑specific or customer‑specific control solutions
Readers are expected to be familiar with general software development concepts and have basic knowledge of APIs, networking, and authentication.
### API Technology
The API is available through two different technologies, each targeting different integration needs: gRPC and REST.
If no strong constraint exists, gRPC should be considered the default integration choice.
#### gRPC API
The gRPC interface is the primary and recommended way to integrate with STAGE.
Key characteristics:
* Provides the full API functionality
* Supports real‑time streaming updates, including:
* Parameter changes
* High‑frequency data such as audio Meters
* High performance and low latency
* Well suited for long‑running connections and complex integrations
This interface is the preferred choice for:
* Full‑scale, generic integrations into other software systems
* Control Applications that require flexible access to all STAGE Parameters
* Integrations that rely on real‑time updates or continuous data streams
#### REST API
In addition to gRPC, the API is also exposed as an HTTP‑based REST interface.
Key characteristics:
* Uses standard HTTP request/response patterns
* Lower performance compared to gRPC
* Does not support streaming updates
* High‑frequency data (such as audio Meters) is not available
* Parameter Value changes must be polled manually
This interface is intended for:
* Quick, ad‑hoc integrations
* More static or configuration‑oriented use cases
* Scenarios where real‑time updates are not required
### Other APIs provided in STAGE
STAGE provides other APIs alongside the one described here. These APIs complement the Northbound API and are typically used together in larger integrations. Further information on these APIs is available in the documentation.
| **APIs** | **See** |
|------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| An AMWA NMOS IS-04, IS-05 Node to control senders and receivers exposed by STAGE. | SAME [Putting a SAME DSP Engine Under Northbound Control](https://manuals.riedel.net/same?contextKey=same_-putting-same-under-northbound-control&version=latest&language=default). For users of the Adobe Acrobat (PDF) version of this user guide, see *Putting a SAME DSP Engine Under Northbound Control* in the **SAME User Guide** . See [STAGE Resources](https://manuals.riedel.net/en/stage/2.1/resources.md). |
| An AMWA NMOS IS-08 API to control patching of senders and receivers to Applications (for Hosts in Direct Control Mode only). | SAME [Putting a SAME DSP Engine Under Northbound Control](https://manuals.riedel.net/same?contextKey=same_-putting-same-under-northbound-control&version=latest&language=default). For users of the Adobe Acrobat (PDF) version of this user guide, see *Putting a SAME DSP Engine Under Northbound Control* in the **SAME User Guide** . See [STAGE Resources](https://manuals.riedel.net/en/stage/2.1/resources.md). |
| A Grafana Loki API to pull Logs collected by STAGE into other systems. | [Monitoring STAGE with Third Party Applications](https://manuals.riedel.net/en/stage/2.1/3rd-party.md) |
| A Prometheus Northbound API to pull Metrics collected by STAGE into other systems. | [Monitoring STAGE with Third Party Applications](https://manuals.riedel.net/en/stage/2.1/3rd-party.md) |
### Available Assets
To support development and integration, Riedel provides an API Development Toolkit. This toolkit contains all assets required to get started with the API.
The toolkit includes:
* Protobuf definitions for the gRPC API
* An OpenAPI specification for the REST API
* A sample Application written in Go, demonstrating authentication and basic API usage. Documentation explaining this sample Application is also provided.
These assets are intended to serve as both reference material and practical examples for implementing integrations with STAGE. To download this package, see [STAGE Northbound API \| STAGE Northbound API Changelog](https://manuals.riedel.net/en/stage/2.1/stage-northbound-api.md#STAGE-Northbound-API-Changelog).
## Quick Start
This section describes a quick way to get started with using the API in STAGE.
* Login to STAGE with a user with System Admin permission
* In System Management / Northbound APIs, enable the API and create an API client. Note the `Client Id`, `Client Token` and `Access Token URL`
See [STAGE Northbound API \| STAGE configuration](https://manuals.riedel.net/en/stage/2.1/stage-northbound-api.md#STAGE-configuration) below.
### REST
* navigate your browser to `>:/docs/swagger#` (the default port is 8444)
* click "Authorize" and provide the `Client Id` and `Client Token`
* select a command from the documentation and run it (e.g. `GET /hosts`)
Note that the access token expires after 60 seconds, since refreshing the token automatically is not supported in this documentation renderer, you will need to re-authorize again periodically
### gRPC
To get started with the gRPC API, run the `stage-api-go-client` available in API Integration Toolkit. Provide the `Client Id` and `Access Token` when prompted and follow the menu of the client to interact with the API.
## Configuration steps
### Deployment
By default, the port used for the API is **8444** . When installing STAGE using Riedel Software Manager, the port used for the API can be configured in the package configuration of STAGE. See also [STAGE Installation](https://manuals.riedel.net/en/stage/2.1/stage-installation.md).
To set the Northbound API port number to be used, see RSM [STAGE Suite Package Settings](https://manuals.riedel.net/rsm?contextKey=rsm_-configurations&version=latest&language=default#STAGE-Suite-Package-Settings).
The base URL for the API is `
The API uses the same HTTPS/SSL certificate as the rest of the Deployment. By default this is a self-signed certificate. The STAGE Administrator can replace this certificate with a trusted one using Riedel Software Manager.
### STAGE configuration
The Northbound API is disabled by default. To start using the API:
1. Log in to STAGE with a user with *System Administrator* permission.
2. Navigate to "System Management", select "Northbound APIs" from the menu.
3. Enable the "Northbound gRPC / REST APIs".
4. Create a new API client by clicking the plus icon.
5. Provide a friendly name and a Client ID for this connection and click Create:
6. Once the Northbound API Client is created, a window will appear:
Note the
* **Client ID**
* **Client Secret**
* **Token Endpoint URL**.
You will need this information in a later step to authenticate to the API.
See also [System Configuration](https://manuals.riedel.net/en/stage/2.1/discovery.md).
## Authentication \& Authorization
All API endpoints are protected and require authentication. Access is granted using OAuth 2.0 / OpenID Connect, with STAGE acting as the authorization authority.
The only currently supported authentication mechanism is:
**OAuth 2.0 Client Credentials Grant with Refresh Tokens**
This mechanism is intended for machine‑to‑machine integrations and does not require interactive user login.
Additional authentication mechanisms may be introduced in later releases.
### Overview
Each third‑party integration is represented as an **API client** in STAGE.
The client authenticates using its own credentials and receives cryptographically signed tokens that authorize access to the API.
The authentication work flow involves three parts:
* **Client** -- your Application integrating with the API
* **Authorization Server** -- STAGE's OpenID Connect provider (Keycloak)
* **Resource Server** -- the API (REST and gRPC)
A valid **access token** is required before calling any API endpoint.
### Client Credentials
To access the API, you will receive the following information from a STAGE administrator:
* **Client ID**
* **Client Secret**
* **Token Endpoint URL**
See also [STAGE Northbound API \| STAGE configuration](https://manuals.riedel.net/en/stage/2.1/stage-northbound-api.md#STAGE-configuration).
The Token endpoint URL follows this scheme:
https://:/service/auth/realms/UE/protocol/openid-connect/token
Client registration and permission management are handled by STAGE administrators. Dynamic self‑registration is not supported.
### Obtaining an Access Token
To obtain an access token, your client must send a request to the token endpoint using HTTP Basic authentication.
#### Access Token Request
POST https:///service/auth/realms/UE/protocol/openid-connect/token
Authorization: Basic
Content-Type: Application/x-www-form-urlencoded
grant_type=client_credentials
#### Access Token Response (Example)
{
"access_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
"refresh_token": "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...",
"expires_in": 300,
"refresh_expires_in": 1800,
"token_type": "Bearer",
...
}
### Using the Access Token
All endpoints require a valid access token.
#### REST API
Include the access token in the Authorization header:
GET https:///v1/system/info
Authorization: Bearer
#### gRPC API
Send the token as gRPC request metadata:
authorization: Bearer
### Refreshing Access Tokens
Access tokens are intentionally short‑lived and will expire after 60 seconds. When an access token expires, use the refresh token to obtain a new one.
POST https:///service/auth/realms/UE/protocol/openid-connect/token
Content-Type: Application/x-www-form-urlencoded
grant_type=refresh_token
client_id=
refresh_token=
A new access token (and possibly a new refresh token) is returned.
Clients are responsible for:
* Tracking token expiration
* Refreshing tokens proactively
* Retrying failed requests caused by token expiry
### Token Revocation
STAGE administrators can revoke access at any time by revoking active client sessions or deleting the configured API client in STAGE.
Once revoked, API calls using affected tokens will immediately fail with authorization errors.
Clients should handle authentication failures gracefully and re‑authenticate when required.
## Core Domain Concepts
The STAGE 3rd‑Party API exposes a small set of core domain models that represent the operational structure of a STAGE system. These models are designed to be stable, discoverable, and consistent regardless of whether functionality is accessed through gRPC or REST.
At a high level, Hosts run Applications, Applications are structured using Control Nodes, and expose Parameters, Meters, Presets, and Snapshots. Parameters use ValueModels to describe valid data and constraints.
### General
#### Names and Labels
Some objects will expose name properties, some other will expose label properties. A name property is exposed, when the name is defined by the system and cannot be changed by the user. Names are stable. A label is a user-defined value and can change at any time.
### Hosts
A Host represents a physical or virtual system registered in STAGE that provides computing and processing capabilities. Hosts are the starting point for discovering Applications through the API.
Each Host operates in exactly one of the following modes:
#### Direct Control Mode
In Direct Control Mode, a host exposes all of its configured Applications directly to third‑party systems through the STAGE Northbound API.
Characteristics:
* Applications running on the host are exposed to the API directly
* Resources are not managed as part of STAGE Jobs
* Intended for direct external control and monitoring when advanced workflows in STAGE are not required
Direct Control Mode is typically used when a host is dedicated to specific tasks, used in a static fashion and controlled entirely from an external system.
In this version of the API only Applications running on Hosts in Direct Control Mode are available. Thus the API will also only expose Hosts in Direct Control Mode.
### Applications
An Application represents a functional processing unit running on a host in Direct Control Mode . Examples include SAME Mixers, Network Plugins, Signal Generators and Analyzers, or other signal‑processing components.
Key characteristics:
* Applications have stable identifiers
* Applications are always addressed through a consistent API structure
* The same Application Model applies regardless of where the Application is hosted
* Each Application defines its own Parameters, Meters, Presets, and Snapshots
* An Application provides a URL and a recommended viewport size to the operational UI of the Application
Applications are the primary entities that third‑party systems interact with.
### Control Nodes
Applications expose their internal structure through Control Nodes.
A Control Node represents a logical grouping within an Application, such as:
* A channel strip
* A processing block
* A functional section of the Application
Characteristics:
* Control nodes form a hierarchical tree
* Each Control Node may contain child Control Nodes
* Control nodes group related Parameters and Meters
This structure allows clients to navigate complex Applications in a predictable and structured way.
### Parameters
Parameters represent controllable or readable values exposed by an Application.
Examples include:
* Gain values
* Mute or enable switches
* Frequency or timing settings
* Mode selectors
Key properties:
* Each Parameter belongs to exactly one Application
* Parameters have stable identifiers
* Parameters relate to a ValueModel that describes the meaning and constraints of a Parameter Value
* A Parameter can have a single value or a tuple value. Tuple values are used to describe a set of values that needs to be applied at the same time.
Parameters are organized under Control Nodes for readability and structure.
### ValueModels
Each Parameter is described by a ValueModel, which defines the structure and constraints of its value.
The following ValueModels are defined:
* `NumericModel`: defines a numeric Parameter. The ValueModel defines a minimum and maximum value, a unit as string and a default value
* `BoolModel`: defines a boolean Parameter. The ValueModel defines a default value only.
* `LookupModel`: defines a Parameter where its value can be picked from a list of predefined values. The ValueModel defines a list of entries, where each entry is defined by a value (a numeric value that the Parameter will display for the entry) and a name (which is a human-readable name for the entry). It will also define a default value.
* `TextModel`: defines a Parameter where its value is a text. Additional constrains can be defined for the text, such as minimum and maximum amount of characters, not being blank, not including spaces, numbers or special characters. For complex cases a regex can be specified. It will also define a default value.
ValueModels enable generic clients to interpret and validate Parameters without Application‑specific logic.
### Meters
Meters provide runtime measurement and monitoring data from Applications, most commonly for audio processing.
Examples include:
* Audio level Meters
* Signal activity indicators
* Other continuously updated metrics
Characteristics:
* Meters are read‑only
* Meter Values may update at high frequency (up to 10 times per second)
* Meters are available only through streaming using the gRPC API
* Meters are always associated to a Control Node and an Application
* Meter Values are transported in an array. In case multiple Meter Values are available for a signal (e.g. for a stereo or 5.1 audio signal), the Meter object will transport an array of values for each individual Meter channel. In case of a single Meter Value, the array will have a length of 1
Meters are designed for monitoring and diagnostics rather than control.
### Presets
A Preset represents a predefined set of Parameter Values for a specific part of an Application.
Key characteristics:
* Presets are always associated with a Control Node
* Applying a Preset sets multiple Parameters simultaneously
* Presets provide a convenient way to recall known or approved configurations
* Presets are Application‑defined and Application‑specific
* Presets can only be created from the STAGE UI, not from the API itself
Presets are used to switch all Parameters of a Control Node into a predefined state without individually setting each Parameter.
### Snapshots
A Snapshot represents a captured state of an Application at a given point in time.
Key characteristics:
* Snapshots capture the values of Parameters across a broader scope
* Snapshots can typically be recalled to restore a previous state
* Snapshots are associated with Applications, not with individual Control Nodes
* Snapshot availability and behavior are Application‑dependent
Snapshots are commonly used for operational workflows, such as saving and recalling complete Application states during production.
### Relationship Overview
The core domain models relate as follows:
* A Host runs one or more Applications
* An Application exposes a hierarchy of Control Nodes and may expose Snapshots
* Control Nodes group Parameters, Meters, and Presets
* Parameters use ValueModels to define valid data and behavior
* Presets apply predefined Parameter Value sets
* Snapshots capture and recall Application states
* Meters provide real‑time measurement data
This domain model ensures that control, monitoring, and state management remain consistent, extensible, and independent of the Application Type used on the STAGE platform.
## Working with the API
This section describes typical interaction patterns when integrating with the API. While the API supports both gRPC and REST, the overall workflow remains the same, with differences mainly in how data is retrieved and updated.
### Typical Workflows
#### Fetching Applications
After authenticating, a client begins by discovering available hosts. Using gRPC, the client typically subscribes to the host list to receive updates; with REST, the host list is fetched on demand.
For each host, the client retrieves or subscribes to the list of Applications running on that host.
Then the client fetches an individual Application. This returns the full Application structure, including the Control Node hierarchy, Parameter definitions including their ValueModels and references to Meters. This provides a complete view of an Application's Parameters and Meters.
#### Opening Operational UI of an Application
All Applications expose a dedicated operational UI.
The client reads the Application's `ApplicationOperationalUI` property, which include a URL and a recommended viewport size, and opens it in a browser or embedded window. The user is required to log in to STAGE and is then presented with the operational UI scoped to that specific Application.
#### Controlling Parameters
Clients interact with Application Parameters and Meters using their identifiers. A Parameter is identified by both the id of the Application and the id of the Parameter. Parameters of Applications of the same Application Type will have the same Parameter Id across different instances of the Application. Control Nodes include the definition of Parameters and Meters, but not their values.
With gRPC, clients can subscribe to Parameter and Meter Values to receive the initial value and real‑time updates. With REST, Parameter Values can be polled, but Meter data is not available.
To change a Parameter, the client sends a new value for the a Application id and Parameter id. A successful response indicates acceptance of the request, while the resulting Parameter Value is propagated through subscriptions or subsequent fetches. Changes made through the API and changes made through the STAGE UI are reflected consistently in both directions.
#### Using Snapshots and Presets
The API supports two complementary mechanisms for restoring predefined Application states: Snapshots and Presets. While both are used to apply multiple Parameter changes at once, they differ in scope, structure, and intended usage.
Snapshots represent a global, Application‑wide state. They capture the values of multiple Parameters across the entire Application at a specific point in time. Snapshots are not part of the Control Node hierarchy and are not included when fetching an Application or its Control Nodes. Instead, dedicated endpoints are provided to retrieve the list of Snapshots available for an Application and to recall a specific Snapshot. Recalling a Snapshot restores the Application to the captured state, potentially affecting Parameters across many Control Nodes simultaneously.
Presets, on the other hand, are scoped more narrowly. A Preset is always associated with a specific Control Node and represents a predefined set of Parameter Values relevant to that node only. Similar to Snapshots, Presets are not embedded directly in the Control Node structure returned by the Application fetch. Clients use separate endpoints to list Presets available for a Control Node and to recall a selected Preset. Recalling a Preset applies Parameter changes only within the scope of the associated Control Node.
### Rate Limiting
To protect system stability and prevent misuse, the API enforces rate limits on incoming requests for both gRPC and REST access.
Rate limiting is applied at the API ingress layer and monitors the frequency of requests per client over a defined time window. The rate limit is set to 200 requests per second with a burst capacity (buffer /queue depth) of 2. See for more information about how this *rate* and *burst*throttling / bandwidth limiting mechanism works.
If a client exceeds the allowed request rate, further requests are temporarily rejected.
When a rate limit is exceeded:
* The API responds with HTTP status code 429 (Too Many Requests) for REST clients.
* For gRPC clients, the request is rejected with the corresponding resource‑exhausted error.
* An Event is generated inside STAGE and can be reviewed in the Event Viewer, allowing engineers to identify and diagnose excessive API usage.
Clients are expected to handle rate‑limit responses gracefully by slowing down request rates, applying backoff strategies, or, where available, relying on subscriptions and streaming updates instead of frequent polling.
### High Availability
The API is designed to operate in a high‑availability (HA) environment. API access is provided by a clustered STAGE deployment, allowing requests to be handled by multiple nodes within the system.
In normal operation, clients interact with the API through a stable endpoint without needing to be aware of individual cluster nodes. Requests may be served by any active node in the cluster.
In the event of a failure or restart of a cluster node, API communication may be briefly interrupted. Existing connections, particularly long‑lived connections such as gRPC streams, may be closed and need to be re‑established by the client. After failover, the API remains available and continues to operate as normal. The failover is expected to complete in less than 10 seconds.
Clients are expected to:
* Tolerate short‑lived interruptions
* Reconnect subscriptions or streams if a connection is lost
* Resume normal operation without manual intervention
The API does not guarantee seamless session continuation across node failures, but it is designed to recover quickly and consistently, ensuring robust operation in clustered and redundant deployments.
## STAGE Northbound API Changelog
| **Version** | **Changes** | **Date** | **Released with STAGE Version** | **API Toolkit Download** |
|-------------|-----------------|----------|---------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------|
| v1 | Initial Release | 08/2026 | STAGE 2.1 | [thirdparty-api-toolkit-1.0.0-15.zip](https://manuals.riedel.net/__attachments/a_7ff01f6cc1a598686b88b392aec908a8a99dbf846a1cb2fc93ade3358490bcc1/thirdparty-api-toolkit-1.0.0-15.zip.md) |
### About the API Toolkit v1
Download and unzip the API Toolkit.
| **Zip File / Directory** | **Description** |
|--------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| `openapi` | An OpenAPI v3 compatible \*.yaml file describing the HTTP / JSON API. |
| `parameters` | Contains a zip file with `SAME_Application_Control_Documentation.html` in it. Open this file in your browser to see a list of all parameters and their definition for all APP types available in this STAGE release. These parameters are both available on the OpenAPI REST API and the gRPC API.  Typical Parameter and Meter Documentation for the SAME DSP Application |
| `proto` | A set of \*.proto files describing the gRPC API. |
| `stage-api-go-client` | A sample application written in Go, demonstrating authentication and basic API usage. This has a zip file in the `doc` folder that contains documentation for the sample Go application. |
| `README.md` | A brief overview of the API Toolkit zip file contents. |
For more information about the API Toolkit, see [STAGE Northbound API \| Available Assets](https://manuals.riedel.net/en/stage/2.1/stage-northbound-api.md#Available-Assets).
## Support
For further support please reach out to Riedel Customer Success through
---
version: "2.1"
language: "en"
---
# STAGE Quick Start Guide
This is a quick start guide to help you to get STAGE up and running with the software application you need to run.
STAGE is a platform on which the following Riedel software applications run.
* SAME DSP Engine: Riedel Smart Audio Mixer Engine
* Virtual SmartPanel: Riedel Virtual SmartPanel
It provides a common infrastructure and operating environment for these software applications. Quick Start Guides are available for the following STAGE applications:
* SAME DSP Engine: See SAME [Quick Start Guide](https://manuals.riedel.net/same?contextKey=same_-same-dsp-engine-quick-start-guide&version=latest&language=default).
* Virtual SmartPanel: See VSP [Quick Start Guide](https://manuals.riedel.net/vsp?contextKey=vsp_-virtual-smartpanel-quick-start-guide&version=latest&language=default).
[Next Page](https://manuals.riedel.net/llms-full.txt/1)