Making voice applications available to TDD users

TDD voice segments and prompts

To make a voice application available to TDD users, you have to add a new language to Blueworx Voice Response. The only TDD language supplied is “U.S. English TDD”. If you want to support TDD users in other languages, you can define other TDD languages. A TDD language is a voice-only language, containing only voice segments, prompts, and voice tables. It does not contain any window text.

Voice segments? Yes, the signals that are transmitted along the voice channel to the caller are stored in exactly the same way as ordinary voice segments. They can be generated automatically from the text descriptions of the default (spoken) voice segments in a custom server using CA_Get_Segment_Info() and CA_TTD_Create-Segment(). This uses the same mechanism as that used for converting text to speech, but TDD characters are generated instead of spoken words. Voice segments are played to the caller using the PlayPrompt action, just as spoken voice segments are.

To add a TDD language to the system, see the Blueworx Voice Response for AIX: Configuring the System information.

The prompts need to be tailored for usability with a TDD. For example, whereas a state table might usually speak “one thousand three hundred and ninety-two dollars”, it would be more appropriate for a TDD user to see “$1,392”. The supplied U.S. English TDD language database includes system prompts tailored in this way

To create tailored versions of prompts, you must create language-specific prompts, in the same way as you would for any other language, as described in the Blueworx Voice Response for AIX: Application Development using State Tables reference manual.

TDD custom server subroutines

There is a set of custom server subroutines for use in applications that work with TDDs:

• CA_TDD_Create_Segment() works like CA_Create_Segment(), but the segment is created from an ASCII text string you supply, instead of from digitized voice data.
• CA_TDD_Play_String() works like CA_Play_Voice_Stream(), taking an ASCII string and playing it as TDD characters directly on a voice channel.
• CA_TDD_Get_String() works like CA_Record_Voice_Stream(), decoding the input signal and returning an ASCII string.

These subroutines are included in the library /usr/lpp/dirTalk/sw/lib/libtdd.a. To use these subroutines, you must explicitly link in the libtdd.a library in the following way:

1. Open the Properties window of the custom server that uses the TDD subroutines.
2. In the Object Libraries pane, add the following entry:

   ${VAE}/sw/lib/libtdd.a

   This puts the libtdd.a reference in the custom server makefile.

For detailed information about the subroutines, see the Custom Servers manual.

There is a sample TDD custom server application that shows you how to use the subroutines. The sample is called TDD_sample; it is supplied as an import file, TDDSample.imp in the samples directory /usr/lpp/dirTalk/sw/samples, and must be imported as described in Importing application objects. The sample application uses a shell script, TDD_talk, which is also supplied.

You can make many of your voice applications enabled for TDD users, but the TDD technology imposes some restrictions :

• TDD segments are stored in uncompressed format, because the data would not meet TDD specifications after compression and decompression. So there is no support for voice messages, audio names, or user greetings.
  Note: When playing TDD segments or using a custom server to receive TDD input ensure that you set the System : Voice Compression Type system variable (SV50) to 1, and the System : PlayPrompt Compression Type system variable (SV182) to 0.
• In addition, uncompressed segments are sensitive to the voice encoding scheme used on the trunk interface. The supplied U.S. English TDD segments are only suitable for T1 trunk interfaces. If you create your own segments using CA_TDD_Create_Segment(), the appropriate encoding, for E1 or T1, is automatically selected.
• A TDD cannot generate DTMF tones. You need to adapt your existing DTMF-based applications to accept TDD strings as input from the caller.

Valid TDD characters

A TDD has a limited character set consisting of:

Lowercase alphabetic characters are automatically folded to uppercase.

Your application must send only valid characters to a TDD. The TDD also supports the following control codes :

It is recommended that your application inserts a <CR><LF> sequence after at most 68 printable characters, to help the TDD printer to display the messages properly.