Manual entry of NDI source IPs
Our campus network security admins say the will never enable multicast DNS (mDNS) on our network. So we cannot use mDNS to locate NDI sources on our network. We would like to be able to manually specify the IP address of NDI sources. NewTek NDI Access Manager allows you to manually specify remote sources, and those sources are then available to the NewTek NDI Source Monitor, but not Wirecast. We would like something similar for Wirecast.
I'd also ask them if they can potentially just put your switching equipment and anything that uses NDI on it's own subnet to alleviate whatever perceived net security concerns they have but also make it you can use NDI the way it was designed to be used.
Some of this just sounds lazy on their end, disabling external mDNS access is a no brainer, but proper firewall rules and only allowing internal mDNS usage should alleviate any "security concerns" on their (or more honestly the campus as a whole)'s end.
(otherwise the other hackish way of getting around this, especially if you and your ndi devices are in the same room, would be to just put them all on their own router behind NAT and then the router connecting to the campus network, but you run the risk at some schools of violating acceptable use by doing that and not clearing it with someone first)Reply
Christopher Darbro Our application is mobile - the NDI sources would run all over campus and use whatever network jack is provided by the facility/client, so the logistics of constantly reconfiguring the switching equipment is a non-starter for us. And frankly, I don't want our NDI sources to be discoverable. 🙂 I want to tell Wirecast, "Use the NDI source(s) at this IP" and not have to go through all of the broadcast and discovery nonsense.Reply
Makes sense, though if they are dedicated campus owned mobile devices, the campus network should be able to put them and your other equipment on their own subnet/vlan so that you can use mdns cleanly if you wanted and not expose your NDI sources to anyone else.
I'm only continuing to offer these up as solutions though just because I realize depending on telestreams dev resources/prioritization, in addition to how much newtek has or hasn't opened that capability in their SDK outside of their own apps, can mean it's possible you might not see this solution added to WC soon. (Unless 50 people jumped on board all of a sudden) So if you're looking for a faster solution, what I mentioned might be the way to go.
Additionally, I'm always a big proponent of having production networks vlan'd off of the main network in corporate or campus environments. I've set that up here and other places solely so that if someone in a workplace or on campus has some random malware or misconfiguration that causes network issues, hogs bandwidth, etc, that the live production network isnt affected by it, and always has guaranteed upload and links and internal bandwidth that can't be effected by any shenanigans happening elsewhere on the corporate/campus networks.Reply
Christopher Darbro said:
I'm always a big proponent of having production networks vlan'd off of the main network in corporate or campus environments.
I'd agree. It's better reliability all around.Reply
I'd agree. It's better reliability all around.
But, there is another category of solution where manual IP for NDI might be desirable. As internet services globally get better, the time will come when NDI over public internet will be a possibility. However, mDNS over the internet just doesn't make sense.
I agree with Brandon Utech 's initial request. It makes sense in the long term to allow manual details to be specified for NDI sources. If not to solve his use case, it will help with the internet source use case.
Greg Kuhnert Sienna has actually been ahead of the game on this particular use case (ndi over public networks) for a while, check out https://ndi.cloud sometime, I've used it take red carpet camera feeds from new york to a switcher/control room in los angeles, its a great tool.Reply
Yes. Its a nice cloud product, that contains a feature that could be easily embedded within Wirecast. Specify the remote IP. If it traverses a upnp gateway, open a temporary port map / firewall rule - and it just works on the wirecast side. Yes, there may be a need to open firewall rules on the far end - but thats not a wirecast problem.
Greg Kuhnert said:
As internet services globally get better, the time will come when NDI over public internet will be a possibility.
In addition to SiennaTV's solution...
Stream NDI over Internet
So this is being tackled with various approaches.Reply
All of this is good. But I think there is still a good story to tell for Wirecast to natively handle some of this in house. Being able to configure an IP address in a GUI and use it is about a day's coding. Being able to do uPNP firewall configuration would take a bit longer. But all possible. Assuming Brandon Utech filled in the form as you suggested - lets hope it makes it into a development funnel.