Novell's most recent products, and those in development, are designed to be modem independent. This enables new modems to be supported by these Novell products without a new version of the software being released. All that is required is to load the appropriate modem description file onto the specified system.
Novell products can interpret modem description files and execute script commands in the files to perform modem operations as the application requires. Neither the modem control components nor the software products themselves are specific to any one modem or set of modems. Any details specific to modems are contained in the modem description files.
When Novell products are installed, modem description files are copied along with other product files. As users configure the software, they identify the modems to be used from lists of modem names. Any modem that has a modem description is presented in these lists for the user to select.
When a port is configured from the Network Interfaces screen of the Novell Internet Access Server Configuration utility (NIASCFG), the type of modem attached to the port is specified in the Modem/DCE Device field. This option enables you to select a modem initialization script that is specified in the compiled NIASCERT.MDC, NIASMDM1.MDC, and NIASMDM2.MDC files in the SYS:SYSTEM directory.
Because these files are compiled, they require a special modem script editing tool, WMDMMGR, to read them and make changes to them. Multiple *.MDC (Modem Definition Compiled) files can exist in SYS:SYSTEM; however, if a description of a particular type of modem appears in multiple *.MDC files, there is no guarantee as to which description is used. To avoid confusion, a modem description should appear in only one *.MDC file. When Novell Internet Access Server 4.1 is installed, any previously installed *.MDC files are moved to the SYS:SYSTEM\BACKUP directory. Only files included in Novell Internet Access Server 4.1 remain in the SYS:SYSTEM directory.
If you create new modem description files, copy them to the SYS:SYSTEM directory so that they are available to the routing software. If the routing software is running, issue the REINITIALIZE SYSTEM command to have the modem script changes take effect
This section discusses the format and content of the information present in the modem description files. The method of defining the capabilities of a modem is specified, and the process of constructing scripts to accomplish modem operations is outlined. Several examples illustrate uses of the details presented.
A modem description file includes information describing both a modem vendor and individual modems. The information about the modem vendor is specified first, with from one to many descriptions of modems following.
One way to organize modem descriptions is to collect information about all modems from one vendor into a single file. This makes it easy to register the single filename with Novell. Another possibility is to group modems by "family," as might be done with all the XYZ Xxxx sample models. We suggest that all modems manufactured by a vendor be located in a small number of files.
A typical modem description file includes the following:
The vendor information begins with the vendor's name, which identifies the company creating the description file. A copyright notice can be included to protect the company's rights. Version information should be added to allow tracking of additions or corrections to description information.
Modem-specific information begins with a line specifying the modem name. This name must be unique within the entire set of modem names known to Novell and should include some form of the vendor's name to avoid conflicting with any other vendor's descriptions.
Modem option lines supply information regarding the features, capabilities, and default values of the modem. This information is needed by the modem control components to determine which logical operations can be performed. The information would include the highest interface bit rate possible for the modem, the link types the modem can use (analog, ISDN, and so on), and whether the modem supports a fixed rate.
Modem scripts that perform particular operations are specified. These scripts are simply strings encoding suboperations to be executed that together accomplish the desired operation. Multiple sequences of commands can be combined, if required.
The final section of a modem description file contains the strings used to decode a modem's responses when the modem answers an incoming call. For example, the string returned by a modem when a call is successful might be associated with the "CONNECT" response. Additional response recognition allows modem control components to record the options that are negotiated for this call.
This section describes the components that can be used in modem description files.
The following fields are part of the vendor description:
The manufacturer and copyright string values can be up to 80 characters long. The version numbers can have numeric values from 0 to 99. Currently, the values are not used directly by modem control components, but they are provided for use by modem vendors.
This section explains the modem keywords and how to use them.
The modem name string value can be up to 39 characters and must be unique within the entire set of modem names known to Novell.
There can be multiple descriptions for the same modem, with each appropriate for distinct circumstances. For instance, it might be found that most revisions of a particular modem can be initialized quickly, but that some ROM levels require delays between output characters. Rather than force all users to wait for a lengthy initialization operation, it is possible to create two descriptions, as follows:
"XYZ Modem Xxxx""XYZ Modem Xxxx (Slow Init)"
The following rate options require values to be defined:
When a modem operation specifies the use of fixed rate mode, the FIXED rate option supplies the bit rate used to communicate with the modem. When that mode is not selected, modem control uses this option to determine the default bit rate for the interface to the modem.
Modems can be initialized to use one unchanging bit rate between themselves and the data terminal equipment (DTE). This bit rate is usually set to a value high enough to permit use of compression, no matter what line speed is used on a connection. The numeric value is the bit rate to be used when the modem is put into fixed rate mode.
NOTE: This option also implies that fixed rates are supported by the modem (refer to "FIXED DTE RATE: Place modem into fixed interface bit rate mode.” for more information).
Some modems permit the use of the FIXED DTE RATE feature, but with only one allowable bit rate, as specified by the FIXED option. This option specifies that this restriction is true for this modem.
The set of interface bit rates that can be used to communicate from the DTE to a modem usually has an upper bound. This option supplies the maximum interface bit rate to be used with a modem. The numeric value for this option is the maximum rate in bits per second.
Depending on how your modem is being used, two of the following options might have to be configured. The first two of the following options are configurable; the last two options are not configurable. These options are described as follows:
Some modems require a greater amount of time to process complex commands. Complex commands that are sent to these modems one character at a time are successful. This option enables you to specify the amount of time to insert between characters of selected commands.
The numeric value is the time, in tenths of a second, that modem control should wait between sending characters. There are two script operations for output: one inserts delays between characters; the other does not insert delays between characters. If this option is not specified, the default delay is zero (no delay).
Possible values are as follows:
Modem scripts are text strings that are sent to the modem to cause a particular behavior. They are associated with a particular modem capability and are transmitted to the modem when the application software wants to invoke that operation.
More information on the content and creation of modem scripts is given later in "Script Operations.” Individual scripts are summarized here:
This script enables the use of any of the error correcting protocols implemented by a modem when the next data connection is begun. Because which protocols might be activated depends on the remote modem, this script only specifies that the best possible protocol for each connection be used. Through monitoring the negotiation progress responses, the modem control components can be informed of the characteristics of the protocol activated.
This script places the modem in the mode of automatically answering incoming telephone calls. A connection can begin without intervention by modem control. Modem control monitors the progress of connection initiation and detects when the connection is complete and data transfer can begin.
This script enables the use of any of the data compression methods implemented by the modem when the next data connection is begun. Because the particular compression method employed depends partly on the remote modem, this script specifies only the preferred method to be used. Through monitoring the negotiation progress responses, the modem control components can be informed of the characteristics of the method activated.
This script is executed when a call origination operation is requested on a switched line. The operation request parameters include whether the dialing should use pulse or touch-tone signaling, and the destination telephone number. These parameters are inserted into the dial script string using the substitution tags [T] and [P]. These tags are described in detail in "Script Operations.”
This script places the modem into fixed interface bit rate mode. This allows the interface to be programmed to one bit rate that can be used for all subsequent connections. The actual rate used is determined by the associated FIXED rate value and SINGLE FIXED RATE rate flag.
This script causes the modem to disconnect any call that might be in progress (that is, place the modem on-hook). This script should specify all required operations that ensure that the call is disconnected, irrespective of the current modem state.
This string is part of the overall HANGUP script for the modem. To change only the ESCAPE output string, you can type directly into the edit box. To modify the overall HANGUP script and sequence, select the HANGUP button.
This script places the modem into a hardware flow-controlled mode. In this mode, data transfer between modem and interface is controlled through the use of the Request-to-Send (RTS) and Clear-to-Send (CTS) RS-232 signals. Each signal controls data transfer in one direction.
This string is part of the overall INIT script for the modem. To change only the RESET output string, you can type directly into the edit box. To modify the overall initialization script and sequence, select the INIT button.
This script causes the modem to be initialized to a known state. This state must have all optional features disabled. That is, the purpose of the INIT script is to put the modem into a state in which any of the other features can then be added by individually executing scripts.
The INIT script is usually the first script executed when a modem operation is begun; the only script that could precede it is the HANGUP script to disconnect a call in progress. The INIT script can make no assumptions about the previous state of the modem. Indeed, the previous user of a modem might not have been Novell's modem control; therefore, not even modem control knows the state of a modem.
The script must reset everything that can be affected by modem commands. This includes features like echo, call progress, result code, modem signal usage, flow control modes, and so forth. The script must set the correct modes so that modem response strings can be recognized.
When a modem initialization operation is requested and the leased-line feature is requested, this script is executed to place the modem into leased-line mode. In some cases, this feature is not under control by commands, but rather, some switches must be set. In this case, the script might be absent.
This script is executed when a call answer operation is requested on a leased line. The modem should attempt to connect to the remote modem using answering frequencies. Once this script is completed, modem control monitors the local modem's responses to detect when a connection has begun.
This script is executed when call origination is requested on a leased line. The modem should attempt to connect to the remote modem using origination frequencies. Once this script is completed, modem control monitors the local modem's responses to detect when a connection has begun.
This script is executed when a manual call answer operation is requested. The modem should attempt to connect to the remote modem using answering frequencies. Once this script is completed, modem control monitors the local modem's responses to detect when a connection has begun.
This script is executed when manual call origination is requested. The modem should attempt to connect to the remote modem using origination frequencies. Once this script is completed, modem control monitors the local modem's responses to detect when a connection has begun.
This script is executed when a modem is initialized for a synchronous connection. Certain modems allow synchronous mode connections, especially when trying to connect to mainframes and UNIX-based systems.
A modem script contains a sequence of nano-operations that inform modem control about which actions to perform. These actions include output of ASCII characters, controlling interface signals, checking for expected input, and so forth. There is no facility for conditional execution of nano-operations; the entire script is executed unless an error occurs.
Each nano-operation consists of an alphabetic character optionally followed by parameters for that operation. These values can be string or time values, or other modifiers for that basic operation.
Following are the operations summaries:
This operation turns on the asynchronous "break" signal momentarily. Toggling the break signal can be used to switch a modem into command mode.
The break operation can be qualified by a decimal number giving the length of time, in tenths of a second, for which break is to be turned on. If a time value is not given, the default break of 0.5 second is used.
This operation controls the DTR signal to the modem. The DTR signal is turned off momentarily and then turned on again. Turning off this signal can be used to switch a modem out of data transfer mode.
An optional parameter, TIME is the duration, in tenths of a second, for the DTR signal to be turned off.
If a time value is not given, the default DTR off time of 0.5 second is used.
Characters that have been buffered for output or input but not yet processed can be discarded by this operation. This might be useful when modem responses, up to a point, can safely be ignored, or if prior output should be discarded when new commands are entered.
The flush operation must specify which streams should be flushed.
This operation allows a script to check for a specific string to be received from a modem. For example, after most modem commands, a script should check for the returned indication of success, usually "OK." There are two variants: must match or optional match.
The operation can optionally be qualified by a decimal number specifying the maximum time to wait for this response. This value is specified in tenths of a second. If it is not given, the default value of 5 seconds is used.
Modem control continues receiving characters from the modem until one of two occurrences. If a matching string from the modem is completed, the nano-operation finishes and the script continues. If a match is not completed and the timeout period has elapsed since the last character was received from the modem, an input timeout is declared.
If this was a must match input string operation, the timeout causes the script to be terminated with a "bad modem response" error code. Otherwise, the timeout simply terminates the optional match operation and continues with the rest of the script.
This operation allows output of character strings from the script to a modem. The output string can contain any non-null, noncontrol ASCII characters.
If a delay must be inserted between characters, the "Output with Delay" operation uses the delay time specified by the OUTPUT DELAY option value.
The string to be output is bounded by a delimiter character chosen by the script creator. The script creator should choose a string delimiter character that is not used for any interactions with the modem. This character should not be an alphanumeric character because this would make reading descriptions difficult. A survey of several modems has identified the many punctuation characters that are used within modem commands and responses. The following set of characters is recommended for use:
` < ^ _ { } | : ' ,
By convention, a colon (:) is used.
Control characters can be inserted into output strings using the back-quote character (`).
Variable strings can be substituted in output or input strings with the use of a substitution marker. A substitution is indicated by a substitution tag name surrounded by brackets ([ ]). For example, the substitution of the tone or pulse modifier and the phone number in a dial-out command might be coded as follows:
ATD[T][N]
where [T] is replaced with T or P, and [N] is replaced with a dial number.
Only a limited number of substitution tags are defined, and the substituted strings are not variable by modem type. The predefined tags are as follows:
Care should be taken that the longest command sent to a modem does not exceed what the modem can handle. Many modems are limited to a maximum of 40 command characters, excluding the leading AT, spaces, hyphens, and final carriage return. The input command can be used to break up long command-output sequences.
This operation allows a script to pause execution for a period of time. This is useful when modems might require additional time to complete complicated modem commands.
An optional parameter, TIME is the pause time in tenths of a second. If a time value is not given, the default time value of 1 second is used (time = 10).
This operation skips all the responses from a previous command before issuing a new command. It causes a wait until the modem remains continuously quiet for the specified time.
An optional parameter, TIME is the pause time in tenths of a second. If a time value is not given, the default time value of 1 second is used (time = 10).
This nano-operation discards any data received from the modem. Whenever a character is received, the elapsed time timer is reset to 0. When the elapsed time timer reaches the specified wait time value, the nano-operation completes successfully. An additional timer records the total time since the nano-operation began. If this timer reaches the sum of the specified wait time plus 5 seconds, a timeout is declared and the nano-operation completes unsuccessfully, causing the script to be terminated with an error.
This operation allows scripts to change the data rate used to communicate with the modem. This is used with modems that do not automatically resynchronize interface data rates after switching back to command mode from data transfer mode.
After execution of this operation, any further output or input through the interface uses this data rate. Some asynchronous equipment must flush one or both of the input and output streams when changing data rates.
The response strings in a modem description allow recognition and interpretation of data sent from the modem to the DTE. Response strings inform the modem control software of the success or failure of a command. These strings also let modem control detect when a call is arriving.
As the responses generated differ between modems, the modem vendor must supply information to allow modem control to recognize responses. Response strings contain from one to many pairs of substrings, the first giving the input string to be recognized and the second representing the standard "meaning" of the string.
With the ever more complex responses found in newer modems, it is sometimes necessary to perform multistage matching of response strings. An example would be when the modem is using negotiation progress monitoring to capture added information about connections. When the PROTOCOL response is received, the first stage of recognition would identify the input as the PROTOCOL message. The second stage of recognition would then identify the particular substrings that might be present in this message. This progression from one stage to the next is called chaining.
Modem control accumulates ASCII characters received from a modem until a carriage return character (\x0D or decimal 13) is received; all other control characters are ignored. The accumulated string is then compared to the match strings in the RESPONSES keyword string. When a match is found, the meaning is interpreted and the appropriate action is taken.
Modem response strings can comprise two string elements: the match string and the meanings string.
The first of each pair of strings in the RESPONSES string is known as the match string. When modem control is monitoring modem responses, characters received from a modem are collected until a carriage return is received. The input string is then compared against all the match strings found in "Modem Responses." This matching operation is case-insensitive and proceeds in the same order in which the string occurred in the description file.
Match strings do not need to be the entire response string to declare a match. Only the initial characters of a response must match the match string. Thus, the match string "ERR" matches both the response strings "ERROR" and "ERRONEOUS", but not "ERASE". However, this might make the order in which match strings are tried even more important.
The second string of each pair of strings is known as the meanings string. The interpretation of this string defines what the recognized response means to modem control. This includes whether the response is a success, a failure, or some intermediate indication. When certain optional connection features are recognized, they can be signaled to modem control by this method. Finally, this is the way that bit rates are given to modem control.
There are four types of meanings information, as shown in Table B-1: status, rate, feature, and match chaining. The status and feature values are decimal indices into tables used by modem control. The rate decimal value is the actual data rate in bits per second. The match chaining value is described in "Match Chaining.”
Type |
Meaning |
|---|---|
STATUS |
Reports a status; might terminate scanning. |
RATE |
Reports a data rate. |
FEATURE |
Reports an enabled feature for this connection. |
CHAINING |
Continues scanning using another string. |
Status information is used to notify modem control when something of significance has been discovered in a response, or to report that scanning should continue. Possible status types are as follows:
NONE |
CONNECT |
RESERVED 1 |
BUSY |
RESERVED 2 |
NO_ANSWER |
RESERVED 3 |
NO_CARRIER |
RESERVED 4 |
ERROR |
RESERVED 5 |
NO_DIALTONE |
OK |
VOICE |
RING |
UNKNOWN |
RRING |
|
The rate meaning tells modem control what the current line data rate is in bits per second. For most modems that implement negotiation progress messages, this rate value can be captured from the CARRIER response by using the <R> construct, as in CARRIER <R> or CONNECT <R>. This construct matches any speed response from the modem and captures that value to return it in the rate definition command.
The feature values indicate to modem control when optional connection features have been enabled on the current connection. Information about which features are enabled or disabled is made available to applications. Applications can use this information to determine whether they must independently perform error control or data compression for a connection. The features are as follows:.
NONE |
V.42BIS |
ERROR_CONTROL |
UNBALANCED |
MNP5 |
SYNCHRONOUS |
The match chaining directs modem control to continue matching using the remainder of the input string (after the initially matched portion) and using a different modem response string. This permits the multistage matching that is so useful with complex sets of responses, such as negotiation progress messages. The following example illustrates this approach:
RESPONSE = "PROTOCOL"RESPONSES STRING 1 = "ERROR-CONTROL" Input from modem: "PROTOCOL: ERROR-CONTROL/LAP-B"
The first string is part of the first stage matching string formed from all the RESPONSES keyword strings. Modem control interprets it to mean that the response beginning with PROTOCOL is not a final response; rather, that additional matching must be performed using RESPONSES STRING 1.
Modem control begins checking the remainder of the input string repeatedly against the RESPONSES STRING 1 match strings. Each time the match strings are used up, modem control advances to the next character in the input string and tries again. This process continues until all the characters in the input string have been exhausted. In this manner, modem control finds the ERROR-CONTROL substring and notes that feature one, ERROR CONTROL, is enabled for this connection.