CLOUD for NDI
global ip video network
Sienna Cloud Blog #6
17th April 2018, London
Configuring the Master / Slave Node method with Sienna.Cloud
The traditional configuration for Sienna.Cloud requires all nodes to be able to contact one another directly, using UDP port 9002. For operations over wide area networks this usually requires Port Forwarding at each Node location, or use of a VPN.
In practice there are situations where this can be challenging -eg. when using connectivity provided by a 3rd party it's unlikely you will be able to configure port forwarding, and in some cases VPN connectivity is blocked, or ends up being relayed.
For these scenarios, Sienna.Cloud now has a new option - Master / Slave operations.
The Diagrams below show the differences between Master-Master and Master-Slave mechanisms.
Master - Master Mode
Where both Nodes are Masters, each end requires Port Forwarding to route Incoming UDP Port 9002 traffic to the Node.
Regardless, both ends require outgoing UDP Port 9002. This is the default, symmetric mode of operation.
Master - Slave Mode
Where one Nodes is a Master and one is a Slave, only the Master Node end requires Port Forwarding to route Incoming UDP Port 9002 traffic to the Node. The Slave Node will only ever make *outgoing* calls, which will be replied to so it doesnt require port forwarding to accept unsolicited incoming calls. This can mean that at the Slave end, only a basic internet connection is required, with little or no configuration. You can even use the 'Auto Address' checkbox in your Sienna.Cloud node setup to allow the Slave node to auto-detect its IP address and publish this to the configuration stored in the cloud.
Regardless, both ends require outgoing UDP Port 9002. In some cases, this may be blocked on the Slave end, if there is a blanket policy of blocking by default. If this is the case you can try to find an outgoing UDP port which is not blocked, and use that instead. You may need to ask the network IT folks which ports are open, or you can guess based on what services already work. For example many networks allow the use of TeamViewer, and this requires UDP port 5938 to be open. In this case you can configure the London Master Node as shown below, with port 5938 as the Public IP Port. Then, in the London Firewall/Router you make a port forwarding entry to connect external port 5938 to internal port 9002 on the Master Node.
In this way, the Slave Node in New York can make an outgoing call on UDP Port 5938 - which the Router will allow because it thinks its TeamViewer Traffic - and this hits the London Router - where a Port Forwarding rule passes the call to the Master Node in London on its internal port 9002.
One thing to note here is that you probably cant operate TeamViewer on the same machines whilst you are using UDP port 5938 for Sienna.Cloud. However, you can use any other UDP port which happens to be open, and there are 65535 to choose from. How you determine which ones are open without asking IT is something we will address in a future blog.
One thing to note is that you cannot communicate Slave to Slave, so you will need a Master Node in all cases, and if you have a Master Node at your base, and multiple Slave Nodes for external sites, the Slave Nodes will not be able to communicate with one-another. If you need to pass video between 2 Slave Nodes you would need to do that via the Master Node.
Conclusion : Master - Slave Mode
The New Master / Slave option provides significant benefits when operating on unfamiliar or aggressively locked down networks. Critically it offers confidence that anywhere you setup on an ad-hoc basis, you should be able to create a direct (non relayed) Sienna.Cloud connection and hence pass video in both directions between Master and Slave Nodes.