Question about TDD/Baudot/Deaf


I see that Asterisk has a mode setting for Telecommunications Device for the Deaf (TDD), which uses the 5-bit Baudot protocol (see EIA/TIA-825 for specs) to allow text communication.

However, I can’t see any info on using this capability in the docs or in this forum. Does anyone have experience with this? Is there a character recognition and generation engine somewhere in Asterisk? Is it dependent on certain hardware? I see filenames with ‘tdd’ and ‘baudot’, but I’m not geeky enough to understand how they work.

One issue with VoIP is that the standard codecs can degrade TDD performance, causing lost or incorrect characters. This issue has been at the core of several disputes about accessibility laws and regulations, in the US at least. I’d like to see Asterisk avoid this problem, both technically, and more to the point, in how it is documented. Sysadmins need to know how to provide TDD service when needed.

Thanks for any pointers!


Wow! Baudot - the old telex protocol, i haven’t heard that referred to for nearly 20 years! I’m amazed it’s still in use. Back in the early 80s i used to know Baudot so well that i could read telex tape (5-level punched paper tape)…

I didn’t even realise Asterisk had TTY/TDD capability, but i’ve just had a quick search through the voip-info wiki - without becoming very much more enlightened.

The zap channel apparently has TTY/TDD support - using the TDD mode AGI command ( ). This AGI command appears to be hardly documented at all though.

There’s no indication of what TTY/TDD support does, or why it’s even necessary - as it only works with zap channels (i.e., POTS phone lines) - however, there is some vague implication that it may be possible to connect a TDD to an Asterisk zap channel and send the message via a SIP channel. Although whether this message would be sent as a text message over a SIP channel or as modem tones, i couldn’t guess.

However, looking at the code in tdd.c, it appears to have the ability to decode Baudot. What it does with it then, though, i can’t tell - i’m not a C programmer, but maybe someone else can help with that.

As far as codecs go, the issues would be the same as faxes and modems. I can’t remember what speed the original telexes worked at, although it was quite likely 300 baud, but i’d imagine (hope) that modern ones would work a bit faster than that - probably at least 14.4kbps.

They ought to work ok with the g711 codec, but you can’t expect them to work properly with any of the compressed codecs (e.g., g729, gsm). They would also be susceptible to packet loss - possibly even losing characters. But how much they would be affected by packet loss would depend on a) the speed of the communications device (modem) and b) the quality of the network connection.

Being only a 5-bit character code - Baudot has a much more limited number of possible characters that can be represented than ASCII does. To overcome this limitation, it uses two characters as “shift” codes to nearly double the number of characters that can be encoded. All characters after a figure shift are interpreted as digits or punctuation-type characters and all characters after a letter shift are interpreted as letters.

So, of course, with Baudot, the loss of one single character could render the rest of the message quite unintelligible - if a figure shift or a letter shift character gets lost and the person receiving it doesn’t understand how the letters and the figures correspond. This would make the effect of line quality on intelligibility much more of an issue with TDD than with fax, i guess.

This issue had never occurred to me before, but it’s an extremely interesting and important issue - on a par with the ability of VOIP to deal with calls to emergency numbers, or possibly more so, as it is potentially harder to deal with. It’s crucial that the current movement of telephony to VOIP doesn’t disadvantage deaf people.

It ought to be relatively simple for it to improve matters for deaf people, but there’s obviously a lot of work to be done for that to happen. I’d be happy to make any small contribution to this that it’s within my capabilities to make. Finding people that have even heard of Baudot wouldn’t be that easy in this field, i’d imagine!

I’m amazed to find myself thinking in terms of Baudot over SIP - i thought i’d seen the last of Baudot 20 years ago! :wink:


Well, doing a bit of research into this subject, it seems that TDDs operate at 45.5 baud in the US and 50 baud in some other countries (typical!), but ITU standard V.18 encompasses both of those speeds as well as a few other systems.

My gut feeling is that speeds as low as 50 baud (50bps) should sample well and shouldn’t have much problem being transmitted over VOIP - even with a compressed codec. However, i don’t know how the modulation/demodulation operates, so i could be way off the mark there.

One thing that i notice, looking at tdd.c in the Asterisk source code, is that it only appears to support 45.5 baud. This means it may not work outside of the US. Although if all TDDs use V.18, maybe that’s not an issue as they should all be capable of 45.5 baud anyway.


Hi Will,

Yes, you’ve got it right about Baudot in North America (45.45) and UK/Australia (50). There are non-Baudot protocols for text telephones in other countries, including DTMF in Denmark. I think there is a gateway in the UK that sorts some of these out.

Unfortunately v.18 exists as a hollow standard. I’m not aware of any actual devices that include it; it’s a really complicated form of negotiation that is too demanding of both hardware and software, plus it was thought to have too tiny a potential market.

I wonder if anyone else will chime in. I saw someone named SaraHemm mentioned in, and I sent her email a few days ago.

Losing characters in G.729 has been reported, and as you say, frame errors and losing track of whether you’re in FIGS or LTRS mode can be fatal. The EIA/TIA 825 spec calls for sending the mode character every 72 characters just in case, but the damage may be done already. For VoIP purposes the general advice is to have users set their defaults to G.711, which works well enough. (BTW, the benchmark character error rate is supposed to be 1% or less.)

This issue cropped up in wireless, and required lots of FCC intervention. In the US some of the handsets have TDD modes: you can attach a TDD to your wireless phone. Characters get sent as codes, not as FSK. This means that carriers have to know that you’re in TDD mode so they know what to forward when they receive the codes. Nobody’s very happy with this, of course, and everyone prays for these users to migrate to more mainstream text services.

So just to repeat for the benefit of anyone who’s lost the original purpose of my post, I’m looking for anyone with experience actually placing or receiving TDD calls through Asterisk.