My wild, totally uninformed, guess that it wasn't an assumption that empty meant wildcard but rather a failure to sanitize input at all. My experience, though

My wild, totally uninformed, guess that it wasn't an assumption that empty meant wildcard but rather a failure to sanitize input at all. My experience, though limited, with these management applications is that the developers assumed the operator would never, ever, ever enter an illegal or unexpected value and therefor implicitly trusted the input. It's possible that the empty value was considered illegal and whatever module that handles call routing on the phone switch failed to function, blocking traffic as a result of the value. It sounds crazy, but consider a similar circumstance of popping something illegal into an Apache or nginx configuration file. The service fails to start and anything hosted behind it is down. I'm not saying it's acceptable, just likely[0]. The difference here is that this software has an audience of very few people, is poorly developed to begin with, and usually outputs error messages similar to C++ compilers from the 90s. And the software was probably written in the 90s, too. [0] While a competent sysadmin expects that a failure to provide valid values in a configuration file will result in a service not functioning, our typical interaction with modern software comes with the expectation that an invalid value provided to a configuration form will result in a rejection of the value. Even in the cases of Apache/nginx, they provide a method to check your configuration before using it -- just to be safe to make sure you didn't leave out a semicolon/closing brace/</Something>