Subject: Re: [SIP] DTMF and Universal Key Input

From: "Skip Cave" <[email-masked]>
Date: Thu, 10 Aug 2000 13:45:31 -0500

Henning S. And Scott P. have made some interesting comments to my post. Before I go about addressing their issues directly, I would like to make a few comments.

For user input:
In the future, there will be SIP terminals that only have a microphone.
In the future, there will be SIP terminals that only have a video camera.
In the future, there will be SIP terminals that only have keys or buttons.
In the future, there will be SIP terminals that only have a smell detector.
In the future, there will be SIP terminals that only have some sort of weird detector (wink detector? emotion detector?) that we can't imagine. 
In the future, there will be SIP terminals that have all sorts of combibations of the above user input devices. 

And for user output:
In the future, there will be SIP terminals that only have a speaker (or two). 
In the future, there will be SIP terminals that only have a display. 
In the future, there will be SIP terminals that only have a tactile transducer (vibrates,
makes bumps, gets fatter or taller).
In the future, there will be SIP terminals that only have a smell generator.
In the future, there will be SIP terminals that only have some sort of weird output mechanism (telepathy? brain socket connection?) that we can't imagine. 
In the future, there will be SIP terminals that have all sorts of combibations of the above user output devices. 

For Control:
In the future, there will be SIP UAs that reside in refrigerators and let you set the tempreature & find out if the door is open from anywhere. They will also let you know what the tempeature in your refrigierator is, and if the temperature drops below a limit you set, or if the supply voltage is low. 

In the future, there will be SIP UAs that reside in your home air conditioner that let you set the tempreature in your house, & find out if your door is open from anywhere. They will also let you know what the temperature in your house is, and if the temperature drops below a limit you set, or if the A/C supply voltage is low. 

In the future, there will be SIP UAs that reside in a baby monitor that let you hear, see, and smell your baby from anywhere. You will be able to talk to your baby and pehaps the baby will even be able to see (and smell?) you. keys on the remote monotor will help control the camera. There probably won't be any keys on the baby's terminal.

Of course, someone will have to figure out what a SIP "Universal Remote Control" will look like, to control all of these various gizmos, but that is a topic for another discussion.

The point is, that we cannot (and should not) know all of the kinds of media that SIP will be required to support today. We only need a mechanism to add new media types as necessary. Luckily, we already have that mechanism. It is called SDP. Now, we only need to define the media types we DO know today. 

Audio, Video, Keystrokes. These three media types are clearly widely used today, so a specific SDP session should be defined for each of these media. Luckily, two of the three have already been done. SDP already has definitions for video and audio sessions.

An important point here. We shouldn't try and combine different media types in one session. A single SDP session is intended for a single type of media. To be specific, we should not combine Video & Audio in a single session. We shouldn't combine Video and Keystrokes in a single session. We should not combine Audio and Keystrokes in a single session.

There is an important rationale behind this requirement. In an ideal world, there would be a method for determining the capabilities of a SIP terminal. A SIP UA could ask another UA just what capabilities it has. Some of the things you should be able to determine:
Is the UA is a human-interface device or an automation device?
If it is a human-interface device, then you should be able to determine what user input mechanisms it supports. 
Does it have Audio input (microphones)? If so, how many? What encoders are supported?
Does it have Video input (video cameras)? If so, how many? What encoders are supported?
Does it have Key input (keypad)? If so, how many keys? What labels are on the keys? 

If it is a human-interface device, then you should be able to determine what user output mechanisms it supports. 
Does it have Audio output capability (speakers)? If so, how many? What audio decoders are supported?
Does it have Video output (screens)? If so, what resolution and how many? What video decoders are supported?
Does it have tactile output (vibrator, who knows)? If so, what kind & how many? 

Unfortunately, SIP does not allow an explicit pre-determination of terminal capabilities today. However, it does have a try-and-see-if-it-works kind of determination, which is good enough for now.

The reason that you only want one media type per session is because when you use SDP to explicitly set-up a media session with a UA, that act implicitly "turns on" that specific media device. Therefore, when you use SDP to set-up a transmit audio channel from the remote device, you are essentially telling the microphone in that device to start transmitting it's output on that session. When you use SDP to set-up a transmit video channel from the remote device, you are essentially telling the video camera in that device to start transmitting it's output on that session. When you use SDP to set-up a keystroke session on a remote device, you are telling the remote device to start transmitting keystrokes from the keyboard on that session.

A terminal may have video, audio, and keys as potential user input mechanisms. For whatever reason, an application may only want to get audio from a terminal. The application may not care anything about the video or keystrokes. You don't want to force the application to receive video and audio when all it wanted was audio. You don't want to force the application to receive audio and keystrokes when all it wanted was keystrokes.

If you turn off a session, you turn off the audio, video, or keystroke transmitter driving that session. If two or more media types are combined in a single session, you restrict the capabilities of the application. If both audio and video are in a single session,  you won't be able to "turn on or off" only one media type . When you setup the combined channel, you essentially turn on both media transmitters. You can only turn on both the audio and video transmitters, not either individually. 

The same argument goes for keystrokes and audio. You should be able to set up a session that only carried keystrokes, or only audio. Otherwise, you prevent the application from efficiently dealing with it's requirements. 
This promotes bandwidth conservation. It also helps simplify applications. If you don't want the media, don't set up the session! 

Probably even more importantly, the application may require that audio, video and keystrokes to go to different places! This requirement will be key in implementing advanced applications, and if the media are all lumped together in one channel, you can't send them different places. There are lots of applications even today that need the keystrokes and the audio to go different places. Some applications just want the keystokes and nothing else. Some want video and nothing else. I have applications where I want a terminal's keystrokes to go one place, and the audio to go to three different places. I can conceive of applications where the audio goes one place, and the keystrokes go three different places. 

RFC 2833 specifies a method for combining DTMF tones (PSTN-specific keystrokes), an audio session, and other PSTN signaling events such as ringing and busy tones, in a single RTP session. While this architecture is good for the person that just wants to transport EVERYTHING that's in a PSTN session from one gateway to another, It may NOT be ok for those who want to implement general applications in the packet network.

Of course, we all know the problem that RFC 2833 is trying to address. The current low-data-rate (LDR) audio codecs (G.732 &G.729 to be specific) were not designed to accurately encode tones. These codecs were designed with a perceptual model of the human voice in mind. If the listener can understand the un-encoded speech, the codec was judged a success. None of the current crop of codecs will convert DTMF or other PSTN tones with enough accuracy to allow automatic detectors to reliably extract the original tones from the encoded/decoded audio stream.

These LDR codecs are being used to transport voice traffic over the packet network. However, with the LDR codecs, the end-to-end keystrokes were getting distorted to the point that they couldn't be detected! Many applications in the PSTN rely on the presence of DTMF in-band, end-to-end signaling, so the network engineers had to come up with a solution. 

To solve this problem, packet network engineers logically decided to take the tones "out-of-band", or at least out of the G.723/729 codec's "band". However, The out-of-band tones must have enough information to reconstruct a reasonably intact G.711 PCM waveform out of the LDR speech codec data, and the out-of-band tone data. The reconstructed G.711 data needed to be both legible to the human listener and with the correct tones for the automatic tone detectors in the PSTN. 

Transporting PSTN signaling over packet networks isn't a new problem. The H.323 protocol addressed this issue with the UserInputIntication messages in the H.245 session. The RFC 2833 designers have done even a better job of designing a solution to the PSTN transport problem, using RFC 2833.

This DTMF transport problem sort of LOOKS like the keystroke-as-media problem that I have been describing. However there are significant differences in the requirements (and hence differences in the potential solutions) in the two problems.

The key differences:

Audio or not? 
RFC 2833 focuses on transporting DTMF signals over a packet network for re-construction of the tones in the PSTN. RFC 2833 assumes that the stuff it will be carying are still audio signals, but just special types. Also, it is assumed that the stuff will all eventually have to be re-combined, hopefully with nearly the same charateristics as the original waveform. As such, detailed information about the tone frequencies, levels, duration, cadence, and time reference to the concurrent audio stream, are all required to be in the transported data.

For keystrokes-as-media, the assumption is that the keystrokes are just that - keystrokes. No tones, no freqencies, no levels, no requirements for resynchronization, just which key was pressed. At the most, you may need a duration indication (key-on, key-off), but this charateristic would depend on whether the terminal device supported key duration.

I quote from section 3.1 of RFC 2833:
"If an end system is directly connected to the Internet and does not need to generate tone signals again, time alignment and power levels are not relevant. These systems rely on PSTN gateways or Internet end systems to generate DTMF events and do not perform their own audio waveform analysis. An example of such a system is an Internet interactive voice-response (IVR) system.   

In circumstances where exact timing alignment between the audio stream and the DTMF digits or other events is not important and data is sent unicast, such as the IVR example mentioned earlier, IT MAY BE PREFERABLE TO USE A RELIABLE CONTROL PROTOCOL RATHER THAN RTP PACKETS (my caps). In those circumstances, this payload format would not be used."

So according to the authors of RFC 2833, the DTMF in RTP scheme they define isn't necessarily the best protocol to carry events such as standard keystrokes that don't need to be time-aligned, or have specific power levels or have frequencies. 

Terminal Generalization: 
RFC 2833 assumes that the originating device is a PSTN phone (no self-respecting packet terminal would generate tones when it's keys were pressed). 2833 doesn't address the issue of what happens when someone presses the keys on a SIP terminal, or a PC running a SIP session. Well, it DOES say something on the subject:

"(By using RFC 2833) an Internet end system such as an "Internet phone" can emulate DTMF functionality without concerning itself with generating precise tone pairs and without imposing the burden of tone recognition on the receiver."     

So RFC 2833 recognizes the fact that a SIP terminal could send RFC 2833-compliant RTP streams to a PSTN device (presumably through a gateway), if it needs to really tightly control the delivery of the tones. The device would then rely on the gateway to generate the actual tones in the PSTN. Of course, if the packet device DIDN'T need to tightly control the key input presented to a PSTN device, and it DIDN't need precice synchronization with an audio stream, it potentially could use a much simpler key input protocol to send keystrokes to the gateway. 

What should be done when a SIP terminal is connected to another SIP device, and all they want to do is send keystrokes back and forth? This will be a common requirement where the device is a SIP UA in a remote-controlled appliance that only needs keystrokes for control. Should we use RFC 2833 to send the keystrokes from the control device to the remote appliance? 

This means you need the RTP protocol. You need to calculate RTSP stats. You need sequence numbers and time stamp alignment with the RTP audio (remember, there isn't any audio in this application). You need to repeat the keystroke packet every 50ms until the key is released. What happens if the keystroke duration is unknown (or is a don't care)? How do you implement redundancy when the keystroke duration is less than the repeat rate?  Do we need all this stuff just to get keystrokes?

Probably the most common keystroke scenario today is a person interacting with a IVR (Interactive Voice Response) system. In the PSTN, you automatically get a two-way audio connection when you connect a call. However, in most of the today's IVR scenarios, the IVR only needs an audio path FROM the IVR TO the caller, to deliver prompts. The IVR doesn't care about audio coming from the caller. It can do without it. All it cares about is what keys the caller presses. 

In the PSTN, the audio is delivered to the IVR systems whether they wanted it or not, since that was the only way that keystrokes (DTMF) could get to the IVR. In a packet network, the application server should have the option to NOT have audio delivered to it - just keystrokes. This would save bandwidth in the network, and save protocol processing horsepower on the IVR/server.

Now, just because the IVR system doesn't need to see the audio stream doesn't mean that the caller won't be transmitting audio streams. Many applications (calling card, conferences) will have the caller's terminal sending its audio to other places, just not to the IVR. Or, the caller may need to send his audio AND keystrokes to the IVR, but just audio (no keystrokes) to other places. Or the keystrokes need to go other places. Or, Or, Or.

In the above example, the IVR/server in the network may handle thousands of SIP sessions, but all of them could be just keystroke input sessions. This occurs any time the application server is the control node for applications that involve large numbers of two or three-way calls (calling card, find-me, record/log, etc.). The application server doesn't actually need any of the audio or video streams, as the audio & video streams are going to the various participants as they communicate with each other. However the server needs to know about all of the keystrokes from any of the participants, as that is the method that this application uses to let the participants indicate what function is to be performed by the application.

In this scenario, you don't want too heavyweight of a protocol for the keystrokes, as that will limit the number of keystroke sessions that a single server could handle. The simpler the keystroke protocol, the more sessions a single server could handle. If I DO need to receive audio for recording or speech recognition purposes, I will probably send that stream to some other device (media recording/storage server, speech regognition server) in the network, not the keystroke server.

The important issue here is that applications residing in the packet network should be able to get simple keystroke media messages (no frequencies, no levels, no timestamps) from the devices on the other end of the SIP session whether the originator of the keystroke was a SIP terminal, A SIP phone, a SIP remote controller, a PC, or a PSTN phone. It should't be a requirement for the device to support audio or video streams just to send keystrokes. 

So, in summary:
1) RFC 2833 is intended for a very specific task - transporting audio signals that would normally be destroyed by speech codecs over a packet network. This task is complex and exacting - requiring a powerful protocol such as RTP with multiple transport components to implement effectively. RFC 2833 should be used only by gateways to transport PSTN signaling between gateways, so PSTN traffic can be routed over a packet network. RFC 2833 is not the appropriate protocol for SIP-terminal-to-PSTN or SIP-terminal-to-SIP-terminal keystroke transport. 

2) When all you have is a simple remote-control device with a small screen and 15 buttons (no mike or speaker), RFC 2833 seems a fairly heavyweight protocol just to carry keystrokes over a SIP session to the controlled device. This is particularly true if the transmitting and receiving devices are both in the packet network. We would still like to use SIP as the session initiation, but we need s simple, reliable protocol for the keysroke transport. This is also suggested in section 3.1 of RFC2833. A similar requirement was discussed previously for application servers in a packet network that need just keystroke input. Perhaps SCTP?

3) If a SIP device in the packet network needs to recieve keystroke information from a device in the PSTN, the SIP device will use SDP to set up a keystroke session with the gateway that is a proxy for the PSTN device. The gateway will be responsible for converting DTMF signals into the simple keystroke protocol for the SIP device.

4) If a SIP device in the packet network needs to send keystroke information to a device in the PSTN, the gateway will use SDP to set up a keystroke session with the SIP device. The gateway will be responsible for converting the simple keysroke protocol from the SIP device into DTMF signals for the PSTN device.

So what are the requirements for a keystroke media transport protocol?

We need keystroke delivery reliability. You can imagine what would happen if, when the bank automation system asked you to type the amout of the bill payment, you typed $180, but it thought you said $980. Or, if the remote-controlled A/C heard 99 degrees instead of 79.

We need sequencing reliability. You can imagine what would happen if, when the bank automation system asked you to type the amout of the bill payment, you typed $180, but it thought you said $810. Or, if the remote-controlled A/C heard 97 degrees instead of 79.

We need simplicity. The simplicity of SIP will allow keystroke mechanisms to be placed on all kinds of ultra-simple wireless remote devices, as well as high-density keystroke-detection servers. These devices will not necessarily support any audio or video media. You need a simple, reliable protocol that doesn't take much processing power, yet meets all of the transport requirements.

We need duration. If the protocol is reliable, all you need is a key-on and key-off messages as a standard mechanism for all key indications.

We need standardization. Most devices with keys will probably have a numeric pad. When you press a 'one' key on the SIP phone, it should give the same key media message as when you press a 'one' key on a PC, or a Cell Phone, or a SIP-based remote control device. 

Now to the SIP List discussion:
Scott Petrack said: 
>"the point is not which one (keys or speech input) 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'.
Post archived at: http://lists.bell-labs.com/pipermail/sip/2000q3/002002.html
..........

Certainly, some applications (those that use a device that has both keys and a microphone) will want to give the user an option for speech or keys for user input. Other applications (that use a device with only keys, or only a mike, or that don't want to pay for speech recognition) will not want to give the user any options for input. The last part of Scott's statement is what I particularly disagree with. The information doesn't need to be encoded as "similarly as possible". How do you encode a single key event similarly to 5,000-10,000 bytes of audio? For that matter, why would you want to? 

Scott:
>What is relevant is that the INFORMATION to be encoded and
>transported is IDENTICAL, whether '1' is pressed or 'yes' is said.
http://lists.bell-labs.com/pipermail/sip/2000q3/002002.html

The application provider may elect to have the keystroke "1" mean "no" or "stop" or "begin launch sequence" or something else. How could you tell the device to make the keystroke "1"  give a response that is "identical" to some spoken word or phrase? This model could only be implemented if speech recognition was implemented in the terminal device AND there was some protocol to explain to the terminal that the phrase "begin launch sequence" should send the same message as pressing the "one" key. I don't think that all of the terminal providers are planning to embed speech recognition in their terminals, and I haven't seen any proposals for a protocol to provide a "matching" mechanism like this supposes. 

Wouldn't it just be easier to have the "one" key ALWAYS sent a "one-key-pressed" message when it was pressed, and the "two" key ALWAYS send a "two-key-pressed" message, no matter what kind of device you have? When a word or phrase is spoken into the microphone, wouldn't it be easier to just send the few-thousand bytes of data representing the speech, rather than trying to convert the thousands of bytes into a single "he-said-stop" or a "he-said-begin-launch-sequence" message? The application should sort this kind of stuff out, not the terminal device.
 
More from Scott's post........
>If you need the keypress to be transported along the signaling 
>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.

This depends highly on the application. In applications where you want keystroke/speech duality (every keystroke has an equivalent spoken phrase) your statement that both media types be sent along the same path has some validity. However this will be the exception, not the rule in future aplications. 

Keypads are useful for pre-defined entry and menu selection that require high reliability. Speech is useful for making selections across more than a few possibilities (what city are you going to?) where the utility is worth the lower reliability (more re-prompting) and higher cost of speech recognition. Applications that my company is developing today, use keys for input in certain situations, speech input for other situations, and "press-or-say-one" dual-input for even other situations. We certainly don't want the keypad to put out the same thing that the microphone does. 

In many cases, the two media types (speech & keystrokes) go to entirely different devices in the network for handling. The key-input-handling server can handle tens-of-thousands of simultaneous keypress event sessions. The voice recognition device can handle a few tens of simultaneous recognition sessions. I will tell the device to send its keystrokes to my keystroke server. I will tell the device to send its audio to one (of many) of my speech recognition servers. NO WAY should those different media-type streams be "in the same path". Or look the same.

More from Scott's post........
>After some DTMF, the session can be modified so that the call is
>transferred to another host which can handle the proper audio codecs.

No, I DON'T want to transfer the call to another host that can handle the proper codecs. I want to leave the key input session going to my key-input server, and I want to RE-INVITE just his AUDIO session to a speech recognition server, or to a different SIP endpoint to which I happen to have the port address. 

I will leave the key-input media session attached to the key-input server so the user can communicate via keystrokes to me, while I RE-INVITE his audio stream all over the place (multicast, multi-unicast, x-cast, you-name-it-cast) depending on the application. I don't wan't his keystrokes going all over the place, just like I don't want to see his audio coming to me.

Occasionally, I may set up an audio (or video) session with the caller to apprise him of his choices he has with the key input. Or I may set up a second audio channel (first channel is going to some other participant) to my speech reco server so he can speak his choices rather than using key input. Whatever fits the application best.

Henning Schulzrinne says:
>It's not that I think that key(board) input will go away, just that it
>won't be 12 buttons with numbers and */#.
>Post archived at:  http://lists.bell-labs.com/pipermail/sip/2000q3/001991.html

You're right. Keyboards will come in all shapes an sizes. There will be 300-key Katakana keyboards. There will be Braille keyboards. There will be 101 key keyboards. there will be European keyboards. There will be 20 key- keyboards, there will be 12-key keboards. There will be keyboards with only one BIG key smack in the middle. There will be soft keyboards that will allow you to specify the number of keys and the labels for each one (using SIP perhaps?).  

Not all of these devices will want or need speech recogniton. However, unless the device is single-functioned, ALL of these devices must have SOME way for a user to indicate a 10-digit phone number or a URL for addressing purposes. 

Some devices will use speech recognition for addressing. Some will not. Those that can't or won't accept the costs of speech reco will still have to have some method of indicating an address at a minimum. I will be willing to bet that that method will include at a minimum, a set of 10 numeric keys and an ENTER and DELETE (or equivalent) button. The keyboard may have a thousand other keys, but it WILL have numerics.

I expect that any device that can connect to the public data network will require a minimum 12-key numeric pad to indicate addresses, although alpha URLs would be a problem. I expect that popular websites will start adding 10-numeric-digit URLs to allow portable devices to enable access from simple wireless devices. Portable devices that don't want to use speech recognition, will invaribly have keys. The 12-digit keypad will be with us for a long time, I think.

More Henning Schulzrinne:
>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.

Why tie keys to SIP? Because keystrokes are a terminal media element just like video or audio. Video & Audio are in SIP. Perhaps we should ask, why were keystrokes left out of SIP? Or a better question, why is there not a keystroke media session defined in SDP like there is for audio & video? RFC 2833 could be considered a first pass at the definition of a keystroke transport mechanism. Perhaps this discussion should be taking place in the SDP working group.

Henning:
>I don't want to SUBSCRIBE to the keyboard 

Neither do I. I want a SDP SESSION for that keyboard, just like I have a SDP session to a microphone and an SDP session to a video camera. I don't want a SUBCRIBE or NOTIFY mechanism for keystokes. Nor do I want to send keystrokes in the InfoMethod message. I want to be able to multicast, unicast, re-invite keystroke sessions just like you do audio and video. SUBSCRIBE & InfoMethod can't multi-unicast my keystrokes.

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

I don't know how you would re-invite a telnet session, or request a multi-unicast of the telnet session. In any case, my simple wireless remote control already has SIP on it to locate the refrigerator in my house over the public data network. No reason to put the Telnet protocol on that little thing if all I need is a simple keystroke to be sent to the refrigerator. Just SDP-up a keystroke session with the refrigerator, and set the temp to 38 degrees.

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

Agreed. There is no doubt that RFC 2833 has the capability to be a keystroke transport protocol. It has some of the appropriate charateristics. The main plus for RFC 2833 is that it is an SDP session! This means that it can be stopped, re-directed, multi-unicasted, and all of the useful things that we want to do with keystrokes. It also, with the addition of a reliability mechanism, could become a reliable transport.

The real questions are: Is RFC 2833 the appropriate protocol to send keystrokes in a packet network? 

Is RFC 2198, which is proposed as a potential mechanism for reliable delivery of keystrokes in RFC 2833, REALLY reliable enough? 

Is the processing overhead required for implementing RFC 2833 and RFC 2198 appropriate for a simple remote key entry device that just needs a simple, reliable keystroke delivery mecahnism? That device doesn't have audio, no synchronization requirements, no RTCP, just reliable keys.

Is RFC 2833 appropriate for a high density keystroke server (see above)?

Will RFC 2833 let me tell a device that is sending me audio and keystrokes, to stop sending me audio but keep sending keystrokes (or vice-versa)? I can certainly tell a device that is sending me audio and video to stop sending me one, but keep sending me the other, using re-invite. Shouldn't the mechanism for both of these start-stop procedures be the same (re-invite a media session)?
 
Can you use RFC 2833 to send keystrokes to one place, and audio three (different) place?
 
Can you use RFC 2833 be used to send audio one place, and keystrokes three (different) places?  

So, these are the issues.

Stay Tuned.

Skip Cave
Sr. Principal Engineer 
InterVoice-Brite Inc.

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

---

From: Colin Perkins <[email-masked]>
Date: Thu, 10 Aug 2000 15:31:00 -0400

--> Skip Cave writes:
>Henning S. And Scott P. have made some interesting comments to my post. Before 
>I go about addressing their issues directly, I would like to make a few comments.
...

Without wishing to get into the details of this post, I would point people
at RFC 2793 "RTP Payload for Text Conversation" which may be relevent.

Colin

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 10 Aug 2000 14:53:21 -0500

For whatever it is worth, some of this stuff is already getting
to market:
"ReplayTV uses Internet as remote control "
http://news.cnet.com/news/0-1006-200-2479544.html?tag=st.ne.1002
.bgif.ni

Henry

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]]On Behalf Of Skip Cave
>Sent: Thursday, August 10, 2000 1:46 PM
>To: [email-masked]
>Cc: [email-masked]
>Subject: Re: [SIP] DTMF and Universal Key Input
>
>
>Henning S. And Scott P. have made some interesting
>comments to my post. Before I go about addressing
>their issues directly, I would like to make a few comments.
>
>For user input:
>In the future, there will be SIP terminals that only
>have some sort of weird detector (wink detector?
>emotion detector?) that we can't imagine.
>In the future, there will be SIP terminals that have
>all sorts of combibations of the above user input devices.
>
>And for user output:
>In the future, there will be SIP terminals that only
>have some sort of weird output mechanism (telepathy?
>brain socket connection?) that we can't imagine.
>In the future, there will be SIP terminals that have
>all sorts of combibations of the above user output devices.
>
>For Control:
>In the future, there will be SIP UAs that reside in
>refrigerators and let you set the tempreature & find
>out if the door is open from anywhere. They will also
>let you know what the tempeature in your refrigierator
>is, and if the temperature drops below a limit you
>set, or if the supply voltage is low.
>
>In the future, there will be SIP UAs that reside in
>your home air conditioner that let you set the
>tempreature in your house, & find out if your door is
>open from anywhere. They will also let you know what
>the temperature in your house is, and if the
>temperature drops below a limit you set, or if the A/C
>supply voltage is low.
>
>In the future, there will be SIP UAs that reside in a
>baby monitor that let you hear, see, and smell your
>baby from anywhere. You will be able to talk to your
>baby and pehaps the baby will even be able to see (and
>smell?) you. keys on the remote monotor will help
>control the camera. There probably won't be any keys
>on the baby's terminal.
>
>Of course, someone will have to figure out what a SIP
>"Universal Remote Control" will look like, to control
>all of these various gizmos, but that is a topic for
>another discussion.
>
>The point is, that we cannot (and should not) know all
>of the kinds of media that SIP will be required to
>support today. We only need a mechanism to add new
>media types as necessary. Luckily, we already have
>that mechanism. It is called SDP. Now, we only need to
>define the media types we DO know today.
>
>Audio, Video, Keystrokes. These three media types are
>clearly widely used today, so a specific SDP session
>should be defined for each of these media. Luckily,
>two of the three have already been done. SDP already
>has definitions for video and audio sessions.
>
>An important point here. We shouldn't try and combine
>different media types in one session. A single SDP
>session is intended for a single type of media. To be
>specific, we should not combine Video & Audio in a
>single session. We shouldn't combine Video and
>Keystrokes in a single session. We should not combine
>Audio and Keystrokes in a single session.
>
>There is an important rationale behind this
>requirement. In an ideal world, there would be a
>method for determining the capabilities of a SIP
>terminal. A SIP UA could ask another UA just what
>capabilities it has. Some of the things you should be
>able to determine:
>If it is a human-interface device, then you should be
>able to determine what user input mechanisms it supports.
>If it is a human-interface device, then you should be
>able to determine what user output mechanisms it supports.
>Does it have Audio output capability (speakers)? If
>so, how many? What audio decoders are supported?
>Does it have Video output (screens)? If so, what
>resolution and how many? What video decoders are supported?
>Unfortunately, SIP does not allow an explicit
>pre-determination of terminal capabilities today.
>However, it does have a try-and-see-if-it-works kind
>of determination, which is good enough for now.
>
>The reason that you only want one media type per
>session is because when you use SDP to explicitly
>set-up a media session with a UA, that act implicitly
>"turns on" that specific media device. Therefore, when
>you use SDP to set-up a transmit audio channel from
>the remote device, you are essentially telling the
>microphone in that device to start transmitting it's
>output on that session. When you use SDP to set-up a
>transmit video channel from the remote device, you are
>essentially telling the video camera in that device to
>start transmitting it's output on that session. When
>you use SDP to set-up a keystroke session on a remote
>device, you are telling the remote device to start
>transmitting keystrokes from the keyboard on that session.
>
>A terminal may have video, audio, and keys as
>potential user input mechanisms. For whatever reason,
>an application may only want to get audio from a
>terminal. The application may not care anything about
>the video or keystrokes. You don't want to force the
>application to receive video and audio when all it
>wanted was audio. You don't want to force the
>application to receive audio and keystrokes when all
>it wanted was keystrokes.
>
>If you turn off a session, you turn off the audio,
>video, or keystroke transmitter driving that session.
>If two or more media types are combined in a single
>session, you restrict the capabilities of the
>application. If both audio and video are in a single
>session,  you won't be able to "turn on or off" only
>one media type . When you setup the combined channel,
>you essentially turn on both media transmitters. You
>can only turn on both the audio and video
>transmitters, not either individually.
>
>The same argument goes for keystrokes and audio. You
>should be able to set up a session that only carried
>keystrokes, or only audio. Otherwise, you prevent the
>application from efficiently dealing with it's requirements.
>This promotes bandwidth conservation. It also helps
>simplify applications. If you don't want the media,
>don't set up the session!
>
>Probably even more importantly, the application may
>require that audio, video and keystrokes to go to
>different places! This requirement will be key in
>implementing advanced applications, and if the media
>are all lumped together in one channel, you can't send
>them different places. There are lots of applications
>even today that need the keystrokes and the audio to
>go different places. Some applications just want the
>keystokes and nothing else. Some want video and
>nothing else. I have applications where I want a
>terminal's keystrokes to go one place, and the audio
>to go to three different places. I can conceive of
>applications where the audio goes one place, and the
>keystrokes go three different places.
>
>RFC 2833 specifies a method for combining DTMF tones
>(PSTN-specific keystrokes), an audio session, and
>other PSTN signaling events such as ringing and busy
>tones, in a single RTP session. While this
>architecture is good for the person that just wants to
>transport EVERYTHING that's in a PSTN session from one
>gateway to another, It may NOT be ok for those who
>want to implement general applications in the packet network.
>
>Of course, we all know the problem that RFC 2833 is
>trying to address. The current low-data-rate (LDR)
>audio codecs (G.732 &G.729 to be specific) were not
>designed to accurately encode tones. These codecs were
>designed with a perceptual model of the human voice in
>mind. If the listener can understand the un-encoded
>speech, the codec was judged a success. None of the
>current crop of codecs will convert DTMF or other PSTN
>tones with enough accuracy to allow automatic
>detectors to reliably extract the original tones from
>the encoded/decoded audio stream.
>
>These LDR codecs are being used to transport voice
>traffic over the packet network. However, with the LDR
>codecs, the end-to-end keystrokes were getting
>distorted to the point that they couldn't be detected!
>Many applications in the PSTN rely on the presence of
>DTMF in-band, end-to-end signaling, so the network
>engineers had to come up with a solution.
>
>To solve this problem, packet network engineers
>logically decided to take the tones "out-of-band", or
>at least out of the G.723/729 codec's "band". However,
>The out-of-band tones must have enough information to
>reconstruct a reasonably intact G.711 PCM waveform out
>of the LDR speech codec data, and the out-of-band tone
>data. The reconstructed G.711 data needed to be both
>legible to the human listener and with the correct
>tones for the automatic tone detectors in the PSTN.
>
>Transporting PSTN signaling over packet networks isn't
>a new problem. The H.323 protocol addressed this issue
>with the UserInputIntication messages in the H.245
>session. The RFC 2833 designers have done even a
>better job of designing a solution to the PSTN
>transport problem, using RFC 2833.
>
>This DTMF transport problem sort of LOOKS like the
>keystroke-as-media problem that I have been
>describing. However there are significant differences
>in the requirements (and hence differences in the
>potential solutions) in the two problems.
>
>The key differences:
>
>Audio or not?
>RFC 2833 focuses on transporting DTMF signals over a
>packet network for re-construction of the tones in the
>PSTN. RFC 2833 assumes that the stuff it will be
>carying are still audio signals, but just special
>types. Also, it is assumed that the stuff will all
>eventually have to be re-combined, hopefully with
>nearly the same charateristics as the original
>waveform. As such, detailed information about the tone
>frequencies, levels, duration, cadence, and time
>reference to the concurrent audio stream, are all
>required to be in the transported data.
>
>For keystrokes-as-media, the assumption is that the
>keystrokes are just that - keystrokes. No tones, no
>freqencies, no levels, no requirements for
>resynchronization, just which key was pressed. At the
>most, you may need a duration indication (key-on,
>key-off), but this charateristic would depend on
>whether the terminal device supported key duration.
>
>"If an end system is directly connected to the
>Internet and does not need to generate tone signals
>again, time alignment and power levels are not
>relevant. These systems rely on PSTN gateways or
>Internet end systems to generate DTMF events and do
>not perform their own audio waveform analysis. An
>example of such a system is an Internet interactive
>voice-response (IVR) system.
>
>In circumstances where exact timing alignment between
>the audio stream and the DTMF digits or other events
>is not important and data is sent unicast, such as the
>IVR example mentioned earlier, IT MAY BE PREFERABLE TO
>USE A RELIABLE CONTROL PROTOCOL RATHER THAN RTP
>PACKETS (my caps). In those circumstances, this
>payload format would not be used."
>
>So according to the authors of RFC 2833, the DTMF in
>RTP scheme they define isn't necessarily the best
>protocol to carry events such as standard keystrokes
>that don't need to be time-aligned, or have specific
>power levels or have frequencies.
>
>Terminal Generalization:
>RFC 2833 assumes that the originating device is a PSTN
>phone (no self-respecting packet terminal would
>generate tones when it's keys were pressed). 2833
>doesn't address the issue of what happens when someone
>presses the keys on a SIP terminal, or a PC running a
>SIP session. Well, it DOES say something on the subject:
>
>"(By using RFC 2833) an Internet end system such as an
>"Internet phone" can emulate DTMF functionality
>without concerning itself with generating precise tone
>pairs and without imposing the burden of tone
>recognition on the receiver."
>
>So RFC 2833 recognizes the fact that a SIP terminal
>could send RFC 2833-compliant RTP streams to a PSTN
>device (presumably through a gateway), if it needs to
>really tightly control the delivery of the tones. The
>device would then rely on the gateway to generate the
>actual tones in the PSTN. Of course, if the packet
>device DIDN'T need to tightly control the key input
>presented to a PSTN device, and it DIDN't need precice
>synchronization with an audio stream, it potentially
>could use a much simpler key input protocol to send
>keystrokes to the gateway.
>
>What should be done when a SIP terminal is connected
>to another SIP device, and all they want to do is send
>keystrokes back and forth? This will be a common
>requirement where the device is a SIP UA in a
>remote-controlled appliance that only needs keystrokes
>for control. Should we use RFC 2833 to send the
>keystrokes from the control device to the remote appliance?
>
>This means you need the RTP protocol. You need to
>calculate RTSP stats. You need sequence numbers and
>time stamp alignment with the RTP audio (remember,
>there isn't any audio in this application). You need
>to repeat the keystroke packet every 50ms until the
>key is released. What happens if the keystroke
>duration is unknown (or is a don't care)? How do you
>implement redundancy when the keystroke duration is
>less than the repeat rate?  Do we need all this stuff
>just to get keystrokes?
>
>Probably the most common keystroke scenario today is a
>person interacting with a IVR (Interactive Voice
>Response) system. In the PSTN, you automatically get a
>two-way audio connection when you connect a call.
>However, in most of the today's IVR scenarios, the IVR
>only needs an audio path FROM the IVR TO the caller,
>to deliver prompts. The IVR doesn't care about audio
>coming from the caller. It can do without it. All it
>cares about is what keys the caller presses.
>
>In the PSTN, the audio is delivered to the IVR systems
>whether they wanted it or not, since that was the only
>way that keystrokes (DTMF) could get to the IVR. In a
>packet network, the application server should have the
>option to NOT have audio delivered to it - just
>keystrokes. This would save bandwidth in the network,
>and save protocol processing horsepower on the IVR/server.
>
>Now, just because the IVR system doesn't need to see
>the audio stream doesn't mean that the caller won't be
>transmitting audio streams. Many applications (calling
>card, conferences) will have the caller's terminal
>sending its audio to other places, just not to the
>IVR. Or, the caller may need to send his audio AND
>keystrokes to the IVR, but just audio (no keystrokes)
>to other places. Or the keystrokes need to go other
>places. Or, Or, Or.
>
>In the above example, the IVR/server in the network
>may handle thousands of SIP sessions, but all of them
>could be just keystroke input sessions. This occurs
>any time the application server is the control node
>for applications that involve large numbers of two or
>three-way calls (calling card, find-me, record/log,
>etc.). The application server doesn't actually need
>any of the audio or video streams, as the audio &
>video streams are going to the various participants as
>they communicate with each other. However the server
>needs to know about all of the keystrokes from any of
>the participants, as that is the method that this
>application uses to let the participants indicate what
>function is to be performed by the application.
>
>In this scenario, you don't want too heavyweight of a
>protocol for the keystrokes, as that will limit the
>number of keystroke sessions that a single server
>could handle. The simpler the keystroke protocol, the
>more sessions a single server could handle. If I DO
>need to receive audio for recording or speech
>recognition purposes, I will probably send that stream
>to some other device (media recording/storage server,
>speech regognition server) in the network, not the
>keystroke server.
>
>The important issue here is that applications residing
>in the packet network should be able to get simple
>keystroke media messages (no frequencies, no levels,
>no timestamps) from the devices on the other end of
>the SIP session whether the originator of the
>keystroke was a SIP terminal, A SIP phone, a SIP
>remote controller, a PC, or a PSTN phone. It should't
>be a requirement for the device to support audio or
>video streams just to send keystrokes.
>
>So, in summary:
>1) RFC 2833 is intended for a very specific task -
>transporting audio signals that would normally be
>destroyed by speech codecs over a packet network. This
>task is complex and exacting - requiring a powerful
>protocol such as RTP with multiple transport
>components to implement effectively. RFC 2833 should
>be used only by gateways to transport PSTN signaling
>between gateways, so PSTN traffic can be routed over a
>packet network. RFC 2833 is not the appropriate
>protocol for SIP-terminal-to-PSTN or
>SIP-terminal-to-SIP-terminal keystroke transport.
>
>2) When all you have is a simple remote-control device
>with a small screen and 15 buttons (no mike or
>speaker), RFC 2833 seems a fairly heavyweight protocol
>just to carry keystrokes over a SIP session to the
>controlled device. This is particularly true if the
>transmitting and receiving devices are both in the
>packet network. We would still like to use SIP as the
>session initiation, but we need s simple, reliable
>protocol for the keysroke transport. This is also
>suggested in section 3.1 of RFC2833. A similar
>requirement was discussed previously for application
>servers in a packet network that need just keystroke
>input. Perhaps SCTP?
>
>3) If a SIP device in the packet network needs to
>recieve keystroke information from a device in the
>PSTN, the SIP device will use SDP to set up a
>keystroke session with the gateway that is a proxy for
>the PSTN device. The gateway will be responsible for
>converting DTMF signals into the simple keystroke
>protocol for the SIP device.
>
>4) If a SIP device in the packet network needs to send
>keystroke information to a device in the PSTN, the
>gateway will use SDP to set up a keystroke session
>with the SIP device. The gateway will be responsible
>for converting the simple keysroke protocol from the
>SIP device into DTMF signals for the PSTN device.
>
>We need keystroke delivery reliability. You can
>imagine what would happen if, when the bank automation
>system asked you to type the amout of the bill
>payment, you typed $180, but it thought you said $980.
>Or, if the remote-controlled A/C heard 99 degrees
>instead of 79.
>
>We need sequencing reliability. You can imagine what
>would happen if, when the bank automation system asked
>you to type the amout of the bill payment, you typed
>$180, but it thought you said $810. Or, if the
>remote-controlled A/C heard 97 degrees instead of 79.
>
>We need simplicity. The simplicity of SIP will allow
>keystroke mechanisms to be placed on all kinds of
>ultra-simple wireless remote devices, as well as
>high-density keystroke-detection servers. These
>devices will not necessarily support any audio or
>video media. You need a simple, reliable protocol that
>doesn't take much processing power, yet meets all of
>the transport requirements.
>
>We need duration. If the protocol is reliable, all you
>need is a key-on and key-off messages as a standard
>mechanism for all key indications.
>
>We need standardization. Most devices with keys will
>probably have a numeric pad. When you press a 'one'
>key on the SIP phone, it should give the same key
>media message as when you press a 'one' key on a PC,
>or a Cell Phone, or a SIP-based remote control device.
>
>
>Post archived at:
>Certainly, some applications (those that use a device
>that has both keys and a microphone) will want to give
>the user an option for speech or keys for user input.
>Other applications (that use a device with only keys,
>or only a mike, or that don't want to pay for speech
>recognition) will not want to give the user any
>options for input. The last part of Scott's statement
>is what I particularly disagree with. The information
>doesn't need to be encoded as "similarly as possible".
>How do you encode a single key event similarly to
>5,000-10,000 bytes of audio? For that matter, why
>would you want to?
>
>Scott:
>The application provider may elect to have the
>keystroke "1" mean "no" or "stop" or "begin launch
>sequence" or something else. How could you tell the
>device to make the keystroke "1"  give a response that
>is "identical" to some spoken word or phrase? This
>model could only be implemented if speech recognition
>was implemented in the terminal device AND there was
>some protocol to explain to the terminal that the
>phrase "begin launch sequence" should send the same
>message as pressing the "one" key. I don't think that
>all of the terminal providers are planning to embed
>speech recognition in their terminals, and I haven't
>seen any proposals for a protocol to provide a
>"matching" mechanism like this supposes.
>
>Wouldn't it just be easier to have the "one" key
>ALWAYS sent a "one-key-pressed" message when it was
>pressed, and the "two" key ALWAYS send a
>"two-key-pressed" message, no matter what kind of
>device you have? When a word or phrase is spoken into
>the microphone, wouldn't it be easier to just send the
>few-thousand bytes of data representing the speech,
>rather than trying to convert the thousands of bytes
>into a single "he-said-stop" or a
>"he-said-begin-launch-sequence" message? The
>application should sort this kind of stuff out, not
>the terminal device.
>
>This depends highly on the application. In
>applications where you want keystroke/speech duality
>(every keystroke has an equivalent spoken phrase) your
>statement that both media types be sent along the same
>path has some validity. However this will be the
>exception, not the rule in future aplications.
>
>Keypads are useful for pre-defined entry and menu
>selection that require high reliability. Speech is
>useful for making selections across more than a few
>possibilities (what city are you going to?) where the
>utility is worth the lower reliability (more
>re-prompting) and higher cost of speech recognition.
>Applications that my company is developing today, use
>keys for input in certain situations, speech input for
>other situations, and "press-or-say-one" dual-input
>for even other situations. We certainly don't want the
>keypad to put out the same thing that the microphone does.
>
>In many cases, the two media types (speech &
>keystrokes) go to entirely different devices in the
>network for handling. The key-input-handling server
>can handle tens-of-thousands of simultaneous keypress
>event sessions. The voice recognition device can
>handle a few tens of simultaneous recognition
>sessions. I will tell the device to send its
>keystrokes to my keystroke server. I will tell the
>device to send its audio to one (of many) of my speech
>recognition servers. NO WAY should those different
>media-type streams be "in the same path". Or look the same.
>
>No, I DON'T want to transfer the call to another host
>that can handle the proper codecs. I want to leave the
>key input session going to my key-input server, and I
>want to RE-INVITE just his AUDIO session to a speech
>recognition server, or to a different SIP endpoint to
>which I happen to have the port address.
>
>I will leave the key-input media session attached to
>the key-input server so the user can communicate via
>keystrokes to me, while I RE-INVITE his audio stream
>all over the place (multicast, multi-unicast, x-cast,
>you-name-it-cast) depending on the application. I
>don't wan't his keystrokes going all over the place,
>just like I don't want to see his audio coming to me.
>
>Occasionally, I may set up an audio (or video) session
>with the caller to apprise him of his choices he has
>with the key input. Or I may set up a second audio
>channel (first channel is going to some other
>participant) to my speech reco server so he can speak
>his choices rather than using key input. Whatever fits
>the application best.
>
>>Post archived at:
>http://lists.bell-labs.com/pipermail/sip/2000q3/001991.html
>
>You're right. Keyboards will come in all shapes an
>sizes. There will be 300-key Katakana keyboards. There
>will be Braille keyboards. There will be 101 key
>keyboards. there will be European keyboards. There
>will be 20 key- keyboards, there will be 12-key
>keboards. There will be keyboards with only one BIG
>key smack in the middle. There will be soft keyboards
>that will allow you to specify the number of keys and
>the labels for each one (using SIP perhaps?).
>
>Not all of these devices will want or need speech
>recogniton. However, unless the device is
>single-functioned, ALL of these devices must have SOME
>way for a user to indicate a 10-digit phone number or
>a URL for addressing purposes.
>
>Some devices will use speech recognition for
>addressing. Some will not. Those that can't or won't
>accept the costs of speech reco will still have to
>have some method of indicating an address at a
>minimum. I will be willing to bet that that method
>will include at a minimum, a set of 10 numeric keys
>and an ENTER and DELETE (or equivalent) button. The
>keyboard may have a thousand other keys, but it WILL
>have numerics.
>
>I expect that any device that can connect to the
>public data network will require a minimum 12-key
>numeric pad to indicate addresses, although alpha URLs
>would be a problem. I expect that popular websites
>will start adding 10-numeric-digit URLs to allow
>portable devices to enable access from simple wireless
>devices. Portable devices that don't want to use
>speech recognition, will invaribly have keys. The
>12-digit keypad will be with us for a long time, I think.
>
>Why tie keys to SIP? Because keystrokes are a terminal
>media element just like video or audio. Video & Audio
>are in SIP. Perhaps we should ask, why were keystrokes
>left out of SIP? Or a better question, why is there
>not a keystroke media session defined in SDP like
>there is for audio & video? RFC 2833 could be
>considered a first pass at the definition of a
>keystroke transport mechanism. Perhaps this discussion
>should be taking place in the SDP working group.
>
>Henning:
>Neither do I. I want a SDP SESSION for that keyboard,
>just like I have a SDP session to a microphone and an
>SDP session to a video camera. I don't want a SUBCRIBE
>or NOTIFY mechanism for keystokes. Nor do I want to
>send keystrokes in the InfoMethod message. I want to
>be able to multicast, unicast, re-invite keystroke
>sessions just like you do audio and video. SUBSCRIBE &
>InfoMethod can't multi-unicast my keystrokes.
>
>Henning:
>I don't know how you would re-invite a telnet session,
>or request a multi-unicast of the telnet session. In
>any case, my simple wireless remote control already
>has SIP on it to locate the refrigerator in my house
>over the public data network. No reason to put the
>Telnet protocol on that little thing if all I need is
>a simple keystroke to be sent to the refrigerator.
>Just SDP-up a keystroke session with the refrigerator,
>and set the temp to 38 degrees.
>
>Henning:
>Agreed. There is no doubt that RFC 2833 has the
>capability to be a keystroke transport protocol. It
>has some of the appropriate charateristics. The main
>plus for RFC 2833 is that it is an SDP session! This
>means that it can be stopped, re-directed,
>multi-unicasted, and all of the useful things that we
>want to do with keystrokes. It also, with the addition
>of a reliability mechanism, could become a reliable transport.
>
>The real questions are: Is RFC 2833 the appropriate
>protocol to send keystrokes in a packet network?
>
>Is RFC 2198, which is proposed as a potential
>mechanism for reliable delivery of keystrokes in RFC
>2833, REALLY reliable enough?
>
>Is the processing overhead required for implementing
>RFC 2833 and RFC 2198 appropriate for a simple remote
>key entry device that just needs a simple, reliable
>keystroke delivery mecahnism? That device doesn't have
>audio, no synchronization requirements, no RTCP, just
>reliable keys.
>
>Will RFC 2833 let me tell a device that is sending me
>audio and keystrokes, to stop sending me audio but
>keep sending keystrokes (or vice-versa)? I can
>certainly tell a device that is sending me audio and
>video to stop sending me one, but keep sending me the
>other, using re-invite. Shouldn't the mechanism for
>both of these start-stop procedures be the same
>(re-invite a media session)?
>

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 10 Aug 2000 17:58:09 -0700

At 11:45 AM 8/10/00 , Skip Cave wrote:
>So, in summary:
>1) RFC 2833 is intended for a very specific task - transporting audio 
>signals that would normally be destroyed by speech codecs over a packet 
>network. This task is complex and exacting - requiring a powerful protocol 
>such as RTP with multiple transport components to implement effectively. 
>RFC 2833 should be used only by gateways to transport PSTN signaling 
>between gateways, so PSTN traffic can be routed over a packet network. RFC 
>2833 is not the appropriate protocol for SIP-terminal-to-PSTN or 

Why shouldn't SIP UA to PSTN interworking use RFC 2833?  The requirements 
for DTMF "events" synched with audio are the same.  I haven't seen a single 
good argument why SIP UA with an active audio stream with a PSTN gateway 
shouldn't use RFC 2833.

>2) When all you have is a simple remote-control device with a small screen 
>and 15 buttons (no mike or speaker), RFC 2833 seems a fairly heavyweight 
>protocol just to carry keystrokes over a SIP session to the controlled 
>device. This is particularly true if the transmitting and receiving 
>devices are both in the packet network. We would still like to use SIP as 
>the session initiation, but we need s simple, reliable protocol for the 
>keysroke transport. This is also suggested in section 3.1 of RFC2833. A 
>similar requirement was discussed previously for application servers in a 
>packet network that need just keystroke input. Perhaps SCTP?

hmm,  buttons and a display, sounds like a web browser to me, and very much 
out of the scope of the Session Initiation Protocol.

>3) If a SIP device in the packet network needs to recieve keystroke 
>information from a device in the PSTN, the SIP device will use SDP to set 
>up a keystroke session with the gateway that is a proxy for the PSTN 
>device. The gateway will be responsible for converting DTMF signals into 
>the simple keystroke protocol for the SIP device.

How is this simpler than using RFC 2283?

With AVT, you just receive the RTP packet, figure out what the associated 
DTMF is, and optionally check that the length/volume is above a threshold.

>4) If a SIP device in the packet network needs to send keystroke 
>information to a device in the PSTN, the gateway will use SDP to set up a 
>keystroke session with the SIP device. The gateway will be responsible for 
>converting the simple keysroke protocol from the SIP device into DTMF 
>signals for the PSTN device.

Again, how is this simpler?

With AVT, just send the packet with a default duration and volume.

If all you are saying is that RFC 2283 is hard, and that you want to build 
a new protocol do transport keystrokes, or DTMF events, I sincerely doubt 
you will be able to convince me that building, documenting, and testing 
this new protocol is *easier* than just implementing

>So what are the requirements for a keystroke media transport protocol?

Has anyone thought about why we really want *raw* keyboard input?  It 
sounds like what you really want, is something like VoXML.  Send a document 
that associates certain collections of input (keyboard, DTMF, voice, 
smell-detector, etc) with some action or URL.

Based on your examples, I could send a document to my phone which 
represents an IVR tree, and after navigating through 7-layers of IVR hell, 
it executes the right URL (which refers me to an appropriate agent).

Likewise, I could collect the desired temperature of my house, and then 
send a HTTP POST with the collected data to my home control system.

Before anyone chides me for being insensitive to the processing/memory 
requirements of portable devices, I think this is quite reasonable on 
devices with 1MB of RAM or less.

Thoughts,

thanks,
-rohan

>We need keystroke delivery reliability. You can imagine what would happen 
>if, when the bank automation system asked you to type the amout of the 
>bill payment, you typed $180, but it thought you said $980. Or, if the 
>remote-controlled A/C heard 99 degrees instead of 79.
>
>We need sequencing reliability. You can imagine what would happen if, when 
>the bank automation system asked you to type the amout of the bill 
>payment, you typed $180, but it thought you said $810. Or, if the 
>We need simplicity. The simplicity of SIP will allow keystroke mechanisms 
>to be placed on all kinds of ultra-simple wireless remote devices, as well 
>as high-density keystroke-detection servers. These devices will not 
>necessarily support any audio or video media. You need a simple, reliable 
>protocol that doesn't take much processing power, yet meets all of the 
>transport requirements.
>
>We need duration. If the protocol is reliable, all you need is a key-on 
>and key-off messages as a standard mechanism for all key indications.
>
>We need standardization. Most devices with keys will probably have a 
>numeric pad. When you press a 'one' key on the SIP phone, it should give 
>the same key media message as when you press a 'one' key on a PC, or a 
>Cell Phone, or a SIP-based remote control device.