Subject: Re: [SIP] Two Keystroke Encodings

From: Rohan Mahy <[email-masked]>
Date: Wed, 06 Sep 2000 17:11:32 -0700

At 02:41 PM 9/6/00 , Skip Cave wrote:
>Rohan Mahy said: What is your definition of a key or keystroke? 
>http://lists.bell-labs.com/pipermail/sip/2000q3/002612.html
>
>Skip Cave says: A keystroke occurs whenever the terminal device user 
>presses a key on the terminal device.
>
>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 have no idea what the difference between "rendering" and "interpreting" 
>a keystroke is. When you press a key, you want an indication that the key 
>is pressed to be passed over the network to the application server. If you 
>are saying that the terminal device should somehow "interpret" the 
>keystroke and convert it into some other form, that could be an option. 
>You certainly can have the application in the terminal translate other UI 
>actions into keystrokes if you like.

<philosophy>
I don't want to translate anything *into* keystrokes.  I don't want 
keystrokes to become somehow a fundamental form of input that everything 
else is translated into.  I want a generic input mechanism (like HTML 
forms).  In this kind of scheme, keystrokes and clicks and voice commands 
and other input would all be equal.
</philosophy>

>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.
>
>What if the SIP UA has 5 keys, or 10 keys, or 20 keys, or 40 keys? Which 
>encoding scheme do you use then? Just because 12 keys is a "tradition" 
>doesn't mean that there should be something magic about

the fact is that many SIP UAs will have these specific 12 keys because they 
want them to work more or less like the 12-keys on the original touch-tone 
telephone.  the reason it has such a pad is so it can interoperate with the 
PSTN and other PSTN  networks.

if your UA has a graphical representation of a DTMF keypad, chances are, 
that keypad is still used for interop with a TDM network, and it should 
also generate AVT over RTP when you click on those things.

>12 keys that causes them to use a different protocol.
>
>Applications don't just get keystrokes from a terminal. Applications need 
>to send keystrokes TO a terminal.

this is news.  please supply an example.

>Which encoding scheme do I use? How do I tell whether the SIP device that 
>I am sending keystrokes to should get RFC 2833 or RC 2793?

why are you sending "keystrokes".  I think you should either send DTMF or 
generic input.

>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?
>
>The application running on the Palm can certainly issue a keystroke 
>indication to the network when a number or letter is written on the Palm 
>screen.
>
>This is an excellent example of how an application in the network can be 
>written to use a generic keystroke protocol.  The various device types can 
>be adapted to utilize this model, even if they don't have keys.
>
>If I tap a region on a touchscreen, or select a region with a mouse, is 
>that a keystroke?
>
>Again, you can do this if the application warrants. This approach is 
>particularly useful when the device does not have enough keys to support 
>the application, but the device has .some other user input mechanism that 
>can be converted to a keystroke indication.

again, I don't want to convert anything to keystrokes.  I don't need this 
on web pages (where I can have similar one decision at-a-time pages), so 
why do I need this on SIP?

>Essentially, keystrokes become THE general-purpose 
>user-input-event-reporting mechanism for terminals on the packet network.

YUCK!

>What about speech rec of canned vocabularies (Yes, No, numbers..)
>
>If your speech rec is resident in the terminal device, converting the 
>spoken phrases into keystroke indications is a good way to generalize an 
>application so it could work on anything from a simple phone, all the way 
>up to a

I think you've got it backwards.  If you use a generic input scheme to 
begin with, then the UA can render that in any appropriate way (just like a 
web page).  You shouldn't start with one input mechanism and promote it to 
King of All Input Methods, then expect everyone to translate.  Keystrokes 
are particularly bad at this.  How do I enter Chinese or Kanji characters 
for example?

>voice-reco-enabled wireless PDA.
>
>The application can ask: "Please say what you would like to do next, or 
>press 1 for your account balance, 2 for ... etc." In this way the exact 
>same application in the network could work across simple PSTN phones or 
>voice- reco-enabled wireless PDAs. The network-based application just sees 
>keystroke indications, no matter what the terminal device looks like.

NO, NO, NO, NO, NO!

The application logic has a list of choices in your example menu.  It does 
not need to be the responsibility of the application to choose that 
1=account balance.  The app doesn't have to say "Please press "1" or say 
"balance".  The UA should do that.  If the UA is a TDD device, it can 
display "Please *type* "balance", "sales", or "operator".  If the UA has no 
screen and a DTMF-pad, and the user is Spanish it can say, ".. marque el 
numero uno .."

>Do we care?
>
>If your question is: "Do we care about what user actions are classified as 
>keystrokes", the answer is no. Any user action can be classified as a 
>keystroke by the terminal  device. If the terminal device has the 
>capability to understand a particular mode of user input (keystrokes, 
>stylus taps, spoken words, eye winks, etc.) it can report that action as a 
>keystroke or user event.
>
>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.
>
>.... clipped example of VoXML
>
>The model you present is certainly one of the many interesting 
>architectures proposed for providing a user interface on a terminal 
>device. You can download all of the user prompts (both spoken and printed) 
>to the terminal device before presenting them. You can download all of the 
>interaction logic to the terminal device so it can present the complete 
>user interaction with minimal external intervention. You can aggregate or 
>store all of the user input in the terminal (keyed, spoken, tapped, 
>winked, etc.) assuming the device can detect and understand the input, and 
>transmit the result of the complex user interaction at the very end.
>
>In this scenario, you certainly don't need a keystroke protocol to 
>propogate the result of the complex user interactions. A XML-structured 
>message carrying the result of a complex user interaction from the 
>terminal device to the application server in the network, is probably the 
>way to go.
>
>VoXML provides an alternate apporoach. VoXML stores all of the user 
>prompts, interaction logic, and user input on the "Voice Browser". 
>Actually, the interaction logic can be said to reside at the VoXML page's 
>URL, but in any case it isn't in the terminal device. The terminal device 
>can be very "dumb". This model is suitable when you don't want to put lots 
>of smarts, storage, or fancy UI equipment on the terminal device, and that 
>isn't just on PSTN phones! Don't forget, in this model, VoXML relies on a 
>standardized keystroke protocol (DTMF) to communicate the user input to 
>the VoXML server.
>
>So we have at least two models - everything on the device, and everything 
>in the network. The first approach makes for simpler network devices. The 
>latter approach has the advantage of simpler terminal devices. But simpler 
>terminal devices REQUIRES a standard input event (or keystroke) model.

You can ask around, but I think the trend is for more stuff on the end 
systems.  If you really want dumb and simple, you can make a SIP device 
with just a DTMF keypad, or you can implement a stimulus response protocol 
like MGCP or Cisco's "Skinny", but that is not within the SIP WG charter.

>However, the general architecture should support both of these models. If 
>you decide that you want to build a  SIP device that is really dumb, and 
>it won't support XML or WAP pages, and it won't support voice reco, and it 
>won't support a display, you should still be able to do it. VoXML points 
>the way.
>
>Remember, not all  terminal devices will have the capability to store
>
>a sequence of keystrokes,

that's absurd.  what terminal device that can speak SIP can't store a 
sequence of keystrokes?  SIP requires enough storage to keep TCBs and store 
packets for possible retransmission.  They have to have at least SOME memory.

>let alone do voice reco, locally. These dumb terminal devices may be a 
>PSTN device, but they may not. You should be able to build a SIP device 
>that essentially has no UI except a few keys and a display or speaker, 
>with no storage requirements other
>
>than the display matrix.
>
>In any case, VoXML REQUIRES that the dumb device have a keystroke 
>reporting mechanism, if it doesn't have an audio input mechanism for voice 
>reco, or particularly if can't even aggregate keystrokes locally. So, 
>there is already the requirement for a keystroke standard. VoXML 
>originally was focused on calls from a PSTN phone to a Voice Browser, but 
>the calling device could easily be a simple SIP device.
>
>The VoXML device may have 5 keys, or 10 keys, or 200 keys, but the 
>"dumb-terminal, smart-network-server" model needs a way to get the 
>keypresses, (or stylus-taps, or eye-winks) to the "smart" application 
>server (or VoXML server, or Telephony Platform, or whatever) over the 
>network in a standard way.
>
>Remember, some terminal devices will not have the capability to store
>
>a sequence of keystrokes, let alone do voice reco, locally.
>
>I like this model.  I'm much less interested in "keystrokes"  than generic 
>input (VoXML-type model works here),
>
>I'm not sure what you mean by "generic input". If you mean: Pressing the 
>"5" key OR, saying the word "five" OR, scribing the symbol "5" on the 
>screen with the stylus will result in a "5-key pressed" message from the 
>terminal. If this is what you mean by "generic input", then I agree with you.

please look carefully at html forms.  for example:

         <select name="menu-choice">
                 <option>balance</option>
                 <option>operator</option>
         </select>
         <input type="text" value="account">
         <input type="submit">

the select tag presents a list of options.  it returns that 
menu-choice="balance", not that the menu choice was "5".

the first input tag collects a complete string.  not "5", but "546325245" 
and will eventually POST that information back.

>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).
>
>A SIP UA should never need to know whether it is sending keystrokes to a 
>PSTN device or another SIP device. The protocol to achieve both should be 
>identical. For one thing, it probably won't be easy to figure out whether 
>the device you are estasblishing a SIP session with is in the PSTN or the 
>packet network. You definitely should NOT be REQUIRED to find out.
>
>If, in the course of an application. I want to send the key indication "5" 
>to the other device, I do not want to have to figure out whether to send 
>the info as RFC 2833 or RFC 2739. There should only be one way.

Don't worry, you won't find anyone at the SIP bakeoff who will try to send 
the "5" character to a terminal using RFC 2739.

>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 third party for AVT tones only.
>
>No, just send standard keystrokes in a standard protocol that all devices 
>(or their proxies) understand.

You assume that everyone else shares your love of keystrokes.

>Henning said: 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. 
>http://lists.bell-labs.com/pipermail/sip/2000q3/002614.html
>
>Again, this model assumes that you want to store the interaction logic on 
>the terminal device. The interaction logic is may be simply
>
>keystroke aggregation, or full blown Javascript and voice reco, but you do 
>not want to force this model as the only way to do user interactions.

why not.  it is probably nearly as light at this point to implementing 
keystrokes on top of RTP.

thanks,
-rohan

>You may not want to put a WAP browser or voice reco on the terminal 
>device. A particular application provider may be prefectly happy with a 
>simple 5 or 10-key terminal device with no display. The standard keystroke 
>model solves these issues simply and powerfully.
>
>Skip Cave Sr. Principal Engineer InterVoice-Brite Inc.
>
>
>
>
>
>
>
>  Rohan Mahy <[email-masked] 09/06 12:31 PM  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
>
>
>At 08:30 PM 9/5/00 , Skip Cave wrote: 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
>
>
>
>_______________________________________________
>SIP mailing list
>[email-masked]
>http://lists.bell-labs.com/mailman/listinfo/sip

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

---

From: "Skip Cave" <[email-masked]>
Date: Wed, 06 Sep 2000 16:41:48 -0500

>http://lists.bell-labs.com/pipermail/sip/2000q3/002612.html

Skip Cave says:
A keystroke occurs whenever the terminal device user presses a key on
the terminal device.

>interpreted.  

I have no idea what the difference between "rendering" and
"interpreting" a
keystroke is. When you press a key, you want an indication that the
key is pressed 
to be passed over the network to the application server. 
If you are saying that the terminal device should somehow "interpret"
the keystroke
and convert it into some other form, that could be an option. You
certainly can have 
the application in the terminal translate other UI actions into
keystrokes if you like.

>I don't think this is what you want.  AVT tones is designed 

What if the SIP UA has 5 keys, or 10 keys, or 20 keys, or 40 keys? 
Which encoding scheme do you use then? Just because 12 keys is 
a "tradition" doesn't mean that there should be something magic about

Applications don't just get keystrokes from a terminal. Applications
need to
send keystrokes TO a terminal.  Which encoding scheme 
do I use? How do I tell whether the SIP device that I am sending
keystrokes to 
should get RFC 2833 or RC 2793?

The application running on the Palm can certainly issue a keystroke
indication 
to the network when a number or letter is written on the Palm screen.
 
This is an excellent example of how an application in the network can
be
written to use a generic keystroke protocol.  The various device
types 
can be adapted to utilize this model, even if they don't have keys.
 
>If I tap a region on a touchscreen, or select a region with a mouse,
is that a 
>keystroke?  

Again, you can do this if the application warrants. This approach is
particularly 
useful when the device does not have enough keys to support the
application, 
but the device has .some other user input mechanism that can be
converted to 
a keystroke indication. Essentially, keystrokes become THE
general-purpose 
user-input-event-reporting mechanism for terminals on the packet
network.

If your speech rec is resident in the terminal device, converting the
spoken
phrases into keystroke indications is a good way to generalize an
application
so it could work on anything from a simple phone, all the way up to a

The application can ask: "Please say what you would like to do next,
or 
press 1 for your account balance, 2 for ... etc." In this way the
exact same 
application in the network could work across simple PSTN phones or
voice-
reco-enabled wireless PDAs. The network-based application just sees 
keystroke indications, no matter what the terminal device looks
like.

>Do we care?

If your question is: "Do we care about what user actions are
classified as 
keystrokes", the answer is no. Any user action can be classified as a
keystroke
by the terminal  device. If the terminal device has the capability to
understand
a particular mode of user input (keystrokes, stylus taps, spoken
words, 
eye winks, etc.) it can report that action as a keystroke or user
event.

>"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, 
>(account number) that your service logic cares about, so let the
end-system 
>render the damn thing.

The model you present is certainly one of the many interesting
architectures
proposed for providing a user interface on a terminal device. You can
download 
all of the user prompts (both spoken and printed) to the terminal
device before 
presenting them. You can download all of the interaction logic to the
terminal
device so it can present the complete user interaction with minimal
external 
intervention. You can aggregate or store all of the user input in the
terminal 
(keyed, spoken, tapped, winked, etc.) assuming the device can detect
and 
understand the input, and transmit the result of the complex user
interaction 
at the very end.

In this scenario, you certainly don't need a keystroke protocol to
propogate the 
result of the complex user interactions. A XML-structured message
carrying
the result of a complex user interaction from the terminal device to
the application 
server in the network, is probably the way to go.

VoXML provides an alternate apporoach. VoXML stores all of the user
prompts, 
interaction logic, and user input on the "Voice Browser". Actually,
the 
interaction logic can be said to reside at the VoXML page's URL, but
in 
any case it isn't in the terminal device. The terminal device can be
very "dumb".
This model is suitable when you don't want to put lots of smarts,
storage, 
or fancy UI equipment on the terminal device, and that isn't just on
PSTN phones!
Don't forget, in this model, VoXML relies on a standardized keystroke
protocol (DTMF) to 
communicate the user input to the VoXML server. 

So we have at least two models - everything on the device, and
everything 
in the network. The first approach makes for simpler network
devices.
The latter approach has the advantage of simpler terminal devices.
But
simpler terminal devices REQUIRES a standard input event (or
keystroke) 
model.

However, the general architecture should support both of these
models. 
If you decide that you want to build a  SIP device that is really
dumb, and it won't support XML or WAP pages, and it won't support
voice reco, and it won't support a display, you should still be able
to 
do it. VoXML points the way. 

a sequence of keystrokes, let alone do voice reco, locally. These
dumb 
terminal devices may be a PSTN device, but they may not. You should
be 
able to build a SIP device that essentially has no UI except a
few keys and a display or speaker, with no storage requirements other

than the display matrix.

In any case, VoXML REQUIRES that the dumb device have a keystroke 
reporting mechanism, if it doesn't have an audio input mechanism 
for voice reco, or particularly if can't even aggregate keystrokes
locally. 
 So, there is already the requirement for a keystroke standard. 
VoXML originally was focused on calls from a PSTN phone to a Voice
Browser, but the calling device could easily be a simple SIP device.

The VoXML device may have 5 keys, or 10 keys, or 200 keys, but
the "dumb-terminal, smart-network-server" model needs a way to 
get the keypresses, (or stylus-taps, or eye-winks) to the "smart"
application server (or VoXML server, or Telephony Platform, or 
whatever) over the network in a standard way.

>input (VoXML-type model works here), 

I'm not sure what you mean by "generic input". If you mean:
Pressing the "5" key OR, saying the word "five" OR, scribing the
symbol "5" 
on the screen with the stylus will result in a "5-key pressed"
message 
from the terminal. If this is what you mean by "generic input", 
then I agree with you.

>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).  

A SIP UA should never need to know whether it is sending keystrokes
to a PSTN 
device or another SIP device. The protocol to achieve both should be
identical. 
For one thing, it probably won't be easy to figure out whether the
device you
are estasblishing a SIP session with is in the PSTN or the packet
network. 
You definitely should NOT be REQUIRED to find out. 

If, in the course of an application. I want to send the key
indication "5" to the 
other device, I do not want to have to figure out whether to send the
info as 
RFC 2833 or RFC 2739. There should only be one way.

>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 third party for AVT tones only.

No, just send standard keystrokes in a standard protocol that all
devices 
(or their proxies) understand.

Henning said: 
>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.

Again, this model assumes that you want to store the interaction 
logic on the terminal device. The interaction logic is may be simply

keystroke aggregation, or full blown Javascript and voice reco, but 
you do not want to force this model as the only way to do user
interactions.

You may not want to put a WAP browser or voice reco on the terminal
device.
A particular application provider may be prefectly happy with a
simple 
5 or 10-key terminal device with no display. The standard keystroke
model solves 
these issues simply and powerfully.

Skip Cave
Sr. Principal Engineer
InterVoice-Brite Inc.

>>> Rohan Mahy <[email-masked]> 09/06 12:31 PM >>>
Skip,

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.

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.

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.

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

At 08:30 PM 9/5/00 , Skip Cave wrote:
>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 
>
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)
>*                     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
>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
>
>
>
>
>
>
>

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 7 Sep 2000 11:39:06 -0400

At least some of this debate seems to be a replay of the ancient (from ISDN
days) stimulus vs. functional protocol debate.  Skip is talking about
stimulus signalling, Rohan about functional.  Oldtimers can tell you the
merits of each, and also that functional may have won in the short term, but
stimulus keeps coming back.

Tom T

> -----Original Message-----
> From: Rohan Mahy [mailto:[email-masked]]
> Sent: Wednesday, September 06, 2000 8:12 PM
> To: Skip Cave
> Cc: [email-masked]
> Subject: Re: [SIP] Two Keystroke Encodings
> 
> 
> "interpreting" 
> for carrying 
> devices. The 
> Pressing the 
> indication "5" 
> involved in

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 07 Sep 2000 09:50:07 -0700

I agree with Tom's assesment.  My feeling is that stimulus signalling is 
fine for MGCP and Megaco, but is not appropriate in the SIP WG.

thanks,
-rohan

At 08:39 AM 9/7/00 , Tom-PT Taylor wrote:
>At least some of this debate seems to be a replay of the ancient (from 
>ISDN days) stimulus vs. functional protocol debate.  Skip is talking about 
>merits of each, and also that functional may have won in the short term, 
>but stimulus keeps coming back.
>
>Tom T

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 18 Sep 2000 04:07:26 -0400

Catching up on some old email....

The subject of discussion here was Skips "generic keystroke" transport
method, and whether to use rfc2833, rfc2793 (text over RTP), or something
else.

I would actually claim that we already have the worlds finest keystroke
encoding protocol. It is also one of the worlds most widely deployed
protocols. It is also the most powerful stimulus signaling protocol ever
invented. It runs on every desktop and laptop. Shortly, it will run in some
form on every wireless device. It is driven by client side interactions
which can be rendered in the format appropriate for that device. What is
this magical protocol?

Its called HTTP.

VoiceXML uses HTTP post to upload the data it collects from voice forms.
HTML uses HTTP to upload the data it collects from text forms. Clients know
nothing about the semantics of the data they render from HTTP, nor do they
know anything about the semantics of the data they post to http servers.
Only the human user knows. Sounds like a stimulus signaling protocol to me.

When used in conjunction with SIP, HTTP is a very, very powerful tool for
integrating in services which require application specific user stimulus.
SIP provides all the needed hooks by allowing us to carry around http URLs
and MIME content, and by using the various MIME headers like Accept which
allow a server to figure out the rendering tools (html, voicexml, wml) that
the client supports.

As an example, consider a pre-paid calling card service. If the calling
device can render html, wouldn't it be far cooler to return, in a 183, a
pointer to a web page where the user can enter, via a form, their calling
card number? If the card checks out, clicking "submit" will complete the
call, else if the card validation fails, the SIP server would return a 400.
In this case, the "stimulus" that the SIP server will receive is in the form
of an http post containing the credit card number. I'll note that if the SIP
server had returned a voiceXML script instead of an html page (or an http
reference to it), the stimulus with the credit card number would be exactly
the same - an HTTP form post. In that case, we completely decouple the user
interaction from the processing of the resulting data, using http for the
intermediate transfer of the raw data collected from the user. Very nice
model, IMHO.

-Jonathan R.

> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Rohan Mahy
> Sent: Thursday, September 07, 2000 12:50 PM
> To: Tom-PT Taylor
> Cc: Skip Cave; [email-masked]
> Subject: RE: [SIP] Two Keystroke Encodings
> 
> 
---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (973) 952-5000
http://www.dynamicsoft.com