Subject: [SIP] Two Keystroke Encodings

From: "Skip Cave" <[email-masked]>
Date: Tue, 05 Sep 2000 22:30:14 -0500

My last post on this subject did not get any discussion. This usually
means that 
everyone agrees, or no one understood it. Since what I was preposing
was 
fairly radical, I assume the no-response was because of my poor
description
 of the issue, and resulting incomprehension. I will try again, 
and this time I won't mix together so many issues in one post. 

Henning and Jonathan have shown generally  how RTP can be used as 
a mechanism to carry keystrokes. They have shown how the delivery 
can be made reliable. This clears several significant hurdles in the
path 
towards using RTP as a practical keystroke transport method. There
are 
only a few remaining issues. The following discussion addresses the 
next critical issue.

Colin Perkins writes:
> I suggest you read RFC 2793 which describes how to use 
> RFC 2198 redundancy as a `reliable' transport for non-audio
keystrokes.
>http://lists.bell-labs.com/pipermail/sip/2000q3/002113.html

RFC 2793 - "RTP Payload for Text Conversation" is an RFC which I had

somehow overlooked (thank you, Colin) which proposes a method to use
RTP 
to transport T.140 "text conversation" sessions. 

So, the IETF now has two different protocols to transmit exactly the
same 
data - keystrokes - over RTP:  RFC 2833, and RFC 2793. 
The primary difference between the two protocols is simply the
encoding
of the keystrokes.

RFC 2833 uses the following encoding for keys:

Event  encoding (decimal)
_________________________
0--9                0--9
*                     10
#                     11
A--D              12--15

RFC 2833 doesn't define encodings for any other keys. It seems to
assume 
that all devices will only have a maximum of 16 keys. 

RFC 2793 proposes ISO/IEC 10646-1, level 3 (Unicode) encoding to
define a 
much larger set of keys, but the 16 keys defined in RFC 2833 are
also
included in the RFC 2973 encoding:

0x0030         DIGIT ZERO
0x0031         DIGIT ONE
0x0032         DIGIT TWO
0x0033         DIGIT THREE
0x0034         DIGIT FOUR
0x0035         DIGIT FIVE
0x0036         DIGIT SIX
0x0037         DIGIT SEVEN
0x0038         DIGIT EIGHT
0x0039         DIGIT NINE
.......
0x0041         LATIN CAPITAL LETTER A
0x0042         LATIN CAPITAL LETTER B
0x0043         LATIN CAPITAL LETTER C
0x0044         LATIN CAPITAL LETTER D
.........
0x002A         ASTERISK
0x0023         NUMBER SIGN
.......

As you can see, the two protocols have two vastly different ways to
encode
exactly the same thing - numeric & alphabetic keys on a terminal
device.

Some other issues with the two protocols:

RFC 2833 allows the transmission of keystrokes from a terminal over
RTP.
However, RFC 2833 also defines a large set of other events besides
keystrokes
that can be carried in the same RTP stream format:
    o  DTMF tones (Section 3.10);
    o  fax-related tones (Section 3.11);
    o  standard subscriber line tones (Section 3.12);
    o  country-specific subscriber line tones (Section 3.13) and;
    o  trunk events (Section 3.14).

While this multiple-event-type property may be useful in some PSTN
transport 
applications, it is definitely not appropriate as a general keystroke
communications 
mechanism. Many applications will not want anything but keystrokes to
come over
the RTP session - no audio, no fax tones.

RFC 2793 also allows the transmission of keystrokes from a  terminal

over RTP. This RFC uses ISO/IEC 10646-1, level 3 to define a much
larger set 
of possible keys, but the keys on a 12-button terminal device are all
included in the larger set.
This RFC does not include any other event types except keystrokes,
but RFC 2793 
does not include a method to carry keystroke duration as a function
of the protocol. 

So to summarize:
RFC 2833 
1) doesn't cover all of the possible keys available in a terminal
device
2) carries extra stuff besides keystrokes in the protocol

RFC 2793
1) Doesn't carry keystroke duration information. 

Meanwhile, both protocols use the same redundancy mechanism 
(RFC 2198) for more reliable delivery of keystrokes.

My issue:
As a general rule, a device establishing a SIP session with another 
device should not have to discover what type of device it is
sessioning with 
before knowing whether to send keystrokes using RFC 2833 or RFC 2793
over 
the RTP session. There should be only one protocol and one encoding
for keystrokes 
in SIP and RTP, regardless of the device that has the keys on it. 

My solution:
Combine the best of RFC 2833 and RFC 2793 for a universal keystroke
protocol.
1) Use RFC 2793's encoding scheme for all keys along with T.140
protocol stucture
2) Use RFC 2833's duration scheme for keystroke durations
3) Use RFC 2198 for reliability
4) Remove the DTMF keystroke events from from Section 3 of RFC 2833 
and keep that protocol format specifically for telephony events 
(fax tones, subscriber line tones, etc.).
5) Add a new payload format in RFC 2833 that is specifically for
keystrokes 
using the 2833-2973 hybrid protocol. 

In this way, you could INVITE only the 2833-2973 hybrid protocol if
you wanted 
just keystrokes, or you could INVITE the RTP audio also, or just the
telephony
events, or any combination using SDP media control mechanisms (m=3D)

In my company's applications we plan to establish  SIP sessions with
PSTN/SIP 
Gateways, Softswitches, SIP phones, SIP mobile devices, and SIP PCs.
The key input from all of these different sources should use the
same
protocol. The key input that we send to all of these devices should
use
the same protocol. We don't want to have to use different protocols
to 
send keystrokes to a SIP gateway, a SIP wireless device, a
Softswitch, or
a PC. We don't want to have to know ahead of time what type of device
we
are calling to determine what kind of session to INVITE to get
keystrokes.
The keystroke protocol for all devices that have keys should be the
same.

If PSTN transport application developers vendors want to stick fax
tones 
and call progress in with the compressed audio in a
gateway-to-gateway 
RTP session, that's fine. Just don't make everybody have to support
those
events when all you want are keystrokes. 

Skip Cave

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

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 06 Sep 2000 10:31:13 -0700

Skip,

What is your definition of a key or keystroke?

I think you are missing a critical point here.  T.140 is designed for text 
chat, where the characters are simply renderred, rather than 
interpreted.  I don't think this is what you want.  AVT tones is designed 
for carrying input that has traditionally been associated with the 
telephony world.  If a SIP UA has a keypad that looks like a DTMF keypad, 
then _most of the time_ it should act like a DTMF keypad, and send the 
corresponding AVT encoding.

If you are interested in getting generic input, I would use something 
completely different that has nothing to do with RTP.  For example, if I 
write some characters on my Palm, is that a keystroke?  If I tap a region 
on a touchscreen, or select a region with a mouse, is that a 
keystroke?  What about speach rec of canned vocabularies (Yes, No, 
numbers..) Do we care?

I think what we are really after is a way to send the kind of "menus" and 
"forms" that we are now used to in traditional IVRs, down to the end device 
(a SIP UA), where it can render the request as speech, text, buttons, 
whatever;  the *method* of input is irrelevant.  It is the selection of a 
particular menu choice, or the completion of a specific bit of information 
(account number) that your service logic cares about, so let the end-system 
render the damn thing.

An example of such a system is a "distributed IVR" that uses VoXML on each UA.

If I want the help-desk...

INVITE sip:[email-masked] SIP/2.0
To: <sip:help-desk>
From: <sip:[email-masked]>
...

301 Moved
Contact: <http://support.company.com/scripts/help-desk-ivr-script.voxml>

I get a reference to the script, then start running it.  At the end of some 
of the menus are SIP URLs.

sip:[email-masked]?Priority=urgent&Subject=account714352

I like this model.  I'm much less interested in "keystrokes"  than generic 
input (VoXML-type model works here), and I think most SIP UAs will want the 
ability to talk to the PSTN some of the time (AVT tones model will be 
needed here).  If we need to get DTMF input to a party that isn't otherwise 
involved in media, we can either tunnel AVT tones inside of SIP, or 
"conference" in the thrid party for AVT tones only.

thanks,
-rohan

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 06 Sep 2000 14:03:19 -0400

See also the WAP menu model. (This is probably separable from the rest
of the WAP stuff.) Also, you're well on your way to just downloading
Java or Javascript. I don't think that voice and menu interaction are
all that similar except in the most trivial cases. For example, you
typically present many menu fields visually at the same time, but
(naturally) only one at a time with voice.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs