Subject: [SIP] DTMF and Universal Input

From: Skip Cave <[email-masked]>
Date: Fri, 11 Aug 2000 03:47:41 -0500

Henning Schulzrinne said:
>Besides the philosophical arguments, can somebody please succinctly and

>technically characterize why RTP transport of digits does not work or
is
>not sufficient?
http://lists.bell-labs.com/pipermail/sip/2000q3/002087.html

Skip says:
I will try to answer Henning and summarize my issues with RFC 2833.

Probably the most important issue is the requirement for a user agent
server in the network to redirect and replicate keystroke sessions just
as it would redirect and replicate audio or video streams.

Lets take this scenario:

1) A UA client (Term1) INVITES a UA server (Term2) and establishes an
audio session, a keystroke session, and a video session between Term1
and Term2 using SDP. Term1 is the transmitter of the media (keystrokes,
audio, video) in all three sessions. Term2 is the receiver of all media
in all sessions.

2) Term2 wishes to redirect Term1's audio media stream to a third party,
a UA server called Term3. Term2 RE-INVITES Term1's audio session to go
to Term3's port. However, the keystroke and video sessions transmitting
from Term1 to Term2 are NOT to be disturbed. We only want to redirect
Term1's audio session to Term3. All other sessions are to be left alone.
If audio and keystrokes are in the same SDP session, how do we do this?
Keystrokes need to have their own session in this scenario. RFC 2833
puts both media types in one session.

3) After we finish redirecting Term1's audio to Term3, we decide that a
fourth party needs to be involved (Term4). We want both Term1's audio
and Term1's keystrokes to be sent to Term4, but we DON'T want to disturb
the keystrokes and video going from 1-2, or the audio going from 1-3.
Term2 re-invites Term1 again, asking Term1 to replicate his keystroke
session and send a copy of the keystroke session to Term4. Term1 is now
essentially multi-unicasting his keystroke session to both Term2 and
Term4. Similarly, in the re-invite we ask Term1 to multi-unicast his
audio to Term2 and Term4. If audio and keystrokes are in the same SDP
session, how do we do this? Keystrokes need to have their own session in
this scenario.

I can go on in this vein, but you get the idea. Why do we require
keystrokes to be in the same session as the audio? Why did we pick the
audio session instead of the video session to carry keystrokes? Better
yet, why not give keystrokes their own session permanently. This makes
the above senarios much simpler, and doesn't affect the PSTN-PSTN
transport problem, other than you need two SDP sessions (tones and
audio)for that particular requirement. Simply modify RFC 2833 to require
two sessions - one for keystrokes and signaling, and one for voice
audio. Now you can treat them as the separate entities they really are,
and not a hybrid construct that is specific to the PSTN. I haven't heard
any reasons why this isn't a better solution.

Henning Schulzrinne said:
>As a side note, I'm still not sure how useful this audio/DTMF split is
>in practice, given the wide use of voice recognition.
http://lists.bell-labs.com/pipermail/sip/2000q3/001933.html

As I have tried to point out in my previous posts, not every application
vendor will want to use voice recognition on every application. there
are many applications where speech recognition is not appropriate, and
could even be detrimental. There are many applications that send
keystrokes in one direction and voice in the other (IVR), and these
types of applications are becoming MORE popular, not less. Most
important, virtually all of the applications my company is implementing
need keystrokes from a caller to go one place, and audio from a caller
to go to another (or many other places).

Henning Schulzrinne said:
>not all end systems will implement anything beyond basic 2833, in
>practice you'll end up with trivial 'RTP splitters' that route DTMF
>packets to one server and audio to another.
http://lists.bell-labs.com/pipermail/sip/2000q3/001933.html

Actually, that is my key point. in order to enable applications like the
one described above, the split between keystrokes and tones NEEDS TO BE
IN THE BASE RFC 2833 DOCUMENT. Otherwise you need splitters, or other
nefarious devices to implement most applications. We don't need
splitters for sending audio two places. Why would we require a splitter
to send audio one place and keystrokes another? Just reinvite a separate
keystroke session.

Henning Schulzrinne said:
>Finally (separate issue), I just don't see that there is a practical
>difference between DTMF and 'user input'. User input is just a subset
of
>DTMF (minus loudness). Hopefully, both will disappear over time, as
user
>devices have richer input capability. We don't want to redo
>telnet/rlogin or X11 in SIP.
http://lists.bell-labs.com/pipermail/sip/2000q3/001933.html

I agree, at least about the issue of DTMF and user input being similar
(assuming you mean keystrokes). I don't agree about the keys
dissapearing over time (See my post about addressing)

Skip said:
>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.
http://lists.bell-labs.com/pipermail/sip/2000q3/002083.html

So perhaps DTMF and user keystroke input can be considered similar
enough that we could use a single protocol to transport both types of
things. Fair enough. We can default things like level or frequency or
time stamps when the transmitting device is a packet terminal that
doesn't care about those things. As long as keystrokes are in a separate
session from the audio, I can deal with these issues.

So that brings us to my second issue. Even if keystrokes have their own
session, they still need to be delivered by a reliable protocol. Henning
seems to feel that RTP with reliability extensions (RFC 2198) will fill
this bill.

Henning Schulzrinne said:
>RTP with redundancy is at least as reliable as SIP transport
http://lists.bell-labs.com/pipermail/sip/2000q3/002087.html

RFC 2198 seems to be targeted specifically to reliably delivering audio
by transmitting redundant audio data. I was unable to find any mention
of how single-datum  events such as a non-audio keystroke from a SIP
terminal could be made reliable using RFC 2198. (I can think of some
ways, but none of them are specified in the document). I expect that, if
we are to use RFC 2198, we will have to extend it to deal with non-audio
keystrokes. I'm not saying it can't be done, just that we haven't said
how to do it yet. By the way, Colin Perkins, a participant in this
thread, was an author of the 2198 RFC for audio redundancy. Colin, if I
am putting words in your mouth, speak up.

There are several existing mechanisms for reliable delivery of
single-datum events. TCP, SCTP, and telnet come to mind. Would it be
easier to just select an existing reliable protocol for keystroke
transport, or develop RFC 2198 to the point it could be used for
single-datum non-audio events like a keystroke. Admittedly, it would be
nice to not require another protocol stack in devices that already
implement RTP, but what about things that aren't phones? Should we
require that any SIP device with keys support reliable RTP? Even if it
doesn't have a microphone or speaker? Is reliable RTP simpler or more
complex than the other reliable delivery mechanisms?

Why should we bias a protocol such as RFC 2833 towards devices with a
microphone and a keyboard? Why not bias it towards devices with video
camera and a keboard? Why not devices with just a keyboard?

Henning Schulzrinne said:
>every Ethernet phone will need to support RFC 2833 (and it's pretty
>trivial to implement, given that RTP/RTCP is needed anyway). Instead of

>adding another mechanism, it would seem better to have the generic
>ability to get end systems to send to multiple copies of audio streams,

>including subsets. This is more generally useful for multi-party calls.

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

I'm not convinced that reliable RFC2833 is all that trivial for
non-audio keystrokes, since that hasn't been defined yet. I'm also not
convinced that reliable RFC2833 is vastly simpler or more complex that
other reliable protocols. I agree that a single protocol is nice, and if
reliable RTP isn't vastly more complex than a different reliable
protocol, we could use it.

I DEFINITELY agree with Henning that all SIP terminals should be
required to have the capability to send multiple copies of audio
streams. This should be in the base SIP (or is it SDP) specification.
This functionality is a MUST for a large set applications (virtually
every application my company builds). Multi-party calls, operator
intercept, voice logging, all of these applications would be much more
difficult and costly to implement, if session replication capability is
not present in EVERY SIP terminal (and gateway). All SIP terminals
should also be required to support requests for multiple copies of a
video session. They should all be required to support requests for
multiple copies of a keystroke session. We should consider this as one
of the highest priorities for updates to the basic SIP doc. What is the
process for getting this requirement into the base document?

Don't know what this has to do with splitting keystroke sesions from
audio, though.

Actually, I don't find this requirement for all devices (including
audio-less devices) to use reliable RTP particularly objectionable. As
long as reliable RTP delivery of keystrokes can be shown to be close to
as efficient in bandwidth and processing power as any of the other
transport protocol candidates, a reliable version of RFC 2833 would be a
viable approach to use. As long as the keystrokes have their own
session, and reliable RTP isn't too much of a hog compaired to the other
choices, let's use it. Of course we still need to define it (reliable
RTP for non-audio, single-datum events) first.

Comments?

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: Fri, 11 Aug 2000 13:34:35 -0400

--> Skip Cave writes:
...much deleted...
>am putting words in your mouth, speak up.

I suggest you read RFC 2793 which describes how to use RFC 2198 redundancy
as a `reliable' transport for non-audio keystrokes. 

Colin

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 11 Aug 2000 18:15:25 -0400

Skip Cave wrote:

> puts both media types in one session.

Several choices:

- Create a new session (by adding a new m= line) for keyboard only. Use
the c= line to direct it to Term2. Leave the c= lines for video alone.
Use a different c= line to point audio to Term3.

- Have the terminal that also wants audio or keystrokes to INVITE itself
as another call leg to the session.

> any reasons why this isn't a better solution.

Has to do with ease of synchronization at the tone reconstruction point.

You want to allow both:

- embedded in audio stream for recreating audio + tones with tight
synchronization;

- just events, for entities that don't care about audio.

The above mechanism supports this.

In practice, the worst thing that can happen to you is that you get some
spurious audio packets. Drop them on the floor and don't forget to empty
the bit bucket at the end of the day.

It may also be a good idea to have devices implement text transport as a
payload type, even if the keyboard is limited to 12 keys. (You'd
probably want a mode to use alpha input mode with
press-2-twice-to-get-B.)

> am putting words in your mouth, speak up.

Currently, the end of keystrokes (last packet) is retransmitted a
setable number of times, according to RFC 2833.

> complex than the other reliable delivery mechanisms?

RTP can already use TCP, but not all devices will support TCP (or the
even more complex SCTP).

> process for getting this requirement into the base document?

The IETF doesn't really do device requirements. TIA would be the more
appropriate body for this. (SIP is not just for audio devices or devices
with keyboards, so I don't think this is appropriate for an IETF
standard. There are all kinds of SIP UAs that wouldn't need this
capability.)

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