Subject: [SIP] DTMF and Universal Key Input

From: "Skip Cave" <[email-masked]>
Date: Sat, 05 Aug 2000 02:41:01 -0500

There is much point-missing going on here.

There are applications that work best using speech recognition for
user input & control. There are applications that work best with
facial gestures as user input. There are applications that work best
with smell recognition as user input (baby monitoring?). There are
applications that work best with key input. 

DTMF has NOTHING to do with this issue. Just because a device has keys
on it doesn't mean it is a DTMF device. For example - SIP terminals
and personal computers have keys, but they don't generate DTMF.

I expect small portable devices with a tiny screen, a few buttons, and
an audio interface will become one of the most popular devices for
personal communications in the future (if they haven't already). These
devices won't use DTMF in the long run. These devices will certainly
have voice recognition. However, many automation applications will
want to use the buttons on the user's portable device for user input
to the application, just as other applications will want to use a
voice interface. 

There are many reasons why an application provider would select key
input as the preferred application interface method. Key input makes
it easier for the user to keep input private in a crowded room than
spoken commands (or facial gestures). Most users feel more comfortable
entering passwords and account balances using keys on their WinCE pad
or SIP portable phone rather than speaking into it. Imagine the CEO on
his cell phone telling his automated broker: "Sell all my stock" in
the lunch room at noon.

Buttons can be language-independent. Arabic numerals are common to
virtually all languages. Pressing the '1' button is exactly the same
act in all languages. Saying 'one' or 'balance' is a different act in
just about every language. No doubt, mechanisms can be provided to
normalize spoken utterances to a common form, but this will certainly
be at a great increase in complexity, a significant increase in error
rate, and at a much higher cost. No doubt there are applications that
will accept this cost, but many will not.

I will venture to predict that, while speech and facial gesture
recognition will eventually become mainstream technologies (and speech
reco is almost there), they will NEVER (at least not in this
millenium) come close to being as cheap to implement as a keystroke
recognition algorithm. Vendors that need a low cost, reliable, input
mechanism for their simple applications will choose key input every
time. Even 50 years from now. 

Simplicity, universality, privacy, cost. These should be enough to put
to bed the issue about "in 5 years everything will be speech
recognition (or facial gestures recognition, or smell recognition)".
Key input is a fundamental input mechanism. Button-pressing as a user
input mechanism is not going to go away next year or in the next
several decades (until we get a direct brain interface - dream
recognition maybe?). Even then, cost constraints and ease-of-use will
mandate key input devices for many applications.

What WILL eventually go away is DTMF. At some point, when the last
loop-start analog line has bitten the dust, the requirement for
audio-based end-to-end signaling will end. Key input will live on, but
not with DTMF. The requirement for an end-to-end signaling mechanism
with keys for input will live on, but not with DTMF.

Users will still want to find out if they are overdrawn in their
e-money account using their new fusion-powered portable communications
device (PCD) while waiting in line for tickets at the spaceport. The
application will validate their ID by requesting that they press their
thumbprint on the device keypad sensor. The user will be asked to
indicate their requirements by pressing one of the 12 labeled
flexi-keys (dynamic visual key labels) on the keypad. Key selections
will also be presented by voice prompts into their wireless invisible
earpiece (well, not really invisible, just teeney). This is still key
input. Just 21st-century style.

Keys, Words, Nods, Gestures. All user input. All appropriate for
certain applications. 

Kevin Davis explains the issue quite well in his post:
http://lists.bell-labs.com/pipermail/sip/2000q3/001467.html

On the other hand there seem to be several dissenting views:
>User input is just a subset of DTMF (minus loudness). 
>Hopefully, both will disappear over time, as user 
>devices have richer input capability. We don't want 
>to redo telnet/rlogin or X11 in SIP. 
> Henning Schulzrinne
Full Post: http://lists.bell-labs.com/pipermail/sip/2000q3/001933.html
 
>If users are still sending alphanumeric data using DTMF in 2020 then
we all
>(communications industry) ought to admit that we failed and shoot
ourselves.
>Mark Peck 
Full Post: http://lists.bell-labs.com/pipermail/sip/2000q3/001483.html

>the next release of the "media server" in the above picture is
>likely to use voice recognition, not DTMF"
>Christian Huitema
Full Post: http://lists.bell-labs.com/pipermail/sip/2000q3/001448.html

I'm afraid I will have to respectfully disagree with Henning
Schulzrinne, Christian Huitema, and Mark Peck in their dismissal of
key input as a short-lived or somehow inferior user interface
mechanism, compaired to speech input.

There is nothing inherently better or worse about speech, or key
manipulation, or facial gestures, as a mechanism for communication.
The application providers will make the decision about appropriate
communications modes, thank you, not the protocol designer. The
protocol designer's job is to enable ALL of these methods of
communication for the application designer, not to dictate one, either
by fiat or performance bias. A protocol suite should provide several
protocol choices that are applicable each to a general class of
communications (ie TCP & UDP), and every reasonable communication mode
should fit snugly and efficiently into one of the protocol choices. 

Regardless of its somewhat illegitimate birth (see my talk on DTMF key
input given at the 48th IETF), the paragigm of end-to-end key input
that exists in the PSTN today is probably THE major factor in the
expansion of ubiquitous automated services in the network. Without
"press one for sales", the world economy would have millions more live
'operators' answering phones and reading rote answers off of computer
screens, and millions fewer productive and innovative workers. That
single error by Ma Bell back in the 70s may have done as much to raise
the efficiency of the economy as the invention of the computer.
Millions of applications, from bill payment to air conditioning
control, use the keypad and speaker of the ubiquitous PSTN terminal
device to provide a simple, universal remote control UI.

So now, how do we make sure that we maintain this wonderful end-to-end
communications mechanism for the future? Loop-start lines will go
away, and so will DTMF. But we still need and want that key press that
travels all the way across the network, from terminal to terminal, be
it packet or circuit. It is time to design the next-generation key
input transport protocol, and DTMF ain't it! Hopefully, we can do
better than the Telco 'mistake' this time around. "Gosh, Toto, we
aren't in Toneland anymore!" 

Enough for now. My flight is about to arrive at D/FW airport & I am
anxious to get home. We need to examine the various proposals for key
transport in light of the above discussion. 

Subscribe/Notify?   Info Method?    RTP?   Which should it be? 
Remember, the day is arriving quickly where most devices won't
generate tones upon keypress anymore. Should you burden the future
with the past? Or make sure you can leave the past behind?

Skip's Fractured Fable
To the designer who has just created a functional and elegant wrench,
everything looks like a bolt or nut. That designer will also tell you
that his wrench is really almost as good as a hammer for driving
nails, and that nails are going to be obsolete soon anyway, and bolts
& nuts are the wave of the future.......

Stay Tuned

Skip Cave
Sr. Principal Engineer 
InterVoice-Brite Inc.

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 05 Aug 2000 10:41:40 -0400

It's not that I think that key(board) input will go away, just that it
won't be 12 buttons with numbers and */#. The notion that this is in any
way tied to telephone service will go away. We'll obviously have lots of
key input. It's the web now, both forms (including speech input) and
applets, telnet/ssh/rlogin, IM, irc and maybe other mechanisms.

Why tie remote key(board) input to SIP or VoIP? If telnet (and kin) or
web-based input modalities are not good enough, we need to discuss this,
but that has nothing whatsoever to do with VoIP. SIP may or may not be
the appropriate solution there. I don't want to SUBSCRIBE to the
keyboard, I want to have an appropriate interaction with an abstract
user interface that is far richer. For simple ASCII, telnet will
probably do the trick (or the WAP "card" mode, if you like that model).

Also, RFC 2833 (first part) has nothing to do with tones. It transports
signals which may, in the current analog phone system, have a tone
representation. Analogy is the relationship of telnet and pixel
rendition.

---

From: Richard Shockey <[email-masked]>
Date: Sun, 06 Aug 2000 11:17:18 -0500

>probably do the trick (or the WAP "card" mode, if you like that model).

For what its worth I completely agree with Skip here on the use of 12d 
keypads in applications. These classes of terminals will not go away and 
will only increase in usage for several reasons particularly mobile.

1. The use of E.164 numbering to identify SIP endpoints ( aka The ENUM WG , 
since I'm co-chair I need to get a small ad in here) and E.164 numbering is 
Globally Unique.

2. As Skip rightly pointed out numbers are Linguistically Neutral 
..something the IETF is still trying to deal with in IDN.

3. Numbers are "domain less" addressing.

4. I continue to hear arguments about voice recognition taking over  but 
I've heard these arguments for 10 years now and DTMF imput for applications 
just gets bigger and bigger.

Richard Shockey
Senior Technical Industry Liaison
NeuStar Inc.
1120 Vermont Avenue N.W.
Suite 550
Washington DC. 20005
Voice 314.503.0640
Fax to EMail 815.333.1237 (Preferred for Fax)
DC Number 202.533.2811
INTERNET Mail & IFAX : [email-masked]
or   [email-masked]
http://www.neustar.com

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

---

From: Scott Petrack <[email-masked]>
Date: Sun, 6 Aug 2000 14:47:58 -0400 (EDT)

the point is not which one will take over the world. The point is that the
applications are similar in many many cases. Today the user experience is
that s/he can

press '1' or say 'yes'

Now it's just not really relevant that 99% of the people press '1' and 1%
say 'yes.' Nor is it relevant that there will be many places where one can
only press '1'. What is relevant is that the INFORMATION to be encoded and
transported is IDENTICAL, whether '1' is pressed or 'yes' is said. So from
the presentation layer down to the transport layer, it's hard to see why
we need two different methods.

I got the impression that Skip and others wanted to enable the Internet
and Internet-connected devices to offer the same key input service that
the PSTN and
PSTN devices offer today. Well, today, whether '1' is pressed or 'yes' is
said, the real-time data is transported to a remote device and gets
interpreted into a 'user input command'. 

The point of people who identify voice reco with key input is that it is a
recipe for trouble if these two end-user events get transported in two
completely different ways. If you need the keypress to be transported
along the signalling path, then you also need the "yes" to be transported
along the signaling path. And the encoding should also be as similar as
possible, since the information to be encoded and transported is similar.

In both cases the data should be encoded and transported as RTP, because
this is the only way you will get the same key input service that you have
today. It is the only way to put saying 'yes' and pressing '1' on an equal
footing, where they need to be. 

If you want to build an IVR controlled signaling point, it is no problem
at all: the first answer to the SIP INVITE points to a host that can
receive ONLY the DTMF payload type, no other. At this point, the calling
phone can receive prompts via G.xxx ordinary audio, and the calling phone
can only send DTMF back (because that's the only codec the answerer
supports). This host might well be a signalling server. It is hardly
rocket science to build an RTP stack which supports the DTMF codec only. 
After some DTMF, the session can be modified so that the call is
transferred to another host which can handle the proper audio codecs.
This is the translation into IP telephony of the service which exists
today, which as far as I understand, is the requirement. What is the
problem with this solution? Is the problem that the signaling server now
has to understand DTMF-in-RTP, this is really not a very difficult codec
to master, and surely we all prefer to have one way of doing one thing
than having two or three? In addition, I'll bet that you'll find it really
useful to be able to have multiple receivers for the DTMF, etc. all the
standard RTP services for this audio signaling.

It may well be that there is a need for some new signaling to tell a
device to go into key input mode, or to send the DTMF codecs to one place
and the ordinary audio to another, or something. But these needs have
nothing to do with the encoding or transport of the information, it seems
to me.

Scott Petrack
http://800.edial.com/[email-masked]