Patent Application
20240089165
This relates to systems, methods, and devices for networked media distribution. More particularly, this relates to systems, methods and devices for large scale networked media (e.g., audio, video, etc.) distribution.
Media signals, such as audio and video signals have historically been difficult to share across a network because media signals prefer networks with both low latency and accurate time alignment. Existing techniques for sharing media signals have been limited to small groups of devices. These techniques are generally unmanaged (e.g., plug-and-play) to simplify the setup for the user. While a plug-and-play system has some advantages, it compromises many features that could otherwise be available because the complex logic is not built into the simple end devices.
While it is possible to make the end devices more complex, this is not generally desired because it may increase latency, the complexity and/or the cost of the end devices. Accordingly, it may be desirable to have systems, methods and devices, capable of large scale networked media distribution that do not suffer from one or more of these drawbacks.
Some embodiments described herein may provide for a method, device or system for providing automated configuration of multi-subnet synchronization systems as described herein.
Some embodiments described herein may provide for a method, device or system for providing active management of a large scale media system as described herein.
Some embodiments described herein may provide for a method, device or system for providing fault tolerant operation of a large scale media system wherein a central management server may not be present. (e.g., devices sensibly caching and operating with known good parameters etc.) as described herein.
Some embodiments described herein, may provide for a domain manager configured to manage and/or configure an audio-video (AV) system but not directly participate in networked media transmission or clock synchronization. The domain manager may include a database; an endpoint manager configured to communicate with the database, the endpoint manager being configured to setup and maintain secure connections to and from media devices and controllers; and at least one management module configured to communicate with the database and provide services to the media devices and controllers. In embodiments, the at least one management module may include at least one of a domain manager for managing credentials and grouping devices into domains, a device directory for managing device registrations and lookup, and an access controller for managing and/or evaluating access control policy.
Aspects of the present disclosure are best understood from the following detailed description when read with the accompanying figures.
The following disclosure provides many different embodiments, or examples, for implementing different features of the provided subject matter. Specific examples of components and arrangements are described below to simplify the present disclosure. These are, of course, merely examples and are not intended to be limiting.
Media signals, such as audio and video signals have historically been difficult to share across a network because media signals prefer networks with both low latency and accurate time alignment. Existing techniques for sharing media signals have been limited to small groups of devices (e.g., subnets). These techniques are generally unmanaged (e.g., plug-and-play) to simplify the setup for the user. For example, in some systems, once a device is plugged in, the device may be automatically recognized and configured. While a plug-and-play system has some advantages, it compromises many features that could otherwise be available because the complex logic is not built into the simple end devices. As a result, many of the features that may otherwise be available (e.g., access control), may not be implemented in the network.
While it is possible to make the end devices more complex, this is not generally desired because it may increase latency, the complexity and/or cost of the end devices. As described herein, a domain manager may be capable of managing a collection of end devices to create an administrative group called a domain. The end devices selected for a particular domain may not be limited to a particular subnet but may instead come from a more expansive wide area network (WAN). this administrative grouping by the domain manager may enable more complex features to be implemented within the network. Additionally, since the domain manager is a part of the control and setup process but not part of the communication process, latency remains minimal and the time alignment remains accurate.
In some embodiments, the domain manager described herein may be implemented in software, hardware, and/or a combination of hardware and/or software. Additionally, the domain manager may be part of a local computer (e.g., laptop or rack mounted computer), it may be installed on a virtual machine, or it may reside as hardware/software in the cloud.
In some embodiments the domain manager may provide one or more beneficial features to the network. Examples of some of the features of the domain manager and operation and architecture of the domain manager are discussed below.
In some embodiments, the domain manager (DM or DDM) may be a hardware and/or software entity that enables effective communication within large scale networked media systems. Media systems (e.g., Dante) may benefit from low latency from a signal input to a signal output and/or accurate time alignment between the media signals. To support low latency, the network may be configured to support media signals with high rates of small packets. To support accurate time alignment, networked media systems may benefit from hardware timestamping of clock synchronization packets to improve synchronization accuracy.
The domain manager may be configured to manage and configure an audio-video (AV) system but may not directly participate in networked media transmission or clock synchronization. In some embodiments, this may be an advantage because it allows the domain manager to be virtualized and/or provided as a service delivered by cloud technology. In other words, in some embodiments, the domain manager may not be constrained by specialized hardware requirements or stringent performance requirements.
In some embodiments, the domain manager may enable one or more of the following features:
Each of these features are discussed in more detail below.
In some embodiments, when connecting local clock masters in different network subnets into a single clock tree, it may be more efficient to use unicast communication rather than multicast communication. However, using unicast may have several disadvantages that the domain manager described herein may be configured to overcome.
In some embodiments, using unicast may require that the local clock masters are configured with the IP addresses of its peers. This can be cumbersome and error prone if performed manually. In some embodiments, the domain manager may facilitate error-free manual configuration and further provide automated configuration by one or more of the following means:
In some embodiments, it may be desirable that subnets include more than one master clock. This could be performed by the domain manager administrator or automatically by selecting multiple of the best candidates in each subnet.
In some embodiments, the subnet local clocks may need to communicate with its peers in other subnets to exchange unicast clocking messages. If multiple candidate unicast masters are present in a subnet, it may be desirable that any candidates not currently considered a master remain passive until the currently active master becomes unavailable. This configuration may decrease both the total unicast traffic between subnets and the load on the grandmaster that needs to send clock synchronization messages to unicast capable devices in other subnets. If all candidate masters are always active the total number of subnets that can be supported in the media network is reduced.
In some embodiments, it may be desirable for the media flows (and clocking) to be maintained even if the domain manager is temporarily unavailable. Accordingly, in some embodiments, it may be possible for the system to detect and switch to another unicast-capable master (from the previously selected candidates) even if the domain manager is not present.
Routable transport protocols may allow media signals to be transmitted and received across IP subnets. However setting up of these media streams may require a media device to be able to discover device addresses and channel information of another media device that may be connected to a different subnet in order to be able to setup a media stream to/from it; and a controller to be able to discover media devices that may be on different subnets in order to configure media flows and other parameters on these devices.
Domain Name System-Service Discovery (DNS-SD) may be used for this purpose, however DNS-SD is limited in its ability to handle rich metadata and to provide prompt notification when media devices are connected and disconnected from the network. In some embodiments, the domain manager may incorporate a device metadata database and associated processes that may be reactive to changes in device metadata. If this is the case, the domain manager may include one or more of the following advantages:
In a large media network it may be important to secure control communications against tampering by encrypting the communication paths between devices, control endpoints and the domain manager. In some embodiments, to achieve this, the domain manager may need to solve one or more of the following two problems—bootstrapping and key distribution.
In connection with bootstrapping, media devices and/or controllers may need to discover the domain manager even if the domain manager is in a different subnet. This could be performed be manually configuring each endpoint with the IP address of the domain manager but this would become unmanageable in large systems. In some embodiments, it may be possible to automatically bootstrap devices by using a service such as a DHCP server to distribute additional configuration information to each endpoint at the same time they acquire an IP address. In other embodiments the devices may discover the DDM via DNS-SD, which may use multicast (mDNS) if the domain manager is operating in a single subnet network or a DNS service record configured in DNS server in the case the domain manager is operating in a network with multiple subnets. In the latter case the DHCP server may be used to distribute the address of the DNS server to the devices. With respect to key distribution, media devices may require encryption keys so that secure communication channels can be established. In some embodiments, the domain manager may be used to enable simple secure key generation and distribution to devices; support cryptographic authentication of devices (e.g., enabling the revocation of keys, for example when removing a device from a domain); build chains of trust where devices are grouped into domains; and/or offload computationally intensive cryptographic operations from resource constrained devices.
In some embodiments, a traditional media network (e.g., a Dante network) may have distributed control and monitoring functionality. For example, a large scale media network with many devices and/or subnets may suffer from an increase in the complexity of the network and the need for better management tools. In some embodiments, the domain manager may facilitate network management by centralizing information and/or control of devices in a networked media system. As a result, one or more features may be enabled by the domain manager.
In some embodiments, the domain manager may be implemented in software and may be configured to manage clocking configuration and media configuration. However, the domain manager may not directly participate in either. As such, the domain manager may not have specific hardware requirements such as access to precision timestamping making the domain manager a candidate for virtualization.
In a large scale media network there may be many active controllers and many users who have access to the network. In such an environment it may be desirable to ensure that the media network is secured against un-authorized access and configuration changes. In some embodiments, the domain manager may provide one or more of the following functions to manage access to a media system:
Where configuration change is permitted by policy, the domain manager may also maintain an audit log of configuration changes. Unlike any logging maintained by the main controller (e.g., a Dante Controller), the domain manager logs may not be lost when the domain manager is restarted and can be managed appropriately by an administrator.
In some embodiments, the audit logs may provide one or more of the following functions:
In some embodiments, media devices may be capable of generating statistics and performance information which can be used to analyze and/or troubleshoot errors in a media network. Control and monitoring applications may display this information with appropriate visualizations such as histograms, warning indicators etc. A large media network may have many controllers active. In a smaller network, devices may multicast such information so that they can be received by the multiple controllers, but this does not scale to large scale media systems. In some embodiments, the domain manager may improve the collection and display of such information in one or more of the following ways:
In some embodiments, it may be desirable to sub-divide large media systems into smaller, logically separate sub-systems consisting of groups of devices called domains. In some embodiments, a single domain manager can manage multiple domains. Domains may support administrative grouping and/or clocking isolation. In administrative grouping, users may be assigned different roles in different domains. These roles may constrain their capability to configure and monitor these domains. With respect to clocking isolation, it may be desirable to maintain independent groups of devices on the same physical network without the need to configure VLANs in a manner that each domain has its own master clock and that changes to clocking in one domain do not interfere with another
As illustrated in
As illustrated in
The ability to sub-divide a large media system into separate administrative domains may be important in an environment with a diverse group of users. However, there is a use case for users in one domain to have access to only certain devices (or specific audio channels on a device) in the other domain without allowing them full access to that domain. For example, two rooms in a conference center are usually maintained as two separate spaces and managed by different users. However, in some instances the second conference room may be configured as an overflow room for the main room. In this case a user with access only to the second room may need to configure outputs in the second room to receive from certain inputs in the first room; without having configuration privileges in the first room. In order to achieve this, a user in the first domain (room) may “project” certain devices or specific channels on a device to be visible in one or more other domains. This may be achieved by the device directory module exposing some devices or channels in one domain to controllers/devices in the second domain as “virtual devices” which may only expose specific channels of the underlying device. A user accessing a controller attached to the second domain will see these “virtual devices” and be able to exchange audio between this virtual device and physical devices in the domain. Thus, a user in one domain can access to certain devices/channels in another domain without requiring total visibility/access to that domain.
An example configuration is illustrated in
In some embodiments, the functionality provided by the domain manager may require that firmware on media devices are updated to become domain-aware. It may be desirable to account for transition scenarios, in which devices are upgraded gradually. Accordingly, in some embodiments, the domain manager may be able to handle both legacy and domain-aware devices. For example, it may be possible to send and receive media from selected media devices/channels that are not domain-aware and are thus operating outside a domain. It may also be possible for the network administrator to configure access policies to enable such functionality only when required as this may alter the security model the system. In some embodiments, it may also be possible to configure clocking on non domain-aware devices such that they share a common clock with devices within a domain.
In some embodiments it is possible that domain unaware devices are 3r d party devices that can interoperate with Dante devices using protocols such as AES67/SMPTE2110.
In some embodiments, when devices are grouped into domains, each domain may have an independent clock and thus it may not be possible to setup isochronous media flows between devices in different domains. A tie line (see,
In some embodiments, it may be desirable to connect a number of media signals between independent domains. In this case, a component may be required that can re-time media signals between the two clock domains. This component may reside within the domain manager or may be an entity controlled by the domain manager (e.g., a software instance based on Dante Via that is controlled by the domain manager).
In some embodiments, the domains may be connected via a low bandwidth network connection. In that case the intervening device may also use media compression technologies.
The domain manager may also be able to manage configuration and connection of streams passed through a media re-timer within domains it is managing.
With reference to
In some embodiments, the receiving device r1 may be a device that is not managed by a domain manager. In the case where the destination domain (i.e. domain 2 in
The domain manager may also make an interface available that allows the operator to manually configure connection details such as the destination IP address and port, audio codec, compression parameters, etc.
In some embodiments, the domain manager may provide an interface for the system operator to select media channels that may be grouped into a single logical tie line connection.
In some embodiments, if a media flow has many receivers it may be more efficient to use multicast instead of unicast. Multicast may be enabled across subnets by enabling multicast routing capability in the routers connecting the subnets. However, in some embodiments, a coordinated centralized approach to multicast address allocation may be required as a distributed protocol may not work across subnets. The domain manager can be used to perform multicast address allocation.
In some embodiments, there may be some receivers in the same subnet as the sender and other receivers on different subnets. In such a case it may be desirable to translate the multicast flow to unicast so it can be sent to the remote subnet. In addition it may be desirable to convert the unicast flow back into multicast in the remote subnet. In some embodiments, these operations may be controlled by the domain manager.
In some embodiments, the domain manager may be used as a centralized store for media network presets, allowing users to store desired configurations for part or all of a media network. The domain manager may manage the process of applying the required configuration to devices and handling errors that arise during the application of presets, as well as providing access control and audit logging for preset configurations. The domain manager may enable discovery and management of presets via user interfaces. In some embodiments, preset discovery and invocation may be triggered remotely—e.g. via a mobile phone or buttons on a wall panel. As illustrated in
In some embodiments, a large media network may consist of products (e.g., devices) from multiple manufactures and ensuring that these devices are running the latest firmware may be desirable. This may be a large management task for the network administrator. In some embodiments, the domain manager may be configured to perform one or more of the following functions:
In a network of single manufacture devices (e.g., Dante devices) a controller such as the Dante Controller can be used to configure and monitor media flows. However some products have additional product specific configuration, for e.g. gain controls. In this case users may have to either use two (2) controllers or the product manufacturer may have to use Dante APIs to build an integrated controller that combines both Dante and custom control. For such a case it is advantageous for the domain manager to be a platform that can be used by a manufacturer to add a vendor specific “plugin” to existing control functionality provided via the domain manager.
Certain media devices may have the ability to encrypt media streams. However the communicating devices may need to be configured with session based encryption keys. In some embodiments, the domain manager may be used to generate and manage session keys for media flows.
In some embodiments, the network devices may be able to operate with different flow configurations based on their capabilities or other system requirements. These flow configurations are typically static, or managed on a ‘whole of device’ basis, where the transmit flow configuration is adjusted for all flows. Flow configuration refers to the number of audio channels contained in the flow description, the number of samples contained within each packet, and the audio format used within the flow. In some embodiments, the domain manager may configure endpoints to use flow configurations that are adapted or otherwise optimized for the use case at hand. This can be performed on a per-flow basis within the operating domain. An example is a flow configuration that has been optimized to suit a network backbone that provides rate-limited bandwidth to the system. In this case optimizing both the number of channels and the sample format can reduce bandwidth without the need to otherwise compress or modify the audio content. This also has the advantage of supporting low latency operation within a single domain.
The ability to connect multiple subnets into a single media network means that the practical limit of the number of devices that can be supported in a single local area network (LAN) may be overcome. In other words, it may be possible to build very large media networks containing 1000s of devices. As discussed herein, the presence of the domain manager allows for implementation of new functionality not possible in a fully distributed network. However it also introduces a single point of failure in the media network. Therefore it is important that the media network incorporates both scalability and fault tolerant features.
In a media network containing a domain manager configuration and monitoring information may be forwarded via the domain manager. However it is possible that the domain manager may be temporarily unavailable—e.g., due to a hardware failure or network partition. In some embodiments, it may be desirable for the media system to be fault tolerant in these circumstances and that media flows be maintained. In some embodiments, this can be facilitated by having the media devices cache sufficient configuration information to continue functioning when the domain manager is not present. In some embodiments, media devices may support maintaining media flows and clocking even if the domain manager is not present and/or being powered cycled and resuming media flows and clocking even if the domain manager is not present.
As the domain manager may be a critical part of the media network it may be desirable for the domain manager itself to be fault tolerant. Such fault tolerance can be achieved by combining multiple domain managers that share/replicate their state. As the domain manager state may be stored in a database, traditional database replication schemes can be used for this purpose. In addition, fault tolerance can be achieved by using virtual addresses for the domain manager and protocols such as Common Address Redundancy Protocol (CARP) to maintain multiple domain manager servers with failover.
In some embodiments, the domain manager may be a set of services that is within the media network. However as the media network can be made tolerant to temporary disconnection it is possible to deliver domain manager services to media systems over the Internet using “cloud technologies” commonly used to deliver Internet services. In this case, the domain manager may include one or more of the following features:
The presence of a domain manager in an media network may enable supporting additional functionality which is not be incorporated into the end devices themselves. This capability of the domain manager provides scalability and the ability to continually enhance a system as new capabilities are required.
In some embodiments, the media network may include highly constrained devices in a scalable system. In particular, a large media system may have very large numbers of input and output endpoint devices. These often only support a small number of media channels. It is possible to reduce the implementation cost of an endpoint by removing the need for the endpoint to provide native implementations of all control functions on an ongoing basis. Offloading control functionality from the endpoint to the domain manager can reduce computing resource requirements such as RAM, storage, and CPU cycles within the endpoint.
Some examples include:
In some embodiments, the media network may include translation to other heavyweight protocols. In particular, there may be multiple protocols and standards used to control and monitor media networks. Examples include AES70, ACN, OSC, and AIMS/NMOS IS-04. Some of these are confined to particular application domains, while others are more broadly applicable. Generally, these protocols are confined to the control plane, and do not natively include media transport, instead relying on a media transport suite provided by the devices (such as Dante). Another feature of this class of protocols is that new versions, extensions, and implementations are constantly released.
The cost associated with supporting each of these protocols in all endpoints is prohibitive in terms of implementation complexity and in device resource cost. In some embodiments, the domain manager may be used to provide a translation gateway between 3rd party protocols and the native control protocols of the media device. The domain manager may provide an API that presents both a system model and an individual device model. This may be used to implement a gateway function to the 3rd party control protocol.
This may have one or more advantages over a native implementation within the device, including one or more of the following:
In some embodiments, the domain manager may be a software application running on a computer that is used to manage a network of media devices. The domain manager may be a set of services that operate in the control plane of the network. Protocols that have real-time requirements such as media flows or clocking protocols may not send messages via the domain manager. Thus the domain manager can be easily virtualized or implemented as a “cloud” service.
The access controller is responsible for access control policy management and evaluation. Messages that pass through the DDM and are access controlled by the DDM may be processed by this block. This block may also manage access control policies for subsequent cache and evaluation on the device itself. If the DDM maintains an audit trail of actions within a domain, it may be embedded within an access control manager or by using an audit log. This may include messages that are sent via the DDM and/or messages that are processed within a device, with a notification sent to the DDM.
Different pathways may exist for media controllers to communicate with the DDM. Controllers may communicate via a web server connected to the database. In this case, the controller may acquire domain and device state from the database via the web server. The database may also act as a pathway for sending device or DDM configuration from the controller to the DDM. The various DDM modules may respond to changes in the configuration areas of the database and apply the changes. Where the changes are to device configuration, a module connected to the endpoint manager may translate and/or forward the configuration instructions to the device. It may also verify that the configuration was correctly applied, and may then update the device's state within the database.
Controllers may also communicate with the DDM via the endpoint manager, network protocols to obtain device, and/or DDM state from DDM. The DDM may forward query messages from controllers to devices, with the devices sending responses back to the controller via the DDM or directly. Alternatively, the DDM may know the information being requested and can provide the device state to controllers on behalf of the devices. Controllers may also use this pathway to send configuration messages for devices. The DDM may apply access control to the configuration messages and then forward acceptable messages to the devices. It could also forward any response from the device back to the controller. Alternatively, the DDM may maintain a desired configuration for devices. In this case the DDM may process the message and update its desired configuration and send a response to the controller. It is free to apply the new configuration to the device either before or after sending a response to the controller.
The DDM may also allow passing of network messages between a controller to a device without parsing or processing the entire message. This feature allows for third-party controllers or controller plugins to push device-specific or manufacturer-specific messages between a controller and a device without the DDM having to interpret or understand the entire message. Controllers attached to web server may push the message into the database, with a module attached to the device endpoint forwarding the message to the device. Messages from a device can also be pushed into the database by the module and then obtained by the controller. Controllers attached to the endpoint may send a message to the device in the same way as for other configuration messages. The DDM may also support third-party access-control plugins to allow access control rules to be applied to these third-party messages.
The controller interface may be implemented as a software library implementing an application programming interface (API). A third party may use this library to implement a customized controller that can communicate with a DDM and media devices in a domain. Such an application programming interface could also provide methods to perform various DDM administrative functions such as managing users, viewing audit logs, etc.
A media network containing a domain manager may span multiple subnets. A domain manager in one subnet may be able to manage devices in other subnets. As illustrated in
In a small network it may be possible to provide each device and/or controller with the address of the domain manager via manual configuration. This can done via a controller or the domain manager itself. In a large network this may be impractical, in such a network a service such a DHCP may be used to provide additional configuration information. This may be implemented as follows in a network that contains a DHCP and DNS server. The DNS server may be configured with a SRV record specifying the device connection endpoint on the domain manager and the controller connection endpoint of the domain manager. Alternatively this could be an A record of the domain manager. In this case the devices and controllers assume a well-known port for the endpoint. The DHCP response may include the address of the DNS server and the search domain for the device. The device or controller performs a DNS query for the SRV record or A record of the domain manager in the search domain. Thus the device/controller has acquired the address of the domain manager and is able to initiate communication.
In some embodiments, the domain manager may use public key infrastructure (PKI) to cryptographically authenticate entities within the media network as well as to setup secure encrypted connections. This may require each entity to be assigned private/public keys and a certificate embedding the public key signed by the entity above it in the hierarchy. This process is illustrated in
In this way a chain of trust is created and a particular device or other entity can be authenticated as being cryptographically associated with a particular Domain and domain manager.
If devices that belong to different domain managers or different domains are required to communicate, these devices can be authenticated by the exchange of certificates at the domain manager or domain level.
In
In some embodiments, devices and/or controllers may need to be assigned public/private key pairs so that individual entities can be authenticated. This may require a bootstrapping step where the keys need to be securely installed on the device. This can be done by using an encrypted connection setup with a common device key. After the per device keys are installed the connection can be re-established using per device keys.
In some embodiments, connections from media controllers may be authenticated via credentials of the user associated with it. In such a case the connection may be encrypted by using a technology such as SSL.
In some embodiments, the device directory module manages the discovery of device information by other devices and controllers. The sequence of interaction is illustrated in
In the description above the device registering its information and the device and/or controller querying this information may be on different subnets.
In the description above devices and controllers may be connected via TCP or UDP connections and the domain manager updates a “long lived” query by sending update messages to the relevant devices and controllers. In an alternative implementation controllers may be web applications and the information in the controller may be updated by real time notifications of changes to the database. An example of such an implementation could be a meteor web application using the domain manager protocol to update the web client information (REF).
In some embodiments, domains (e.g., Dante domains) may span multiple IP subnets. Devices within a domain may require synchronized clocks. Multicast PTP can be used to distribute clock synchronization information to devices within a subnet. However multicast PTP may not be used across subnets unless routers are explicitly configured to forward multicast. Thus unicast PTP may be used to distribute clock synchronization information between subnets. Devices capable of both unicast and multicast PTP may act as boundary clocks between an inter-subnet unicast clock domain and intra-subnet multicast clock domains. The unicast master may be the device that has its PTP unicast port in the master state. The unicast master may also be the grandmaster for the domain consisting of all the devices in multiple subnets. The unicast master may be selected by using a standard PTP best master clock (BMC) procedure.
When a device registers with the domain manager it sends its clocking capabilities to the domain manager including whether it supports unicast clocking. The domain manager maintains a list of unicast clocking capable devices for each subnet. At least one unicast capable device in each subnet should be selected to be part of the PTP unicast group. These devices have their unicast clocking port enabled. More than one device may be selected so that an alternate device is available if the first device is disconnected. This selection may be done manually by a user, or alternatively the domain manager can auto-select the best/desired unicast devices.
In order to exchange unicast PTP clocking messages each device in the unicast group may be configured with the IP addresses of the other devices in the group. The domain manager maintains a list of IP addresses of the devices in the unicast PTP group. When a device is added to the unicast group the domain manager add its IP address to the set of addresses and updates all devices in the unicast group. When a device is removed from the unicast group or removed from the domain the domain manager removes the address from its list and updates all the other devices in the group.
As discussed above, the domain manager does not participate in the clocking protocol itself, the devices in the unicast group maintain clocking across the domain by exchanging clocking message between themselves. The domain manager in only responsible for enabling or disabling the unicast port on a device; propagating the addresses of participating unicast devices when a device's unicast port is enabled/disabled or when a participating unicast device is removed from the domain; and/or notifying the user on clocking mis-configuration
In some embodiments, it may be possible for a user to manually select unicast clocking devices from the list of unicast capable devices. The domain manager may also provide the option of auto-configuration of unicast clocking. This option may be useful when a user has limited understanding of unicast clocking, and to avoid potential mis-configuration by the user when manually configuring clocking. Using the auto configuration option, the domain manager will enable unicast clocking on a subset of devices in each subnet. For example this could be two devices so there is a unicast device and an alternate in each subnet. The auto configuration option may choose the best devices (in each subnet). In some embodiments, these devices may be selected by comparing the clocking capabilities of candidate devices. The capabilities can include information such as the stability of the local clock on the device.
The domain manager may also be able to detect mis-configuration of unicast clocking and can inform the user when this situation occurs. Mis-configuration can arise due to a subnet not having a unicast clock configured or unicast-enabled devices being disconnected or removed from domain subnet. These warnings may include:
When unicast clocking is used to distribute clocking information access subnets, the designated unicast master may need to send clock synchronization information to the other unicast peers in the unicast group. Clock synchronization messages are relatively high rate (e.g., several messages a second). If for example each subnet has an alternate unicast device then the number of devices the unicast master needs to send to is doubled. As there may be a limit on how many unicast PTP connections can be supported by a device, the total number of subnets that can be supported in this network is halved. The volume of unicast traffic between subnets is also doubled. Thus to support a large number of subnets, it may be desirable that the unicast PTP master only sends PTP clock synchronization messages to the best unicast device in each of the other subnets, and the alternate unicast devices are maintained in an “idle” unicast state, with minimal unicast traffic to/from the device. The alternate devices can maintain clock synchronization via the local multicast master.
Devices enter the “idle unicast” state by comparing the clock quality of other masters in the local subnet via the multicast port. When a device determines that another device is a better source of clock sync information, it puts its unicast port into the idle state.
Such an optimized PTP network can be implemented by using PTP v2 for unicast clocking. In PTP v2, there are separate messages for grandmaster information (low-rate) and timing information (high-rate). When a unicast port enters the idle state, it stops sending PTP timing requests messages to the unicast master. Instead it starts sending a low rate periodic custom “keepalive” message to the unicast master. In the absence of PTP timing request messages from a participating device the unicast master will stop sending timing information messages to that device. The receipt of the custom keep alive message at the unicast master indicates that the device is only interested in low-rate PTP grandmaster information messages. The unicast master uses timeouts to determine the absence of a device when it is not receiving timing requests or custom keep alive messages from a device. If a timeout is observed the master can stop sending any unicast messages to that device. This reduces unicast traffic when a device goes away. If the grandmaster information in the grandmaster message changes or if another device becomes unicast master, all idle unicast ports re-activated.
Such a network is illustrated in
When a device is the unicast group is reconnected to the network, it may first send a keep alive message to each device in its list of participating devices. On reception of such a message, the current master will start sending Unicast PTP synchronization messages to that device. This way the recently connected device can immediately become a slave device instead of transitioning through a PTP master state where it sends unicast PTP synchronizations messages to the other devices in the unicast group.
Unicast clocking can continue to work if a domain manager goes away as each participating unicast device persists the list of addresses of the peers, including across reboot.
In some embodiments, multicast flows created in a media network may be sent to receivers within the same subnet or to receivers in multiple subnets. In the latter case intervening routers may be configured to forward multicast. The domain manager is used as a centralized allocator of multicast addresses. Addresses may be requested by transmitting media devices or by media controllers which then configure the media devices with appropriate flow parameters and the multicast address to be used.
In certain instances if there are many multicast receivers in the originating subnet and a few receivers in a remote subnet it may be more efficient to transmit the flow to the remote subnet as a unicast flow. In other cases where multicast routing is not configured it may be more efficient to translate the unicast flow back to multicast in the remote subnet. This is implemented by means of a unicast/multicast translator. This translator may be a specialized implementation of e.g., a Dante Virtual Soundcard or Dante Via. As illustrated in
In order to secure a media network configuration messages issued by controllers may need to be access controlled to prevent un-authorized changes. In addition any changes made should be logged in an audit trail for accountability and diagnostic purposes.
In some embodiments, the domain manager may be configured to allow an administrator to define and maintain a database of access control policies. Different users issuing configuration commands via media controllers may be assigned different permissions. For simplicity users may be assigned roles and permissions may be assigned to each role.
Other roles may be assigned lesser permissions.
So that complex access control policies can be evaluated without overloading a lightweight media device, configuration commands issued by an media controller may be forwarded via the domain manager to the target device.
As illustrated in
It is also possible for access control policies to be defined and managed on the domain manager but cached and evaluated on the device itself, without requiring the configuration message to be forwarded via the domain manager. This can be useful when processing messages that originate from within the device rather than an external controller. This is illustrated in
In some embodiments, media devices may generate diagnostic data, such as events generated on error conditions (e.g., the device local clock lost synchronization, media packet errors, etc.) or periodic statistics (e.g., local lock variation over time, latency of received media packets). This information may be sent to the domain manager by devices when the event occurs or periodically for statistical data. The domain manager may also generate events when a device state change is observed (e.g. a device becomes uncontactable).
Device data sent to the domain manager may be formatted in different ways. The domain manager may post-process the data if needed to generate summaries or other more user-friendly representations. The data may be stored in the domain manager database, and provide various outputs. For example:
In some embodiments, raw information can be aggregated so that long term historical data can be maintained. Specialized databases that are optimized to handle time series data could be used for this purpose.
The data collected in the database may be sent to third party network management tools. For example the administrator of the media network may be monitoring other aspects of the network using a network management tool. Such software may be using a protocol such as Simple Network Management Protocol (SNMP) to receive events from devices. In such a case the domain manager can act as a proxy on behalf of all the media devices and can generate SNMP traps (events) that can alert the administrator using the network management software of issues with the media devices.
In some embodiments, the domain manager may incorporate firmware management for media devices on the network. This may include any combination of one or more of the following functionalities:
In order to participate in a media network containing a domain manager, media devices may need updated firmware so that they can locate and securely connect to the domain manager. In some embodiments, there may be reasons that such firmware is unavailable for certain media devices. In such cases it may be useful for such media devices to be able to be incorporated into the media network and able to send/receive media flows from devices within a domain (e.g., a Dante domain). However these devices do not have the full functionality of devices in the domain e.g., control communication from a controller may not be secure, it may not be possible to send/receive media flows to devices in another subnet, there may not be an audit log of configuration changes, etc.
Allowing the exchange of media flows between enrolled domain aware and non-domain-aware media devices may include any combination of one or more of the following capabilities:
In some existing networks (e.g., a Dante network) that are limited to a single subnet, control and monitoring may be distributed and thus there is no single point of failure. The domain manager allows such networks to be enhanced with many additional features however it does introduce a possible single point of failure. Therefore it is desirable that the media devices can continue to send and receive media flows with accurate clocking even if the domain manager is temporarily unavailable. The media network should be able to recover and restart media flows even if media devices are restarted while the domain manager and other services are not available.
In some embodiments, to maintain availability, media devices cache some or all of the following information:
In media networks where is it critical to always maintain control and monitoring functionality a cluster of domain managers may be installed to maintain “high availability”. In such a network the domain managers may be configured with the IP addresses or hostname of their peers. A virtual IP address and optionally a virtual hostname that is shared amongst the peers may also be configured. A virtual address management protocol such as Common Address Allocation Protocol (CARP) or Virtual Router Redundancy Protocol (VRRP) or a database cluster management protocol may be used to determine which domain manager is the master at a given time. The peer domain managers may also use a database replication protocol to replicate the database state from the master to the slaves may manage the ownership of the virtual IP address. The domain manager that is the master owns the virtual IP address and the other domain managers may be maintained as slaves. The media devices and controllers connect to the virtual IP address and thus connect to the current master. If the virtual address management protocol or database cluster management protocol detects that the master is disconnected then another domain manager will take over its role as well as the virtual IP address. The media devices and controllers will now connect to this new master. As the database state has been replicated to the slaves, the media devices and controllers will be able to continue operation without loss of data.
As the media network is tolerant to temporary disconnection of the domain manager, the domain manager services could also be implemented as a “cloud” service external to the organizations media network. In such an implementation a multi tenancy domain manager could manage multiple media networks belonging to multiple organizations. In this implementation media controllers could be local to the organizations media network. However it is also possible that a media controller in a remote network could control and monitor the organizations media network via the cloud service. Such a network is illustrated in
In some embodiments, it may be that the wide area network connection of an organization may be unreliable, in such a case it is be possible to improve that availability of the domain manager by providing some of the domain manager services locally while others domain manager services are remote. Such an arrangement is illustrated in
In some embodiments, vendor plugins may allow vendors to provide control functionality for specific devices within the framework of a domain (e.g., a Dante domain) and its user interfaces, allowing users to manage vendor-specific elements of a device from within a single user interface.
A vendor API allows plugin implementers to see devices in a domain and obtain model information for that device. Vendors can also send & receive vendor-specific messages to/from devices. The domain manager forwards vendor specific messages between devices and UI plugins. Plugins may be stored in a central database separate from the domain manager that includes information about the plugin and the types of devices for which it is applicable. The domain manager can communicate with the plugin database to obtain plugins for devices within its domains, and present device-appropriate plugins to the user when they are working with those devices in the UI.
In some embodiments, the API can be provided in a form allowing plugin integration into a web-oriented UI. It could also be provided as an API in a compiled program language such as Java or C, if the UI were written in those languages. In this instance the UI may need to obtain the plugins from the plugin database itself.
The foregoing outlines features of several embodiments so that those skilled in the art may better understand the aspects of the present disclosure. Those skilled in the art should appreciate that they may readily use the present disclosure as a basis for designing or modifying other processes and structures for carrying out the same purposes and/or achieving the same advantages of the embodiments introduced herein. Those skilled in the art should also realize that such equivalent constructions do not depart from the spirit and scope of the present disclosure, and that they may make various changes, substitutions, and alterations herein without departing from the spirit and scope of the present disclosure.
This application is a continuation of U.S. application Ser. No. 17/376,730, filed Jul. 15, 2021, which is a continuation of U.S. application Ser. No. 16/478,784, filed Jul. 17, 2019, now U.S. Pat. No. 11,102,051, issued Aug. 24, 2021, which is the National Phase Application of International Application No. PCT/AU2018/050030, filed Jan. 17, 2018, which designates the US and was published in English, which claims priority to U.S. Provisional Application No. 62/447,722, filed on Jan. 18, 2017. This application is related to International Application No. PCT/AU2015/000345, filed on Jun. 10, 2015 and published as WO 2015/188220. These applications are herein incorporated by reference in their entirety.
| Number | Date | Country | |
|---|---|---|---|
| 62447722 | Jan 2017 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 17376730 | Jul 2021 | US |
| Child | 18221726 | US | |
| Parent | 16478784 | Jul 2019 | US |
| Child | 17376730 | US |
