Home | ARONTS | ARONTS Instruction Manual |

What are some examples of Dialing Registers used for test calls?

1. RTS redialing 1 + 10 digits with absolute comparison

2. RTS redialing 1 + 10 digits without comparison

3. RTS redialing with access codes

4. RTS credit card call

5. RTS redialing with access codes requiring secondary dialtone

6. Measure the time it takes for the Central Office to return local dialtone

7. Generate test calls of specific durations in order to perform billing verification.

8. Measuring the response time for voice response systems.

9. ARONTS reprogramming RTS-1 and RTS-2 Test and Program codes.

10. ARONTS making RTS-2 level measurements.

11. Retrieving RTS-2 firmware versions.

12. Retrieving RTS-2 unit ID numbers.

1. RTS redialing 1 + 10 digits with absolute comparison:

Spaces in the Dialing Register have no effect and are used merely to aid understanding. The Q at the start of the Dialing Register pauses one quarter second. The sequence 32 1n* # commands the RTS to slow DTMF redial whatever is between the 32 and the #. In this example, these digits are specified as 1n*; the 1 means literally dial DTMF digit 1; n* means dial all digits of the Test Number (which is assumed in this case to be a ten digit number). After receiving this command from ARONTS, the RTS takes line 2 off-hook (from the 32 command), waits for loop current, waits for dialtone, and redials the specified 11 DTMF digits at a rate of 5 digits per second. The redialing takes 2.2 seconds, plus one or two seconds to receive dialtone, so this process requires about four or five seconds.

The next Dialing Register sequence, WC10 1n* E, causes ARONTS to listen for the RTS redialing the requested number. WC10 causes ARONTS to listen up to ten seconds for whatever code precedes the ending E. In this case, the code is 1n*, which is the same DTMF digit 1 plus the ten DTMF digit Test Number. The same digit stream must be specified between the WC10 and the E as between the preceding 32 and the #. The first sequence instructs the RTS what it should dial, and the second tells ARONTS what it should wait for the RTS to redial.

The purpose of using the WC command in this example is to make certain that the specified test call is properly dialed before the result of the test call is counted as valid. Once the Dialing Register successfully goes past this point, ARONTS has verified that the requested test call has actually been placed at the remote site. Therefore, whatever happens subsequently is a real success or failure of the network under test. If the WC code fails, ARONTS will retry the test call. If the network quality between ARONTS and the RTS is such that dropouts occur, it is possible that the RTS will properly and accurately redial the DTMF digits, but ARONTS does not hear the process perfectly; perhaps a dropout occurs which causes a missed digit, or breaks a single digit into two; so the result is that the test call is ignored and repeated unnecessarily. On the other hand, if a network dropout occurs while ARONTS is sending the 32 command, it is possible for the RTS to receive an incorrect digit stream, and perfectly redial a wrong number. However, the WC command will fail and the test repeated.

WB is always used to clear the results field. W*4560 is used in this example to have ARONTS look for the 1004 Hz milliwatt tone, while also detecting busy signals, DTMF splashback, etc. The 45 specifies how to handle any received DTMF splashback signals, which are rare. Here the 4 indicates that a maximum of four DTMF digits is expected; the 5 specifies a five second timeout after at least one DTMF digit is received in case four are not sent. The ending 60 causes ARONTS to wait up to 60 seconds to determine the call disposition. In most cases, the RTS has already been issued a shorter timeout setting, so that this ARONTS timeout should not occur.

The subsequent WQ30 sequence instructs ARONTS to wait up to 30 seconds for the milliwatt signal to drop (wait for quiet). As soon as it does, ARONTS sends DTMF digits ####. Only three #'s are required to command the RTS to exit the test call; however, sending a fourth makes it more certain that the RTS receives the call knockdown code. Sending more than four will cause an RTS error and should not be used.

The final WE03 W0 is used to end the Test Dialing Register. If the RTS successfully exits the test call as a result of the previous ####, the register exists gracefully from the WE03 command (wait for exit up to 3 seconds). If the RTS does not detect the ####, the register forcibly exits via the W0 sequence, which causes ARONTS to go into recapture control mode. This is invisible to the user, except that log code 112 may be inserted into the log file. This has no significant meaning relative to the network under test.

The Dialing Register should be marked with Outline 12 indicating that the test call is being placed on RTS line number 2 on module 1. The 2 matches the 2 in the 32 command. Should 33 be used to place the test call on RTS line number 3, then the Outline must be set to 13 correspondingly.

The Expect field must be set to Milliwatt to match the W* command used in the Dialing Register. The Continue with field must be set to No, as this is the entire Dialing Register. The Call Code field is optional.

2. RTS redialing 1 + 10 digits without comparison:

This example is identical to the preceding example except that ARONTS does not listen to the RTS redial the test call to verify accuracy. A trick is used here. The RTS is commanded to send the same 1 + ten digits, but to send an additional DTMF fourth column digit A afterwards. In many cases, the Telco's Central Office ignores this extra digit. If it does not, this method cannot be used. The WC command is used, but only to wait to hear the single DTMF digit A. So as soon as the RTS finishes redialing the Test Number, ARONTS proceeds in the Dialing Register. This is the method shown in section 7.3.3 of the ARONTS manual. This simplifies and shortens the Dialing Registers, but should only be used if the network quality between ARONTS and the RTS is high.

3. RTS redialing with access codes:

This is identical to example 1, except that DTMF digits 1010288 are inserted into the 32 RTS redial command and the WC comparison command. In this case, the domestic calls are forced over the AT&T network. Whatever the dial plan digits are, they must be placed identically in both places. This method is used for 011 international calls as well.

4. RTS credit card call:

This is similar to example 1 except for the following: The RTS is redialing 0 + the Test Number, so 0n* is placed in the 32 redial command and the WC comparison sequence. After the redialing is complete, ARONTS uses the WT302222102 energy detect sequence to detect a bong tone or a voice prompt requesting a credit or calling card number. In this case, up to 30 seconds is permitted before timing out. Each S pauses one second to make sure the Telco is ready to receive the credit card number. The c0 denotes that credit card number 0 should be sent in DTMF. This is entered under system setup. It should be noted that ARONTS itself is transmitting this DTMF data through the entire network; the RTS is not regenerating it. The MS04 sequence pauses four seconds (SSSS accomplishes the same thing). This must be adjusted to match the carrier's "Thank you" or other advertisement message sent after receipt of the credit card information. Without a proper delay, ARONTS may detect voice in the subsequent W* command and end the test call.

5. RTS redialing with access codes requiring secondary dialtone:

In this example, ARONTS commands the RTS to redial the access number, which is 1-800-555-1234. A precise dialtone is expected next; W3 waits for it. If a 400 Hz ready tone is returned, W2 should be used instead of W3. If steady dial or ready tones are not returned, then either an energy detect similar to that of example 4 (with appropriate center frequency settings), or fixed delays (SS...S or MSxx) can be used instead of a W3 or W2 command. The rest of the dialing is done directly from ARONTS and is not redialed through the RTS. In this example, ARONTS DTMF dials 1 + the Test Number (1n*). The rest of the Dialing Register is identical to example 1.

The comparison command:

can be inserted in front of the W3 if desired, but it is generally unnecessary, as the W3 command will fail if dialtone is not returned. The default timeout for the W3 command is 30 seconds. If loss of a dialed digit returns local dialtone in less time than that, and the comparison sequence is not used, then there could be a problem with local dialtone being interpreted as secondary dialtone. The timeout for W3 can be altered by placing an IDW3xx command in the Module Initialization Commands:

for example, which changes it to 15 seconds. The W1 command's default precise dialtone timeout is 4 seconds (this is changed to 20 seconds in the Module Commands with IDW120). W1 requires a constant one second dialtone for detection, while W3 requires a constant three second dialtone (to make certain that ringback tone does not cause false detection).

If there is any difficulty with reception of DTMF digits end-to-end, it may be desirable to slow down the ARONTS dialing:

P10 slows ARONTS' DTMF dialing to 5 digits per second (100 milliseconds on and off times). P05 restores it back to the standard 10 digits per second (50 milliseconds on and off times).

With international calls and poor quality Central Offices, this type of end-to-end dialing can be problematic. If the above 5 digit per second DTMF dialing does not provide satisfactory operation, the following portion should be tried:

This method can only be used with Tone Controllers equipped with version 6 firmware. The P25 causes very slow DTMF dialing at two digits per second. PT1612 increases ARONTS' DTMF output levels to -1 dBm for the low tone and +1 dBm for the high tone. P* restores the output levels, and P05 returns to normal speed DTMF dialing.

6. Measure the time it takes for the Central Office to return local dialtone:

In this example, ARONTS commands the RTS to take line 2 off-hook with the 12 command. A precise dialtone (consisting of 350 Hz + 440 Hz) is detected with WT995141B10, which provides a timeout value of 99 seconds; looks for the presence of two tones (B); 51 specifies 350 Hz and 41 specifies 440 Hz; and the tones must be present for 1.0 second (10). xxxxxxx represents a quiet termination local number. The register's Expect field is set to milliwatt. Dialtone presence in less than 99 seconds logs a successful test. The placement of MS60 in the beginning of the register delays 60 seconds prior to taking the line off-hook. This spaces out the tests to provide a sample of the CO's readiness due to posssible customer overloading.

Due to the time it takes the RTS to take the line off-hook, and the detection method programmed into the WT command, the time logged is approximately 1.9 seconds greater than the actual time. The failure log can be used to inspect these times if the log all tests option is enabled under System Setup. If the Statistics are zeroed prior to running these tests, the Analysis outputs represent the mean and standard deviations of the dialtone delay (with the above mentioned offset).

7. Generate test calls of specific durations in order to perform billing verification.

A typical dialing register used for call completion testing through the RTS-2 is:

This commands the RTS-2 to hang up the test call as soon as the milliwatt signal from the test number dialed is returned. The W* command requires the presence of the 1004 Hz tone for about 1 second. Immediately thereafter, the first three #'s disconnect the call when recognized by the RTS-2. This last process takes about 0.4 seconds. Measurements indicate that the call is in progress for a total of 1.5 seconds. Any delays placed between the W* command and the #### add to this existing fixed delay.

A typical dialing register used for billing verification testing through the RTS-2 is:

This adds the delay of QQMS56 after the milliwatt is detected prior to commanding a call disconnect. Each Q adds a quarter second, and the MS56 adds an additional 56 seconds. Adding in the existing 1.5 seconds yields a call hold time of 58 seconds.

The MSdd dialing register command delays dd seconds. The actual delay time is between (dd) and (dd - 1) seconds. Therefore, the above nominal 58 second dialing register produces a call hold time between 57 and 58 seconds. A representative test call with the above dialing register was measured with a call hold time of 57.22 seconds.

Concatenating additional MS delay commands together in order to exceed 99 second delays do not produce additional imprecision. For example, MS58 MS60 together will cause a delay between 117 and 118 seconds. If another command which requires more than one second to execute is placed between them, an additional imprecision of up to one second results.

The S command produces a delay between 1.0 and 1.1 seconds. The Q command produces a delay between 0.24 and 0.25 seconds. The MDdd command produces a delay between (dd) and (dd - 1) milliseconds.

Milliwatt numbers may be used for billing verification test calls with the RTS-2 as long as verification is made that the ### is properly detected to disconnect the call in the presence of the milliwatt tone. It is preferable to use quiet termination test numbers (which produce a 10-second 1004 Hz tone and then silence). This eliminates the possibility of the tone blocking reception of the ### signaling. These quiet term test numbers must be used with RTS-1's, which do not generally have the ability to accept commands while the tone is present.

A typical dialing register used to place fixed duration calls charged to a calling or credit card is:

See RTS credit card call example above for explanation of the center portion of this dialing register. In the example above, a # is placed after the c0 command; this sends the DTMF "#" digit after the credit card number entry to speed up call acceptance. Additionally, P10 and P05 surround the c0# credit card number to slow its dialing down to 5 DTMF digits per second, as in some cases the CO's have been found to be lacking in the reception at 10 digits per second. Many carriers insert a "Thank you" message after call acceptance prior to connecting the call. In this case, in order to commence timing the call, it is necessary to correctly detect the initial milliwatt tone and ignore the welcome message. Use of the W* detection command may cause the voice to be detected instead of the milliwatt; therefore, the above register uses another WT command which is programmed to detect a 1004 Hz tone; it ignores the preceding voice signal. The trailing WT parameter requires the presence of the tone for 1.2 seconds. Measurements have shown that this matches the detection time for the W* command. So the timing discussion above for non calling card calls applies to this dialing register as well. This example produces a call hold time of 60 seconds (59-60).

Tone Controllers equipped with firmware version 6.1 or later have the additional dialing register command MPsss available. The parameter sss can take the values of 000-999 (three digits required). This command produces a delay of sss seconds, precisely. This command should be used to generate test calls for billing verification instead of the MSdd command (which has 1 second of imprecision).

A typical dialing register used for billing verification testing with 1+10 digit dialing is therefore:

This produces a call hold time of 60 seconds (1.5 from W* and ###, 0.5 from QQ, and 58 from MP) and is repeatable without timing variability.

A typical dialing register used to place a 60 second call charged to a calling or credit card is therefore:

8. Measuring the response time for voice response systems.

By using the same dialing register as example #1:

The expect field is set to Milliwatt as usual. If the system under test returns a voice prompt, then the expected result is log code 121 (Voice). The delay time is also given; however, the voice detect circuitry in the W* command requires a varying number of seconds to qualify it as voice. Using this register will show all of the possible results (such as busy, reorder, SIT, DTMF, etc.), but the delay time is not particularly accurate, because the voice detection time depends upon the actual individual voice recording.

To obtain an accurate measurement of the voice prompt response time, the following dialing register can be used:

In order to use this register, the system under test must not provide ringback tone prior to producing the voice prompt. This dialing register uses WT to detect the voice response instead of W*. The above parameters specify a timeout of 99 seconds; look for energy around 400 Hz (45) from filter number 1 (50 sets the second filter frequency and is irrelevant because of the following 1 which specifies to use only the first filter) which lasts for 0.2 seconds (02 at the end). The voice is normally detected within one second, giving more accurate delay time measurements than the W* method. However, this register (which should have its Expect field set to Milliwatt) will only return a log code of 100 (successful, or passed) for energy received (with the appropriate delay time), or 127 for a timeout (energy not detected within the specified 99 seconds). For this dialing register, the RTS internal call timeout should either be disabled, or set longer than the WT timeout setting.

It is recommended that tests with both the W* and WT methods be made to verify voice response systems; if the W* tests reveal the calls are mostly the expected voice response, then the delay values found from the WT tests can be used for greater accuracy.

9. ARONTS reprogramming RTS-1 and RTS-2 Test and Program codes.

This is discussed on page 46 of the manual (7.3.3). The Program code shown on the Site Information screen must be correct -- if not, update it. First, change the #t* in the Access register to #p*. The Access register is generally 1-3, but is specified on the Site Information screen. A typical access register then would be:

Create a new test register to change the Test code (to 8732 in this example):