Section 3 : Running a Server

Q316: How these dialrules work?

? Got something to say about this answer? Hit the question mark to invoke the mailer and send your comments to the HylaFAQ maintainers.

How these dialrules work?

I would like to ask a couple of questions about dialrules....

Attached below is a e-mail from Seth Chaiklin to the mailing-list about the dialrules w/ comments from Sam Leffler (and yes: I welcome this for the FAQ).

Date: Tue, 24 Oct 1995 10:35:56 PDT
To: Seth Chaiklin < >
From: Sam Leffler < >

To: Subject: dialrules Date: Fri, 20 Oct 1995 17:46:37 +0700 From: "Seth Chaiklin" I would like to ask a couple of questions about dialrules and area codes. Probably these questions do not come up for most people because they live in the United States and just use the rules outta the box. But the rules are different in Denmark and I have been trying to make my own rules. Therefore, I would like to inquire a little about the principles behind their operations. [Don't worry, I have seen the interesting and helpful examples that can be found on in the contrib section!] I understand more or less the basic idea behind dialrules, have learned to appreciate the help provided by dialtest, and therefore I am NOT trying to ask for advice about how to compose the rules, or what the difference is between a canonical string and a dialstring. However, I would like to check my understanding and possibly make some suggestions to be incorporated into the man or FAQ pages. Question #1: Are dialrules required? In principle, if a person always gave precisely the correct phone number (including necessary codes for getting external lines, or international access, country codes, and so forth, and it was not necessary to hide credit card information or special access codes), then one would not need dialrules. Is that true? If so, then function of dialrules is to provide a kind of "service" to make it easier for the user to succeed in entering a correct fax number (e.g., by removing country codes for one's own country or one's own area code). But this is simply a luxury or user-friendly feature, not a necessity of HylaFax operation. dialrules are required to craft the canonical phone number from the user-supplied dialstring. The canonical number is used to uniquely identify the destination when storing and retrieving cached information such as the remote device's capabilities. This information is also used to create filenames for session logs. The other important reason for dialrules on the server is to provide a uniform mechanism for specifying dialing commands. In particular supporting the +country code syntax means that client phone number databases can be setup in a location independent fashion (important given the client-server nature of the system--otherwise folks in different locales or using different servers wouldn't be assured of being able to exchange phone numbers/databases). Question #2: What are the extent of applications to which the AreaCode, CountryCode, InternationalPrefix, LongDistance Prefix, used for in etc/config and etc/config.modem? My answer: As best as I can tell (from config(5) and from the online documentation about advanced configuration of the server) is that they are only used to hold values that can be used in dialrules. Correct. They are not required, but could be helpful in setting up the dialrules. And it is just helpful to keep these values separately in a config file, rather than "hard-coded" into dialrules. If they are not mentioned in config, then they will not be available for use in etc/dialrules, but otherwise, they have no other effect. Is that true? Correct. Question 3: If my answer to question #2 is correct, then in a situation where one always use the local area code, even when dialing within that area code, then it is necessary to change the dialing rule from the "original formulation." One can still provide a value for "area code" in etc/config file, but if it is not used by dialrules, then it really has no meaning, isn't that right? Correct. Question #4. Is there any error-checking for valid telephone numbers? I realize this is dicey business, but if it is true that dialrules are provided as a step in the direction of userfriendliness (in the sense of checking for International prefix, country code, area code), then why not continue in that direction and have more strict errorchecking. I will illustrate with my own local case (which will allow me at the same time to raise a suggestion about dialrule documentation). All calls within Denmark are composed of 8-digit numbers. In principle the first two digits are a kind of "area code", but these numbers are always dialed. For example, in Aarhus, we have 86 as an "area code", but if I dial from a phone with an 86 exchange to another 86 exchange, I still start the dialing with "86..." Therefore, it would seem "smart" to me if there was a kind of setup in the dialrules that would check to make sure that "local" calls are exactly 8 digits, and otherwise not bother to process local calls that were not 8 digits. There are no exceptions, as far as fax is concerned, and it would also have protect against calling emergency and information numbers, which are usually three digits. For example, maybe the following rules would do it (I am still rather shaky at rule construction -- well I tested them and I can see they are WRONG. But allow me this foolishness to make some more points). [some rules to clean up syntax and process leading '+' and '0'] [0-9]{0,7} = ! replace 0 to 7 digit numbers with nothing [0-9]{9,} = ! replace over 8 digits with nothing In effect, this would remove the phone number if it was "local" and less than 8 digits. And if there was an "internal" exchange (as is the case at my university), then perhaps the following rule just after would pick up those cases? [0-9]{4} = & ! keep 4 digit cases (trust user has valid no). [0-9]{0,3} = ! reject numbers with three or less [0-9]{5,7} = ! reject 5-7 digit numbers [0-9]{9,} = ! reject over 8 digit numbers Or what about the person who only sends a fax once every three months, and cannot remember whether a + or the international access code should be used, so writes: user@+004589424901 or the person who knows that a 0 has to be entered to get an outside line, and therefore adds one of those: user@+0004589424901 In principle...and with sufficient should be able to write rules that could catch these special cases. But let me ask (returning in effect to my question #1, but on a more sophisticated plane): in principle one would not have to write rules to catch these cases, but then it is also likely the modem will fail to complete the call because of the "botched" phone number. It is no different than using an 'O' for '0' or '1' for 'l' or '-' for '_' in composing an email address. You get an error message and then fix it up. But, again, in principle, if one can write the correct rules, then one can protect users (a little) against their mistakes. Unlike the email example, where the problem is a wrong character. Here the problem is that the person knows the correct number, but is a little uncertain about which form the fax server needs to get the information. Question 4a: Is this a foolish idea to try to use dialrules for this kind of error checking? Just not worth the trouble to catch the few errors. The user will just get the fax back. Or maybe this will prevent some unnecessary modem use, and possible calls to undesired locations. Question 4b: Have I made foolish errors in my rule-writing? Yes. I can see that. There are two ways that I intended for folks to reject phone numbers. The DestControls file has an explicit mechanism that lets you reject destinations and return the user a message explaining why the destination cannot be sent to. The 2nd mechanism is as you describe, using the dialstring rules to transform the user-supplied dialstring to an illegal phone number that is then rejected. These two mechanisms can be used together. Suggestion: Is it possible to start to build a small listing of what rule constructs can be used for specific purposes? man dialrules only says that POSIX extended regular expressions are used (which is great news for those who are competent and knowledgeable about such things). But it does not tell where to get information if you are not. The FAQ has a helpful little example about dialrules, but again it just shows the answer, without giving so much insight into the actual rules for regular expressions. I finally found some enlightenment in "man grep". (The GNU version also discussed extended regular expressions). util/regex in the source distribution includes the documentation that comes with the regex package used by HylaFAX. You can also get a POSIX spec that documents the regex syntax. If nothing else, I would suggest mentioning 'man grep' in either 'man dialrules' or the FAQ as a source of information about regular expressions. Also, it might be worth mentioning in the FAQ that one can find some interesting examples of dialrules in at in sgi/fax/contrib/dialrules. Alternatively or additionally, it might be nice to have a weblink in the FAQ to a place where one could read about those expressions. BUT, it is not so important in this context to learn all the ins and outs of regular expressions, but rather to learn those specific techniques that are needed for the limited domain of dialing strings. Therefore, I would like to suggest that a little library of illustrative examples could be built up that could link syntax and function explicitly. All this is fine, but someone needs to do it. I'm sure that Matthias would welcome a contribution to the FAQ. I'd also be happy to include more documentation in the HTML materials. Feel free to contribute. <...other stuff deleted...> I think you understand things quite well and could write something up for inclusion. Most people that use this software do so blindly and w/o understanding 5% of its capabilities (it *is* large and complex, but then again it tries to solve many problems). Better documentation would go a long way to improving this situation. Sam

 Back to FAQ Index FAQ Index  Next question in List Q317: Why have fax user? Last updated $Date: 2000/01/06 00:22:04 $.