Control network IP scheme change and automation

[Ioannis Syrogiannis]

I "inherited" a network IP scheme that even though when it was created it might have been able to support the few networked appliances, now it isn't.
In a normal dolby (DSS) IP scheme, with half the last octet subnet-masked out, two more (non DSS) auditoriums were connected, without following the rule ..241.2+X, ...X.129 etc.
Slow times give me the chance to untangle this complicated situation, but with a small problem.
The automation I inherited also is a crestron based one.
That means that I can't change on my one the IP of it.
I wouldn't mind a lot, since its input is serial and it's output that I care for is not over ethernet.
I never used it for giving commands to the projector/server/cinema processor system, I prefer the server to take care of such things directly.
Yet, on the rare occasions that a power failure occurs, if I don't connect to the user interface to acknowledge the restart, house lights may or may not turn on or off.
And if I am to change the IP scheme, in such an unfortunate event, it would mean that I'd have to connect a PC directly to each of the crestron modules (eth.), with a similar IP and do the job.
After agreeing that the integrator would be the best person to change the IP settings of each system, my question is:
Do you know of any way for one to change the IP settings from a(/ny) given setting to DHCP?
Some networked equipment are able to be re-set to DHCP with some kind of manipulation.
Some micro-computers give you the same ability by using a file with the IP settings.
Is there anything similar that I can take advantage of to save myself from the trip to the cinema in such cases?

[Dave Macaulay]

I have never seen a cinema equipment network use DHCP, except for some that do have DHCP for wireless device connections. All system devices should have static addresses, other things need to talk to them and the D in DHCP stands for Dynamic - device addresses can capriciously change any time, although in practice that's unusual (but not uncommon). You can use DHCP with MAC reserved device addresses but that is a bit of a pain, pointless, plus if your router fails you will lose all those assignments unless you made backups and replace it with the same model.
Can you build a reasonable addressing scheme including the Crestron addresses, assuming they are all on the same /24 subnet? You can use a /23 subnet with all your cinema stuff either above or below the Crestron segment, and have free reign to address all your other equipment in it's own /24 half of the /23. And the Crestron and cinema stuff will be able to talk to each other if you want.
But I would definitely avoid DHCP unless you really know what you're doing.
The Dolby default addressing scheme has only one thing going for it - it works with network hardware and speeds common when it was devised, for users with no clue about networking: just follow the manual and use all Dolby equipment (when it was all available) and it should all work nicely. Otherwise... it sucks. Big time.

[Ioannis Syrogiannis]

Thank you Dave for your response.

I have never seen a cinema network use DHCP either, and I don’t want to use it for anything.
Yet, what I am wondering here is if I can have the crestron equipment, and only that, reset in such a way, so to be able to use the WUI to press “acknowledge” when I need, and do just that.
I can set the router assign dedicated IPs to those. The router failure is less likely to happen than the power failure and backing up, along with cleaning, is the things I do more often in the booth, since I never seem to have it clean enough or secured enough.

The crestron settings, though, are out of my reach. At least, according to crestron. I don’t blame them, but I am trying to find a way to change the network scheme for all equipment on the booth and those little things are the only ones I can’t change. So, DHCP would be a solution, IF there is a way to do that for those. For the time being, and as I see it, I can not build a reasonable addressing scheme, as you write *including* the actual/present crestron addresses. I maybe can build an inconvenient one, a bit similar to the present one, but a bit better.

I would go -in a second- for a Dolby default addressing scheme, if I had all servers to be DSS, and -even now, that they are considered relics- I would go for DSS on all screens in a second, if I had that choice (over the choices I don’t have). Then, I would have found a proper way to “expand”.
A /25 subnet per screen can work, a /25 subnet per booth leaves no place to a reasonably designed network. I wanted to replace a CP750 with a CP950 and I had to use the same (CP750) IP, since the default one was occupied by another cinema-server! Not a tragedy, but not a good working scenario either. And guess which network automation equipment still sends CP750 text commands to the CP950…

So, now, that I have the time to address all the small and the big issues of re-building a cinema network, I will do so, without hesitation. Stoic philosophers were saying that “there is no bad that doesn’t contain some good in it” or, a rough modern translation, “every cloud has a silver lining”. This downtime give some chances.
I am just wondering if any of you would know a way for me to avoid the inconvenience of having to go on site, change IP on a laptop and connect to each module, in order to make it operational again, every now and then. Especially for the consequences in case of my not being able to be there.

[Carsten Kurz]

Why is the Crestron such an issue to adjust? I understand not everyone is entitled to work on them, but, for a major change in the network setup...?

[Steve Guttag]

I disagree with Dave on his assessment of the Dolby "DSS" addressing scheme. It actually was clever and ensured one never ran out of IP addresses...no matter how big/complicated the booth and its network got and yet it was very simple to navigate. You got 127 IPs for EVERY screen and you could have up to 252 screens (yeah, right) or a mixture of screens and media devices (e.g. DCDC, Eclair...etc.). It does require one key piece that I think only Dolby included in their servers...an internal router. With that, from the "Theatre Network" one could access any device on an auditorium network. If you wanted to get to the projector in theatre #4, for instance, you would use server 4's Theatre IP as the gateway to get to 192.168.4.133 (projector 4), from the Theatre network, you would use 192.168.241.6 (server 4) as the gateway and the DSS server would be your router to get there. This could be greatly simplified if the installer configured the router on the Theatre network to have a routing table that defined the gateways for each auditorium. Then, from the theatre network, you don't have to do anything special...just access the various devices with the known IPs...the router and servers do all of the networking.

Note too, this also means you only need to run a single Theatre-wide network (The theatre network) as all control/management communication is constrained to each auditorium. Think of it as a "star" system with the Theatre Network at the middle of the star and each auditorium as the points going around the middle.

The change I made to the scheme is that I added 100 to each theatre number so that theatre 1's auditorium IPs would be 192.168.101.x. This avoided ever conflicting with a router in the complex that almost always comes default as 192.168.1.x. it also means that if you run an install disc, you don't have two auditorium 1s until you reconfigure.

If you don't have 100% DSS servers though, the scheme doesn't work if you want to access all IT in a uniform manner. Most systems create two distinct networks a Media (just content moves around here and typically has no gateway) and a Management/Control network.

Most people put the auditorium number in there, somewhere and you really do need to map out your scheme before you start or you will forever be tripping over yourself. As others have indicated, DHCP is not the way as you will, for instance have no way to reliably control your sound since you won't know where it is located and not all devices can control devices by name.

Really think out your needs. Simpler schemes will limit you to say 10 devices per theatre. These schemes will have IPs that will have the 4th octet with the auditorium number and device. So, if your projector is device 1. In theatre one its 4th octet will be 011. For theatre 2 it will be 021 and so forth. Things below 010 would be for common devices for all auditoriums (router, switch, TMS). You can get up to 24 auditoriums with this sort of thing, if your theatres aren't too busy (needing IPs).

The other popular method is what I call the Cinedigm scheme (I call it that because that is where I first encountered it and have many locations using it because they were on VPF programs). Again, the screen number is in the scheme. However, things are sequential by device, not by auditorium. For instance, the projectors start at 191. So projector 1 is 191, projector 2 is 192...and so forth. This scheme is normally a /23 type network so you can have over 500 IPs for the complex...which is a lot, even for a moderately sized complex. I have expanded upon it for our systems by recognizing, it was designed for up to 40-screens (there are 30+ auditorium complexes but our biggest is under 15 screens). By limiting screen count, I could expand the number of devices per screen. For a 10 plex, I can get over 30 or so IPs per screen which covers a lot of ground. That said, I ensured it is backwards compatible...so projectors, regardless of screen count are still in the 191+. Our more technically savvy theatres (ultimately the screening rooms with typically 1-3 screens) can then have the most IPs.

Note, it is possible to expand the first method I mentioned by doubling (or even tripling) up the ranges...so if you only have 10 screens...what would have been assigned to screen 11 could be the next grouping of screen 1 and so forth. Again...figure out your needs and pick a system/design your own and go with it but try to look reasonably into the future to not have to make a bunch of exceptions.

I would avoid any scheme that does not have the auditorium number in it somewhere though and really avoid the "clever" one that cut up a range with masks. It can cut down on cabling but it is a total PITA to deal with on service and there is no easily discerned IP per device. All those are good for are conservation of IP addresses in a large NOC where complexes use very few IPs. It's what happens when an IP expert designs a system but isn't a theatre tech or realizes the needs of cinema specifically.

[Ioannis Syrogiannis]

@Carsten

I asked the company for a way to configure the IP.
Their reply was, “you need the toolbox, but access is restricted, get a reseller of us to do it for you”.
So, I am looking into alternatives. It seems that there are not any, or, maybe, they are not widely known.
I probably won't be able to avoid the elegantly put... PITA.

@Steve
There are a few different schemes that are proposed for a theater. Dolby had one, Sony another, companies who provide NOC services tend to adopt their own, with their advantages and disadvantages.
(As a side-note, I believe that the XDC CineStore SoloG3 servers were using internal gateways to get to the auditorium’s equipment, but to be honest I am not sure any more.)
The kind of scheme that I am inclined towards is a /(24-X) one, where X corresponds to 2^X is bigger or equal to “number of auditoriums+1”. In other words, having the third octet (second from the last) to indicate the auditorium (or central control) in some fashion and use common numbers on the last octet for the same type of equipment. It’s more demanding in number of IPs, but I’ve seen that in practice is easier and safer to rely on and leaves you space to add the odd networked device that may be temporary (a special event) or not.

[Bruce Cloutier]

You could put an inexpensive router ahead of each Crestron and remap their IP addresses into your scheme. You could use one router and put all of the Crestron behind it and be able to access each by port number (use NAT and port forwarding). Two completely different subnet schemes can exist on the same wire. So you could layout your new IP scheme on a new subnet and leave the Crestron where they are. Then you can configure one PC to talk to the Crestron when you need to. There are lots of kludged tricks to get around it. All of it though dirties the elegance of your new layout. I get it. Seems they take "fixed IP" a little too far.

It might have to do with SSL certificates. If you change the IP address you have to get a new CA signed certificate. The JNIOR has to use self-signed certificates for that reason. You change the IP address and it regenerates the certificate. If you need a CA signed and trusted certificate then you are stuck. I've toyed with a Let's-Encrypt approach for trusted certificates for the JNIOR but... nobody cares about SSL and the JNIOR here. We do have units in security situations on the open Internet. There it is a different story. You can install your own CA signed certificate. But this is the only headache I ran into with playing musical IP addresses.

I've suggested that we ship JNIORs with DHCP enabled. That would make locating the JNIOR easier wherein you can configure your fixed IP scheme. The 10.0.0.201 default address can be problematic. Instead we went with the Support Tool and the Beacon protocol so you can configure the JNIOR IP addressing regardless of how it is configured or misconfigured. The DCHP change would be simple for us if anyone thought it better. But, DHCP is not appropriate for routine use here.

[Dave Macaulay]

Steve: fair enough, but the DSS scheme does have problems. It was designed when 100Mb networks were standard and could saturate if traffic was not isolated, and drop packets. So each DSS scheme auditorium is on a separate /25 network. Advantage is limited traffic avoiding saturation and - for example - that server 1 can't talk to Jnior 2 if you mess up the addressing and thus control the lights in the wrong room. But let's presume that the tech is competent and not doing that. It also means that, if something doesn't execute commands on #1, like a CP750, you can't temporarily readdress the #2 server to use the #1 CP750 to help diagnose what the problem is: #1 can't communicate with #2 devices.
1000Mb networks are standard now and as far as I know all (except ancient) servers and projectors have 1000Mb ports. With standard switches (no "hubs") a flat 1000bT management network will never saturate.
Using a /24 segment gives you 255 usable addresses. If you have up to 10 screens that gives you a lot of room using a logical numbering scheme like x.x.x.01 for server 1, x.x.x.02 for server 2 etc, x.x.x.11 for projector 1 and so on. I can't think of any screen setup that could possibly have 24 different networked devices. I have sites with 24 screens that use this scheme on a /24 segment, meaning each device reserves 30 addresses allowing 8 devices per screen - and there are only 5 or 6 anyway (server, projector, S1 projector, audio processor, Jnior).
There are advantages to having everything on one segment. I can sit at a desk with my pc connected to one screen's switch or projector, and connect to all devices for updates and diagnostics. I suppose the DSS does route the theatre network to its auditorium network but many small sites do not have a theatre network connected. And many sites have mixed server brands, especially now when a dead DSS is essentially irreparable.
Even Dolby DSS support techs are less than fans of the DSS scheme.

[Steve Guttag]

I have found that as I've done screenings, MOST of the sites I've personally been in have adopted what I call the Cinedigm scheme or a VERY close variation. I have essentially adopted it as well and have developed spreadsheets for various auditorium quantities that allow me to quickly and consistently assign IPs without having to refigure anything. If a device is prevalent enough that it warrants its own IP...then I will add it to all sheets so it ripples through and that set of IPs are "taken" for all systems. For instance, when Closed Captions became required (they were not in 2010 so there was no set assignment)...now all of my sheets have a dedicated number for them. I suspect, over time, the need for Series 1 TI boards (Series 1 projectors required TWO IPs) will no longer be required. GDC needed another IP for their HDSDI mediablocks when they became DCI compliant...those IPs are all reserved on all of my sheets but, over time, through attrition, they will likely free up.

[Ioannis Syrogiannis]

@Bruce
Well, that-using a router in front of such a machine, while I can get it, I wouldn't have thought of.
While it complicates things and I am not going to do it, I really appreciate the idea behind it. Chapeau !
The idea of changing the configuration of a PC on site to make the setting I thought about, but it doesn't answer to the problem of me being on-site. If I change the network settings, there will be no internet (and thus, remote control) to take advantage of.

Except if a routing command would do such a trick.
Meaning to specify that the gateway for the given address -say- 10.10.10.5 will be the same (10.10.10.5).
For example:

route ADD 10.10.10.5 mask 255.255.255.255 10.10.10.5 if *network-controller-number-here* -p

I'll have to check if that works or not.

I was using a similar command so to let control PCs (with communicator software) to connect to 192.168.1.133 projectors when on internet with same (192.168.1.1) rooter IP on the second (often wireless) network interface controller. I never learned its equivalent on Linux or OS X though.

[Bruce Cloutier]

@Carsten
Their reply was, “you need the toolbox, but access is restricted, get a reseller of us to do it for you”.

Maybe pursue this avenue to determine the cost and/or amount of hassle in changing the Crestron addressing with their assistance. It might be not be all that unattractive to do. I am curious. I don't know. If it were us, we'd just do it for you but, I don't know, we're maybe not the norm.

The idea of defining a new logical scheme for everything that would accommodate the then anomalous Crestron addresses sounds like the least disruptive approach. You could set aside addresses for the Crestron equipment fitting in the new scheme. Sometime down the road you can get the Crestron addresses changed or the equipment updated/replaced. That's probably where I would go if faced with this.

We are actually dealing with our own IP address issues with our products laying all over the place consuming a lot of address space. We set up production as its own subnet to keep that out of the mix. Sitting down and cleaning it up seems to fall on the back burner. Now we are not supposed to be in the facility. Ugh.

[Sean McKinnon]

It is possible to remotely configure crestron equipment, in fact as an integrator we do it all of the time where we have a programmer in a different state "dial in" and work with an on site tech to load programs and make configuration changes.The issue is going to be acquiring a local pc with toolbox. I have done t it before in emergency situations where ive installed toolbox remotely, done what i needed to, and then uninstalled and deleted toolbox all remotely. Maybe you can find a crestron dealer that would do that for you?

[Greg Routenburg]

The fact that Crestron locks out anyone that is not a Crestron dealer is a pretty big deal breaker for me. I'm all for limiting manager access to configuration of equipment to avoid tampering. That's what passwords are for. I would never buy something that I need to rely on someone else to configure or change. That's just annoying. I'd be adding the replacement of those automation devices to my upcoming equipment replacement budgets and installing Jniors in their place.

The DSS servers were very clever in the way they networked together using dynamic routing protocols. It provided for some nice remote management options if you had a core router that supported OSPF and any sort of secure VPN for example. Also, you could communicate between auditorium networks so long as all of the complex was Dolby and dynamic routing was left enabled in the network configuration. The servers would establish neighbour relationships with each other over the Theatre Network interface on the 241 network and route auditorium traffic between multiple Auditorium networks if necessary. It wasn't the intended design by it was possible. It's probably my favourite design to date.

I've adopted a number of Christie VPF networks that have a design similar to that of Cinedigm. I've just stripped out all of the ACLs and port security from the switches to allow better flexibility and added their VLANs to my core equipment. I have no complaints.

[Ioannis Syrogiannis]

@Sean and @Bruce

I think that I will pursue the “once in a while using rooting” idea for now.

As I wrote initially, I don’t like the idea of automation sending commands to the cinema processor (especially faulty ones), projector, server or taking care of anything else than the lighting (and I forgot door magnets). I prefer to make a show playlist that will be detailed and customised to my needs. So, given the programming being inspired more by film projection and the IP configuration being unreachable, I’ll make an effort to minimise its use to serial and put it in the list of “to be replaced” as Greg suggests.

That work model doesn’t seem flexible enough to accommodate my needs. I would either have to be a crestron dealer or ask for one to sort things out for me every once and again.

Being used to automations that are either dead simple, like: input pulse/latch this -> output that or able to do from a simple task to bring-the-newspaper-to-the-bed-while-heating-with-an-iron-first if you take the time to configure it properly and add the “iron” module (like jnior), crestron seems limited by its own rigidity.

While I feel obliged by your input, and I’ll press “like” to your willingness to contribute, somehow, that willingness augments the contrast with that aforementioned inflexibility.

[Bruce Cloutier]

If the Crestron automation does the job then I would argue against its replacement. You have to consider whether or not the contribution to the landfill is something that you would feel good about. Those devices might be more capable of certain things that the JNIOR doesn't do.

I am also not happy about not having full control over my equipment that I buy outright. Of course, I am quite confident in my ability to reverse engineer and hack my way into things that I need to get into to. Especially when the manufacturer is particularly obnoxious. I also despise things that require login back to the original company before they work at all. And then there are things that require monthly fees now, that I have purchased outright at least a dozen times before (MS Office). And... I can rant forever.

I get all of the copyright protection issues with content. But I can rant about how it shouldn't force equipment to go obsolete and require replacement. I have firsthand experience with that as well.

So, Ioannis, everyone has a "to be replaced" list but maybe not just replace stuff that is functional because the supplier pisses you off. Beat them up a little first. They should take care of you.