Cpanel web hosting - How to Dial a Number Using the dial
How to Dial a Number Using the dial File The dial file describes the way various dialers are used. Traditionally, UUCP talks of dialers rather than modems, because in earlier times, it was usual practice to have one (expensive) automatic dialing device serve a whole bank of modems. Today, most modems have dialing support built in, so this distinction gets a little blurred. Nevertheless, different dialers or modems may require a different configuration. You can describe each of them in the dial file. Entries in dial start with the dialer command that gives the dialer’s name. The most important entry besides dialer is the modem chat, specified by the chat command. Similar to the login chat, it consists of a sequence of strings uucico sends to the dialer and the responses it expects in return. It is commonly used to reset the modem to some known state and dial the number. The following sample dialer entry shows a typical modem chat for a Hayes-compatible modem: # NakWell modem; connect at high speed dialer nakwell # dialer name chat “” AT&F OK\r ATH1E0Q0 OK\r ATDT\T CONNECT chat-fail BUSY chat-fail ERROR chat-fail NO\sCARRIER dtr-toggle true The modem chat begins with “”, the empty expect string. uucico therefore sends the first command AT&F right away. AT&F is the Hayes command to reset the modem to factory default configuration. uucico then waits until the modem has sent OK and sends the next command, which turns off local echo and the like. After the modem returns OK again, uucico sends the dialing command ATDT. The escape sequence \T in this string is replaced with the phone number taken from the system entry sys file. uucico then waits for the modem to return the string CONNECT, which signals that a connection with the remote modem has been established successfully. Sometimes the modem fails to connect to the remote system; for instance, if the other system is talking to someone else and the line is busy. In this case, the modem returns an error message indicating the reason. Modem chats are not capable of detecting such messages; uucico continues to wait for the expected string until it times out. The UUCP log file therefore only shows a bland “timed out in chat script” instead of the specific reason. However, Taylor UUCP allows you to tell uucico about these error messages using the chat-fail command as shown above. When uucico detects a chat-fail string while executing the modem chat, it aborts the call and logs the error message in the UUCP log file. The last command in the example shown above tells UUCP to toggle the Data Terminal Ready (DTR) control line before starting the modem chat. Normally, the serial driver raises DTR when a process opens the device to tell the attached modem that someone wants to talk to it. The dtr-toggle feature then drops DTR, waits a moment, and raises it again. Many modems can be configured to react to a drop of DTR by going off-hook, entering command state, or resetting themselves.98 UUCP Over TCP Absurd as it may sound, using UUCP to transfer data over TCP is not that bad an idea, especially when transferring large amounts of data such as Usenet news. On TCP-based links, news is generally exchanged using the NNTP protocol, through which articles are requested and sent individually without compression or any other optimization. Although adequate for large sites with several concurrent newsfeeds, this technique is very unfavorable for small sites that receive their news over a relatively slow connection such as ISDN. These sites will usually want to combine the qualities of TCP with the advantages of sending news in large batches, which can be compressed and thus transferred with very low overhead. A common way to transfer these batches is to use UUCP over TCP. In sys, you would specify a system to be called via TCP like this: Some modems don’t seem to like this and occasionally hang.