Appendix
B – TTY Abbreviations
Overview
TTY Angel is a tool that translates text into WAV files that can be played to TTY/TDD phone devices. It’s designed for being able to quickly generate audio text applications for TTY/TDD users and also has a “batch mode” which can be used for generating thousands of individual prompts quickly and easily to provide a “TTY Language” for voice mail systems, IVR applications and other telephony applications.
Shown here is the basic interface that allows you to simply type in any text you want and convert it into a WAV file selected. Notice that the text entered is “translated” into a short hand that is commonly understood by users of TTY/TDD phone devices. See the “Translation Dictionary” section below for more on this optional feature.
TTY Angel also supports a batch mode for generating large numbers of prompts used for making telephone conversations. See the “Batch Mode” section below for more on that.
Requirements/Special Notes
TTY Angel cannot be run over a WTS connection. Since it interacts with the WAV driver to get it’s job done and WTS does not like applications doing this remotely, TTY Angel will not allow itself to run if it detects it’s launched from over a WTS connection.
TTY Angel is not specific to any Unity version or the like. It generates WAV files that can be understood by TTY phone devices and can do this in “batch” for CSV files. You can, of course, run TTY Angle on or off the Unity server.
TTY Angel will produce WAV files that can be played back an
“understood” by any device compatible with the Baudot
protocol. This is the standard
protocol used by all TTY/TDD phone devices in
While some TTY/TDD phone devices support the newer ASCII protocol at 110 or 300 baud speeds, TTY Angel does not support this since these are two way modem protocols that cannot transmit using simple asynchronous WAV file transmissions. See the “A Brief TTY Primer” for more details on that.
I have tested the TTY Angel output against several TTY/TTD phones and software packages that use standard PC modems to emulate TTY/TDD phone devices and found it to work well with all equipment. One thing to note, however, is that some phones treat the # (pound) and ‘ (single quote) characters differently and map them to different values. I have used the most up to date specifications I could find and tested it against the latest Ultratec phones to verify the output from TTY Angel is accurate. If you find yourself needing to produce output for a phone device that maps the # and ‘ characters differently you can use the translation dictionary to “swap” the characters as necessary. See the “Translation Dictionary” section below for more on that.
Using TTY Angel
One-Off Mode
The most common way to use TTY Angel is to simply select a WAV file path for output and type in text you want translated and have the output saved to the designated WAV file. This what’s shown in the overview screen shot above. The resulting WAV file is also copied to the clipboard in addition to being stored in the file designed on the form. Typically you paste these WAV files into the voice mail or IVR application in a method provided by the manufacturer. In the case of Unity this is done via the SA web interface using the media master control using the “Paste” (for the clipboard) or “Paste from file…” (to use a file on the hard drive) options in the drop down control on the left as shown here:
You can use this mechanism for constructing audio text applications, providing greetings and generating voice names for TTY/TDD users and the like. Of course it’s also possible to simply use TRAP (telephone record and playback) and call a TTY/TDD phone device and just record the tone output while typing, however this is much more time consuming and error prone than using the TTY Angel application. Further, all files constructed by TTY angle start with a transition into LTRS or FIGS mode which can help solve problems caused by inserting these greetings in between other prompts which may leave the device in the “wrong” mode before playing the prompt. When recording from the phone and you just type letters in, for instance, the phone will not issue a LTRS transition and if the last prompt to play before the WAV file you construct with the phone is played is in FIGS mode, the resulting output will look like garbage characters to the receiver.
Batch Mode
Import from CSV
The CSV import function is very simple. It reads in a flat text file and expects to see two columns of information separated by a comma. The first column should be the WAV file name and path and the second column should be the text of the prompt to construct. If the text of the prompt contains commas, it should be bounded with quotes. There is no “first line header” on the CSV file, it requires the information to be presented in that order.
To be considered valid the text file must have a first line that reads “FILE, TEXT” in that order. If the file selected does not contain this first line it wont be considered a legal file to import from and will be rejected.
The prompt name can be a fully qualified path or just a WAV file name in which case it will be saved out to the directory you are currently running TTY Angel from. If the file name already exists, it will be overwritten without asking. Be careful.
Here’s an example of valid input:
FILE, TEXT
C:\MyPrompts\Prompt007.wav, Press 1 for more options
C:\MyPrompts\Prompt008.wav, “For more options,
press 7”
Prompt9.wav,”There is no limit to the number
of characters you can enter in a text field, however do not include returns or
line feeds.”
These lines, on the other hand, will be rejected:
FILE, TEXT
C:\myprompts\prompt10.wav, This text, has a comma
but no quotes around it
C:\myPrompts\Prompt10.wav this text has no comma
separating the wav file name and the prompt text
C:\myprompts\prompt11.wav, “This text has a line
feed
In the middle of it which will cause a problem with
the parser”
All rejected lines will be written out to the log file generated and a total count of all lines processed and how many were successful is presented when the CSV parse is done. Review the log file and search for the string (error) to find problems in the CSV processing.
NOTE: If you want the dictionary
replacement function to be active for your CSV text, you must first select
“File | Apply Dictionary Translation To Input Text” on the main TTY
Angel form before opening the “Import from CSV” form. By default the dictionary translation is
on. See below for more on the
dictionary function.
Constructing an Alphabet
The TTY Angel application ships with a default set of 60 WAV
files that represent all the characters that the Baudot protocol supports. These WAV files are appended together to
form the resulting WAV file for the desired phrase. Since the Baudot protocol is a 5 bit
standard which only supports 32 characters it has to “shift” into
“letters” and “figure” modes as necessary to generate
the 60 characters in the full set.
The set of WAV files that ships with the tool by default are recorded at
the standard 45.45 baud used in most of
To do this, select “File | Construct Alphabet”. You’ll see this dialog:
Select the desired baud rate and hit the “Create Alphabet” button. This will replace all the WAV files used to construct phrases with ones that generate tones at the desired speed. All phrases generated by TTY Angel will be done at this rate until you construct the alphabet again with a different speed.
Translation Dictionary
Users of TTY/TDD phones typically use a kind of “short hand” language to reduce the number of characters that need to be transmitted as such slow speeds. Most folks can easily type and read much faster than 45.45 baud, for instance, so the need to keep things brief is acute. TTY Angle include a simple dictionary function that lets you do string match and replacement so you can “shorted up” preconstructed prompt text easily. It also allows you to add silence and skip prompts entirely if necessary.
TTY Angel uses two files to act as it’s replacement mechanism. The Dictionary.TXT file contains phrases or words that need to be replaced. The logic for this file is such that it will not do “partial” word replacements. So for instance if you want “phone” to be replaced with “phn” it will not replace “telephone” with “telephn”. It will only do “whole word” or phrase replacement. The ReplaceChar.TXT file, on the other hand, will replace ANY instance of a string you ask it to no matter where it appears in the text. This is normally used for trimming spaces out, removing periods, commas and other punctuation and the like. It should be used sparingly and with caution.
Dictionary.TXT
This is the main translation mechanism that does whole word replacements within the text being converted in to TTY tone. The dictionary itself is simply a flat text file called “Dictionary.txt” found in the installation directory for TTY Angel. If you select “File | Edit Dictionary” it will pop open Notepad with this file loaded. TTY Angel ships with a short Dictionary file that includes some of the more commonly used substitutions, however you can add as many additional items to the dictionary as you like. It also includes special replacement strings specific to the Unity prompt set translations that wont conflict with other things you may be using TTY Angel for.
NOTE: After editing the dictionary text file you need to select “File | Reload Dictionary” for the new values to be used.
When text is processed through the dictionary, it is simply doing a search for the target string from the dictionary and if it’s found, the designated action is taken. Most commonly this is to substitute the target string with the replacement string specified on to the right of the column. However there are four key words that have specialized functions:
- <silence> inserts 1 second of silence at the end of the prompt. This key word can be repeated on the right side of the comma as many times as necessary (see the example file below). You cannot insert silence into the middle of a prompt string, however this shouldn’t be a problem since none of the Unity prompts want silence anywhere but at the end.
- <skip> means to skip the file entirely. This can be useful if you’re updating a standing set of prompts and you want to not overwrite certain files in the process.
- <remove> means to delete the text from the string and not replace it with anything, not even a space. This can be useful for screening out characters not supported by Baudot such as “$” or the like.
- <space> means to replace the string with a single space. You cannot insert more than one space into a string.
The strings must appear with the text to search for on the left and the text to replace it with or an action on the right. The two fields are separated with commas so if the text on the left or on the right contains a comma, be sure to bound the text between double quotes. The strings are not case sensitive – everything is converted to uppercase when processing since TTY/TDD output for Baudot does not include case.
Here are some valid entries in a dictionary file:
(1 second of silence), <silence>
<2 seconds of silence>, <silence><silence>
(blank), <skip>
“You may record your message
at the tone, stay on the line for more options”, “U may rec
telephone, phn
phone, phn
Answer, ans
$,<remove>
*, star
#, pound
NOTE: The dictionary file is processed from the top down so it’s a good idea to order your big string replacements first and your smaller string replacements near the end to avoid problems.
NOTE: The strings in the dictionary will only replace whole words or phrases. Strings in this file will not replace parts of a word. For instance if you have “#” set to be replaced with “pound” and the string is “press 3##2” it will not replace those # characters with “pound”. To do that you need to use the CharReplacement.txt file discussed next.
By default the dictionary replacement function is on. If you want it turned off you need to select “File | Apply Dictionary Translation to Input Text” on the main form. Once this option is checked, it’s used for ALL string replacements including the two batch modes discussed above. You can see the original text and the modified text in the progress window at the bottom of the main form. When running in batch mode, all prompt text is written to a log that is displayed at the end of the batch processing so it can be reviewed if desired.
CharReplacement.TXT
The CharReplacement.TXT file follows the same rules as the Dictionary.TXT file except that strings in this file will replace ANY instance of that string found regardless of if it’s part of a larger word or not. This file also allows you to match and replace space characters which the Dictionary.TXT will screen out. As such you need to use this file with caution. By default this file is not active, if you wish to use it you need to rename it from CharReplacement_Hold.TXT to CharReplacement.TXT. You’ll find this file in the directory where you installed TTY Angel.
Here’s the text from the default CharReplacement_Hold.txt file that is included in the TTY Angel setup:
STRING, REPLACEMENT
" "," "
" "," "
.," "
","," "
Applying this file will remove all multiple space strings and replace all periods and commas with a space. I find strings that don’t contain punctuation are much smoother since it doesn’t require the device to transition in and then back out of FIGS mode – in most cases it’s still very readable but does not contain the typical “stutter” that you get by inserting FIGS characters into the middle of a stream of LTRS characters. Some folks wouldn’t agree with that which is why be default this file is not active.
A Brief TTY Primer
I get a lot of questions from folks about how TTY Angel works, most of which center around the fact that not too many folks really know how TTY/TDD phone devices actually work or how the Baudot protocol required by Section 508 functions. If for no other reason than I spent days figuring all this all out last year and I think it’s kinda cool, we’re going to cover the ins and outs of the Baudot protocol and lay a little history on you here.
The History
The Baudot protocol was developed in the 1870s to improve the basic telegraph transmission mechanism such that it could be automated rather than having a telegraph operator decode the spaces and dashes into letters on the receiving end. The idea was simple: send a series of on/off tones (dashes and spaces) in patterns that the receiving machine could translate into known letters and print out on a small tape for the operator to read. There were a number of competing schemes at the time including one by the man who was later erroneously credited with the invention of the telephone, Alexander Graham Bell. Mr. Baudot, however, was the first to successfully develop a functioning teleprinter device and bring it to market.
Since this protocol had to work across a simple single wire system it was based on the same set of spaces and dashes used at the time. It was a 5 bit protocol meaning that each letter consisted of a combination of 5 “marks” or “spaces” sent at consistent time intervals so the receiving end could gather them in a predictable way and then print the appropriate character or letter based on a predetermined set of patterns. Whipping out your binary calculators you can quickly see that a 5 bit protocol will yield you 32 characters total which is not enough to transmit all the letters of the alphabet, numbers and various characters needed to deliver a text message. As such Baudot introduced the nifty concept of having two sets of characters: a “letters” set and a “figures” set that you switch between using a special predetermined code. In this way he expanded the character set to 64. You can check out Appendix A for a run down on the entire character set.
Due to limitations in the equipment at the time the transmission speed for Baudot’s device was set at 60 words per minute where a word is defined as 5 characters. So 300 characters could be transmitted in 60 seconds give or take. The speed varies somewhat since if you have to flip back and forth between the “letters” and “figures” set it takes time to do that which eats into your speed. At the time this was rip-your-face-off-fast compared to the existing human operated telegraph machines. This side note becomes important in a bit.
Fast forward to
1964. Robert
Weitbrecht, a deaf physicist and ham radio enthusiast, wanted to communicate with
his friend who did not have a license for a ham radio. Ham radio operators (or just
“hams” to the hipsters) use teleprinters to communicate over the
air sending the same 5 bit Baudot protocol such that text messages could be
transmitted easily. This had been
in use by the military and some private sector folks for some years and was
just being replaced by other more robust and fast transmission mechanisms
becoming available at that time. He realized that these machines, which were
becoming available in large numbers from military and telephone company
surplus, could be used by deaf people to "talk" over the phone lines
as well. He developed and patented a modem protocol which, when coupled to a
teleprinter, allowed them to do just that over existing public telephone lines. In the late 1960s AT&T started
dumping a bunch of modems capable of supporting this protocol that were
becoming obsolete. Rather than
throwing them out they were pressed into service as telephone devices for the
deaf. Literally millions of such
devices were given away to deaf users and hence was born the standard in
Fast forward again to
July of 1990 when the Americans with Disabilities Act was signed into law. It’s a common misconception to
assume the section 508 requirements stem from this act, which is not the
case. While the
This section 508 includes, among other things, requirements for telephony related products for supporting blind and deaf users. If you ever want to feel better about how efficient your meetings are, just wander through a few weeks worth of minutes from the meetings on just this one section and watch our government groan into action. The short story is they decided to stick with Weitbrecht’s 1964 adaptation of the Baudot protocol as the standard that all telephony products must conform to when providing text services for the deaf. This was largely arrived at because of the many pieces of equipment that were out there already and they didn’t want to force everyone to have to replace that equipment. As such, even though most TDD phones sold today support far more robust ASCII based protocols that transmit at much faster rates and include far more characters, they all must support the 45.45 baud asynchronous Baudot protocol adaptation.
The Protocol Today
Weithbrecht’s adaptation of the Baudot protocol such that it would work across modems on a phone line involved defining “mark” and “space” tones (called “tics”) as set frequencies and including a “start tic” and “end tics” around each character transmitted. The “mark” tic was defined as 1400 Hz and the “space” tic was defined as 1800 Hz. The leading start tic is a space and the tailing tones are, depending on who you talk to either one and one half or two mark tics. The “half tick” concept is a little goofy and most folks just roll with two full tick tones at the end there, as such each letter sent is made up of 8 distinct tones.
As noted earlier,
Buadot’s protocol transmitted at 60 words a minute which, doing some
quick math, comes out to each tic being exactly 22 milliseconds long. This equates to a transmission speed of
45.45 baud. It’s important to
note here that other adaptations of Baudot’s protocol use slightly
different transmission speeds. For
instance in
To see what this looks like,
here’s a shot of the letter “c” or the figure “:”
(colon) as it appears in Cool Edit’s nifty “spectral view”:
You can see the pattern of 8 22 millisecond tones for SPACE, SPACE, MARK, MARK, MARK, SPACE, MARK, MARK clearly here. Stripping off the leading space and trailing marks you’re left with SPACE, MARK, MARK, MARK, SPACE which translates to “01110” in binary which is 14 in decimal which, of course, maps to “C” or “:” in the Baudot letters and figures tables respectively. See Appendix A for a complete table.
To switch between the letters set to the figures character set or vice versa the sender simply sends the reserved tone for that and begins transmitting using that set. The receiver assumes all characters transmitted from that point further will be from the respective set until another “switch set” tone pattern is sent. This can present tricky problems if you want to hop into the middle of a transmission and “sniff” the tones going by since you wont know which set is being sent at the time so, in the case of the tone pattern above, you can’t tell if it’s a “c” or a “:”. This can also cause problems when appending together wav files made up of such tones since you have to be careful to take this “mode” issue into account. TTY Angel deals with this by forcing a LTRS or FIGS transition at the beginning of each WAV file it constructs regardless. Burning 176 milliseconds is worth avoiding “garbage” strings coming at you across the phone. Further, phone devices will send a FIGS or LTRS “reminder” in the middle of a transmission every 72 character at least. This normally isn’t really necessary since devices just don’t “forget” what mode they’re in all of a sudden and waiting a full 72 characters for it to correct itself would be pretty painful if they did regardless.
This is what the kids call an “asynchronous” protocol meaning that the sender transmits blindly and the receiver is responsible for picking up the tones. There’s no two way hand shake or checksum or an “I got it, go ahead” or a “I need you to send that again” convention or the like. If the receiver misses a tone or two they will get garbage until there’s a pause long enough for it to “reset”. With such a slow protocol sending big, fat 22 ms tones, though, unless the line quality is absolutely horrible it’s not very likely that the receiver will simply drop tones coming across. This is one of the reasons why the TDD acoustic couplers work so well even in the presence of a lot of ambient noise such as street sounds near a phone booth and the like. This is also why it’s possible to transmit TTY messages across radio waves without requiring any feedback from the receiving end of things.
Being a one way protocol, just about any recording and playback mechanism can be used to store and retrieve TTY messages, including answering machines. As long as the device is capable of recording the tones and playing them back faithfully it should work fine as there’s no decoding or encoding necessary here. The only gotcha in this respect is some codec compression algorithms such as G729a are optimized for human voice and the 1400 and 1800 Hz tones used for TTY are crunched a bit during the recording process and do not play back as recorded reliably. As such the Rehabilitation Act specified the use of G711 MuLaw for recording as a requirement for compliance with section 508.
Appendix A – Baudot Codes
This is a complete list of the Baudot character set used by TDD phone devices. Notice the lack of a provision for “*” or “#” here. Various TDD phone manufacturers have mapped * to value “5” and # is sometimes substituted for value 20, however there is no accepted standard for this and it varies from phone to phone. For this reason even if (when) we do have the ability to detect TTY characters in the Unity conversation we will have to make this configurable and/or map those actions to known letters in this chart and modify our conversation to ask TTD users to press those for conversation navigation.
|
Appendix B – TTY Abbreviations
TTY Angel includes a built in dictionary capability that allows users to dictate simple word or phrase replacement. This is used extensively to get the text pulled form the PROMPT.INI files to generate proper looking prompt text by replacing items that are not appropriate to TTY users. For instance phrases such as “you may record your message after the tone”, “Please say your name…” and other voice specific references are replaced when the prompts are constructed. This file is also used to replace words with abbreviations commonly used in TTY discussions. There are a number of compilations of abbreviations that can be found on the internet which we used as a starting point but ended up adding a few additional ones specific to our conversation. For instance “directory” is replaced by “dir”. If sites are not happy with our choices for abbreviations they can simply edit the text based dictionary file in TTY Angle and construct their prompt set again if they like. Hopefully this will be the exception as opposed to the rule but the option is there if necessary.