Version

This page describes the Riedel RRCS implementation in vsmGadgetServer.NET 5.6. The current protocol version 1.1.0.0 supports Riedel RRCS 8.0 D22.

Features

The implementation offers following features:

  • Key Assignment via a 1:N Matrix on Layer 0.
  • Routing via a N:N Matrix on Layer 1. Can be used via two 1:N Adapters on Layer 2(Summing mode) and Layer 3(Exclusive mode).
  • IFB Assignment via a 1:N Matrix on Layer 4.
  • Virtual Functions of Artist Ports via a 1:N Matrix on Layer 5.
  • Virtual Keys of Artist Ports via a 1:N Matrix on Layer 6.
  • Input Gain Control.
  • Output Gain Control.
  • Single/Conference Crosspoint Volume Control.
  • Bidirectional change of Label/Alias.
  • Remote key feature.
  • Expansion ports.
  • Logic Sources.
  • Group Membership Assignment.
  • Trunkend Ports/IFBs.
  • Pool Ports only as VirtualFunction targets
  • Sip Phone
  • Optional Properties for KeyAssignment
  • RRCS Redundancy

Configuration

Routing

The routing matrix supports audio routing on the riedel system. Routing matrices on Layer 2,3 and 4 can handle up to 1024 Riedel audio crosspoints. The calculation of the corresponding target/source is: 128 * nodeAddress + portAddress.

Mapping

vsmGadgetServer 5.4 introducing a new mapping file for targets and sources which will be used for key assignment matrix. New discovered Ifbs, Conferences, Groups and Panels will be automatically added as sources and each Panel as targets to the mapping file. The user can download/edit and upload the generated file. For download press the arrow down button and the export button to save the file on your machine.

Now each source and target can be moved within the matrix by modifying the <index> value of each element, which is added to the <offset> value if present. The <meta> tag is just an additional information of a Riedel element and should not be modified by the user.

<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<mapping>
<identifier>Riedel System</identifier>
<children>
<indexMappingRegion>
<name>IFBOffset</name>
<offset>0</offset>
<usage>Source</usage>
<children>
<indexMapping>
<identifier>1992061502</identifier>
<index>0</index>
<meta>
<metaMapping>
<name>Ifb</name>
<description>Interrupted Fold Back 00001</description>
<type>String</type>
</metaMapping>
</meta>
</indexMapping>
<indexMapping>
<identifier>1835544362</identifier>
<index>1</index>
<meta>
<metaMapping>
<name>Ifb</name>
<description>Interrupted Fold Back 00005</description>
<type>String</type>
</metaMapping>
</meta>
</indexMapping>
</indexMappingRegion>
<indexMappingRegion>
<name>ConferenceOffset</name>
<offset>1000</offset>
<usage>Source</usage>
<children>
<indexMapping>
<identifier>329713904</identifier>
<index>1</index>
<meta>
<metaMapping>
<name>Conference</name>
<description>Conference #002</description>
<type>String</type>
</metaMapping>
</meta>
</indexMapping>
<indexMapping>
<identifier>1819424962</identifier>
<index>0</index>
<meta>
<metaMapping>
<name>Conference</name>
<description>Conference #001</description>
<type>String</type>
</metaMapping>
</meta>
</indexMapping>
</children>
</indexMappingRegion>
<indexMappingRegion>
<name>GroupOffset</name>
<offset>1500</offset>
<usage>Source</usage>
<children>
<indexMapping>
<identifier>417337575</identifier>
<index>5</index>
<meta>
<metaMapping>
<name>Group</name>
<description>Group #006</description>
<type>String</type>
</metaMapping>
</meta>
</indexMapping>
<indexMapping>
<identifier>497031789</identifier>
<index>0</index>
<meta>
<metaMapping>
<name>Group</name>
<description>Group #001</description>
<type>String</type>
</metaMapping>
</meta>
</indexMapping>
<indexMapping>
<identifier>671026474</identifier>
<index>8</index>
<meta>
<metaMapping>
<name>Group</name>
<description>Group #009</description>
<type>String</type>
</metaMapping>
</meta>
</indexMapping>
<indexMapping>
<identifier>1069907700</identifier>
<index>1</index>
<meta>
<metaMapping>
<name>Group</name>
<description>Group #002</description>
<type>String</type>
</metaMapping>
</meta>
</indexMapping>
</children>
</indexMappingRegion>
<indexMappingRegion>
<name>LocalPortOffset</name>
<offset>2000</offset>
<usage>Source</usage>
<children>
<indexMapping>
<identifier>1020795049</identifier>
<index>0</index>
<meta>
<metaMapping>
<name>ArtistPort</name>
<description>PORT 1.1 - Node #1</description>
<type>String</type>
</metaMapping>
</meta>
</indexMapping>
<indexMapping>
<identifier>501366847</identifier>
<index>1</index>
<meta>
<metaMapping>
<name>ArtistPort</name>
<description>PORT 1.2 - Node #1</description>
<type>String</type>
</metaMapping>
</meta>
</indexMapping>
</children>
</indexMappingRegion>
<indexMappingRegion>
<name>1020795049</name>
<offset>0</offset>
<usage>Target</usage>
<capacity>24</capacity>
<meta>
<metaMapping>
<name>ArtistPort</name>
<description>PORT 1.1 - Node #1</description>
<type>String</type>
</metaMapping>
</meta>
</indexMappingRegion>
<indexMappingRegion>
<name>501366847</name>
<offset>25</offset>
<usage>Target</usage>
<capacity>32</capacity>
<meta>
<metaMapping>
<name>ArtistPort</name>
<description>PORT 1.2 - Node #1</description>
<type>String</type>
</metaMapping>
</meta>
</indexMappingRegion>
<indexMappingRegion>
<name>1871974489</name>
<offset>33</offset>
<usage>Target</usage>
<capacity>32</capacity>
<meta>
<metaMapping>
<name>ExpansionPort</name>
<description>PORT 1.2 - Node #1 Exp.[1]</description>
<type>String</type>
</metaMapping>
</meta>
</indexMappingRegion>
</children>
</mapping>

If a whole element group (e.g Ifb, Conference ...) must be moved within the matrix, use the global <offset> tag of the corresponding <indexMappingRegion>.

  <indexMappingRegion>
      <name>IFBOffset</name>
      <offset>0</offset>
      <usage>Source</usage>
      <children>
        <indexMapping>
          <identifier>1992061502</identifier>
          <index>0</index>
          <meta>
            <metaMapping>
              <name>Ifb</name>
              <description>Interrupted Fold Back 00001</description>
              <type>String</type>
            </metaMapping>
      ...
  </indexMappingRegion> 

Move all Ifbs to start at source 500:

  <indexMappingRegion>
      <name>IFBOffset</name>
      <offset>500</offset>
      <usage>Source</usage>
      <children>
        <indexMapping>
          <identifier>1992061502</identifier>
          <index>0</index>
          <meta>
            <metaMapping>
              <name>Ifb</name>
              <description>Interrupted Fold Back 00001</description>
              <type>String</type>
            </metaMapping>
         ...
  </indexMappingRegion> 

After upload to the vsmGadgetServer the Ifb "Interrupted Fold Back 00001" will be located at source 500. To upload your the file press the arrow up button and select your modified Riedel.Mapping.xml file. Do not rename the file.

Event Listener

vsmGadgetServer needs two Tcp connections to the RRCS proxy. The main connection sends changes from VSM to the Riedel world. The EventListener connection receives any changes happend remotely, thus VSM has to tell the RRCS proxy the listener endpoint. Please enter a valid and open port and the IP Address of the vsmGadgetServer machine.

Transfer Delay

TransferDelay defines the how long vsmGadgetServer will buffer any changes before sending it to RRCS proxy.

IFB Assignment Matrix

This matrix generates 3 targets for each configured IFB(Max. 500). The targets Input, MixMinus and Output can be assigned with a source(Group or Panel). The sources will be mapped as defined in mapping source sections

    <indexMappingRegion>
          <name>GroupOffset</name>
          <offset>1500</offset>
          <usage>Source</usage>
          <children>
            ....
            ....
          <\children>
    </indexMappingRegion>

and

    <indexMappingRegion>
          <name>LocalPortOffset</name>
          <offset>2000</offset>
          <usage>Source</usage>
          <children>
            ....
            ....
          <\children>
    </indexMappingRegion>

Virtual Functions

The virtual function matrix supports up to 3 Artistport functions: Always, Vox and On call. The source offsets are the same as on the KeyAssignment Matrix(Layer 1). The targets reperesent the different functions and are also mapped from the global LocalPortOffset mapping region(<index>*3). Since not all Artistports support all function, there may be some unused targets on the matrix. Currently known Artistport with custom function count is the splitted 4-Wire port. This type will generate a "2-Wire In" and a "2-Wire Out" port."2-Wire In" only supports Always/Vox and "2-Wire Out" only supports Always/On Call functions. All virtual functions will support the Call-to-Port/-Group/-IFB/-Conference exept the "2-Wire Out". This Artistport type only supports Call-to-Conference and Listen-to-Port. Please consider this limitation when assigning a virtual function on a "2-Wire Out" port.

Group Member Assignment

Since driver version 1.0.4.5 all Artistports are listed under a seperate Node "Ports" with inforamative parameters about the port type, alias and number of expansionports. Each port node have 2 child nodes "Groups" and "Conferences", each lists all known groups and conferences. Under Groups the user now can assign the corresponding Artisport as a group member via parameter "IsMember". The conference "IsMember" is a readonly parameter, because this can be only done via the KeyAssignment matrix.

Virtual Keys

The virtual keys matrix supports the configured virtual keys of any Artistport. vsmGadgetServer doesn't add or delete virtual keys. Due some protocol limitiations, all keys need to be configured before the start of the vsmGadgetServer. Sources are the same as on the KeyAssignment matrix. Targets are mapped into a new section named: VirtualKeysOffset. The offset must be at least the offset+capacity of the last target on the KeyAssignment matrix.

<indexMappingRegion>
      <name>VirtualKeyOffset</name>
      <offset>16384</offset>
      <usage>Target</usage>
      <children>
        <indexMapping>
          <identifier>775846364</identifier>
          <index>0</index>
    </indexMapping>
    ...
    ...
      </children>
    </indexMappingRegion>

Sip Phone

"Line is busy" and "Line is free" status is retrieved by "PortActive" and "PortInactive" events. "Waiting for Connection" can only be retrieved on general "ConfigurationChange" event.

Optional Properties for KeyAssignment

Version 1.0.23.0 introduces a new node Key Properties on root level. Within this node the user can specify optional properties to make PanelKey, VirtualKey and VirtualFunction assignments. All values are always intialized with default values. A default value won't be sent to RRCS.

Currently only Group properties are supported and can be extended on request.

Group Properties

  • UseSecondChannel
  • ShowIncomingMarker
  • DisableDestinVolumeAdjust
  • AudioPriority

RRCS Redundancy

Driver version 1.1.0.0 introduces the support of RRCS redundancy.

Requirements:

  • All RRCS intances need to enable "Gateway starts standby" option.
  • The driver needs to know about all redundant RRCS instances through the address list.

Flow:

  1. The driver conencts to the first endpoint of the address list.
  2. The driver checks if the RRCS is running in standby and activates this RRCS instance if it is connected to a frame.
  3. If this RRCS instance loses the connection to the frame, the driver first activates the standby mode again and then disconnects itself.
  4. The driver connects to the next endpoint from the address list and starts with 2.

===== vsmGadgetServer 5.2 Implementation =====

This page describes the Riedel RRCS implementation in vsmGadgetServer.NET 5.2. The first release offers the following features:

  • Key Assignment via a 1:N matrix
  • Input Gain Control
  • Output Gain Control
  • Crosspoint Volume Control

Configuration

Since a Riedel system may contain up to 1024 panels with thousands of buttons in total, we currently need to limit the panels and their keys that shall be editable via the control system. The key assignment matrix is a 1:N matrix, where the targets represent the assignable keys and the sources represent the talk destination, like other panels, IFBs, conferences and groups.

Target Mapping

To map a panel on a range of targets, it must be added to the "Editable Panels" list via the web interface by entering its node and port number (example: Node = 2, Port = 1). All panels in the list will be mapped to the targets. Each panel is assigned to a fixed number of targets, where each target represents one key. The number of targets per panel is configured via an option called "Targets Per Panel". The default value is 99. That means, that the first panel is mapped to targets 1 to 99, the second panel to targets 100 to 199 and so on. That way, it is possible to configure the targets in advance.

Source Mapping

The following objects can be mapped to the sources:

  • Ports (panels, beltbacks, ...)
  • IFBs
  • Conferences
  • Groups

Ports

Each port is assigned to a node which has a number in the range of 2 to 255. If mapped linearly, this number may lead to a huge matrix which is difficult to handle. To reduce the number of crosspoints, each node that is required must be mapped by specifying an offset. That way, only the ports required are located on the matrix, which keeps the size at a minimum. Node 2 might for example be mapped to source 2000, which means that the panel with address Node = 2, Port = 100 is mapped to source 2000 + 100 = 2100.

IFBs

IFBs have a number starting at 1, where each number must only occur once. So there is only the need to specify an offset for the IFBs in general, for example 0. That means, the IFB with number 1 would be located at source one. The option to specify the offset is called "IFB offset".

Conferences & Groups

For both types an offset must be specified ("Group offset" and "Conference offset"). However, it is not possible to know where a conference will be located without having the Riedel configuration, since they have an object identifier that is created by the system itself. To simplify the mapping a bit, the conferences and groups will be mapped by ordering these object identifiers. So as long as the configuration does not remove conferences or groups, the mapping will remain the same.

Summary

The following options are required in order to configure the key assignment matrix:

  • Targets Per Panel : integer
  • Editable Panels : string list
  • Nodes : string list
  • IFB offset : integer
  • Conference offset : integer
  • Group offset : integer

Examples

We have a system consisting of two nodes, 2 and 3. Furthermore, we have four panels (Node 2, Port 1; Node 2, Port 2; Node 3, Port 1; Node 3, Port 2), some IFBs, Conferences and Groups.

All four panels shall be editable. So the "Editable Panels" list would look the following:

  • Node = 2, Port = 1
  • Node = 2, Port = 2
  • Node = 3, Port = 1
  • Node = 3, Port = 2

This results in the following mapping, assuming "Targets Per Panels" is set to 99:

  • Node = 2, Port = 1 is mapped to 1 - 99
  • Node = 2, Port = 2 is mapped to 100 - 198
  • Node = 3, Port = 1 is mapped to 199 - 297
  • Node = 3, Port = 2 is mapped to 298 - 396

Now, we want to map the nodes to the sources, where ports of node 2 should start at source 2000 and ports of node 3 start at 3000. To do so, we edit the "Nodes" list:

  • Node = 2, Offset = 2000
  • Node = 3, Offset = 3000

That means, that the panel with the address (Node = 2, Port = 2) will be mapped to source 2002.

Since IFBs have number in a range from 1 to N, we map them to source 1 - N by settings the "IFB offset" to 0. This results in mapping IFB 1 to source 1, since the formula is offset + IFB number (0 + 1).

Finally, we have to map groups and conferences. This is similar to mapping the IFBs, just specify the offsets, for example:

  • Group offset: 100
  • Conference offset: 200