DTMF &Universal User Key Input

Skip Cave

InterVoice-Brite Inc.

48th IETF SIP WG 2

DTMF Origins - The Fortuitous Mistake

• DTMF was designed to provide address signaling to CO in PSTN at start of call– Speed user address input (rotary dial was slow)

– DTMF originally turned off during conversation part of call

– Left on during call because of tip-ring polarity administration issues

48th IETF SIP WG 3

DTMF Origins - The Fortuitous Mistake

• Created simple, universal user input mechanism for all devices on the PSTN network – end-to-end signaling

– standard across all PSTN terminal devices

• PSTN service and application vendors discovered DTMF availability during call in late 70s & began using DTMF for application control

• Accidental provisioning of an end-to-end standard for user input by the Telco made possible most of today’s automated telephony applications & services

48th IETF SIP WG 4

DTMF Usage Today

• Virtually all PSTN terminals today have a standard 12-key keypad as a minimum

• DTMF for Address signaling is ubiquitous• Universal User Input mechanism - DTMF has

become the standard user input mechanism for all types of PSTN voice terminals to interact with services and applications

48th IETF SIP WG 5

DTMF - Is it Network or Application Signaling?

• DTMF address signaling is always terminated in the local CO

• All DTMF after call setup is application signaling• Edge applications

– IVR

– Voicemail

• Network applications– Calling Card

– Universal Messaging

48th IETF SIP WG 6

Address Signaling in a Packet Network

• Current packet session protocols thoroughly deal with address signaling

• Packet network address signaling standards– H.323 - Q.931, H225

– SIP Invite

• The original function of DTMF (address signaling) is not needed in packet network

48th IETF SIP WG 7

The Universal User Input Problem

• Most (if not all) packet terminal devices do NOT use DTMF for user input signaling

• Some method for user input keystroke signaling IS a requirement in a packet network for interactions with applications and other users

• Application providers in the packet network need a standardized way to deal with key input from all types of terminal devices that reside both in the PSTN AND in the packet network.

48th IETF SIP WG 8

Questions

• From the perspective of an application provider in the packet network - What do you want to have happen when a user presses a button on the keypad of a SIP desk phone during a SIP call ?

• A cell phone in the PSTN?

Answer• The same thing that happens when you press a key

on the keyboard of a computer during a SIP call.

48th IETF SIP WG 9

Current DTMF/SIP Transport Proposals

• Originally focused on carrying DTMF across packet network to be reconstructed for PSTN

• Started discussing delivery of DTMF to application platforms in the packet network

48th IETF SIP WG 10

User Input Signaling in a Packet Network

• H.323 defines user input indication - H.245– Intended specifically for DTMF

– Assumes 16-key device 0-9, *, #, and A-D

• SIP User Input under discussion• Schulzrinne made H.323 to SIP proposal

– Left out user input indication translation

48th IETF SIP WG 11

Requirements for User Key Input Mechanism

• End-to-end event delivery• Single-event transmission protocol

– perhaps like mid-call triggers for applications

– Keystroke-based

• Guaranteed delivery– no dropped key events

• Guaranteed sequencing– receiver should be able to determine order of transmitted

input events

48th IETF SIP WG 12

Requirements for User Key Input Mechanism

• Should DTMF Duration, Time-Stamp & Level information be an option?– Primarily required for DTMF reconstruction

– Packet terminal devices will probably not be capable of providing keystroke duration, time-stamp & level information (PC)

– Applications that must use both PSTN & Packet terminals should not rely on duration, exact event times, or levels, so these should not be in Universal Key Input protocol (RFC 2833 sec. 3.1)

48th IETF SIP WG 13

Requirements for User Key Input Mechanism

• Media/Keystroke Separation– Keystroke events should be in isolated session

– NOT combined with audio streaming

• Many applications will not require media streams, only keystroke events

• Some applications will send media streams to one endpoint, and keystroke events to another endpoint– Should be able to re-invite keystroke streams to other

endpoints

48th IETF SIP WG 14

What are the Choices for User Input?

• Info Method• RTP stream• Other SDP session protocol

48th IETF SIP WG 15

SIP Info Method

• The current Info Method proposals– http://www.ietf.org/internet-drafts/draft-ietf-

sip-info-method-05.txt.– http://www.ietf.org/internet-drafts/draft-

choudhuri-sip-info-digit-00.txt.– http://www.ietf.org/internet-drafts/draft-

culpepper-sip-info-event-00.txt.– draft-kuthan-sip-infopayload-00.txt (expired)

48th IETF SIP WG 16

SIP Info Method for User Key Input

• Pros– Existing, efficient protocol– Guaranteed delivery of Single Events– Simple mechanism (part of SIP)

• Cons– Architecturally, application and user data should NOT be in the

signaling channel• This point is probably moot for PSTN-PSTN transport, but it is

significant for UUKI

– Applications using redirection and replication of user input for multi-party conferencing would be prevented

• How do you redirect or multicast the SIP session Info Messages?

48th IETF SIP WG 17

RTP “Telephone Event” Payload

• The current RTP Stream Proposal for DTMF– http://www.ietf.org/rfc/rfc2833.txt– RFC 2833 defines a method to transport PSTN

audio and in-band signaling tones across a packet network - primarily for re-insertion into the PSTN

– Solves problem of tone-distorting compression protocols

– Solves problem of reconstruction of waveforms with correct timing relationships

– Henning has done an elegant job of solving the PSTN to Packet to PSTN transport problem

48th IETF SIP WG 18

RTP “Telephone Event” Payload for User Key Input

• Pros– Uses Existing protocol

– Guaranteed Sequencing

– Focused on PSTN to Packet to PSTN - DTMF transport

48th IETF SIP WG 19

RTP “Telephone Event” Payload • Cons

– User Input is not necessarily a streaming function• single keystroke events

– RTP is not guaranteed delivery in basic form (can drop keystroke events)

• RFC 2198 provides a potential redundancy method for improving relibility

– Overly complex protocol for simple keystrokes• RTSP, statistics, jitter buffers, redundancy, etc

• Simple text chat apps would require RTP stack

• http://www.ietf.org/rfc/rfc2833.txt Sec 3.1

– User Input needs to be a separate session from audio stream– Should all terminal types be required to provides keystrokes

using 2833?

48th IETF SIP WG 20

RTP “Telephone Event” Payload

• RFC 2833 Does not address (at least not explicitly) the Universal User Input problem

48th IETF SIP WG 21

The Problem

• RFC 2833 is certainly a good way to send DTMF across a packet network for reconstruction in the PSTN. Not so good for simple user key input

• All of the Info Method proposals are reasonable ways to transport user input to a packet terminal, but they use SIP Info Message session signaling - not appropriate for application usage.

48th IETF SIP WG 22

The Problem

• These proposals aren’t appropriate for providing a universal user input mechanism across both PSTN and Packet terminal devices

• Application providers in the packet world want the same universal input model that the PSTN has

48th IETF SIP WG 23

The Solution

• Define SDP Session Specifically for User Key Input• Pros

– Provides separate session for User Key Input– Allows selection of appropriate transport protocol for reliable

keystroke delivery– Allows redirect & multi-unicast, etc. of keystroke events– Could allow optional timestamp & duration information for

reconstruction of DTMF

• Cons– Need to select/define new SDP protocol for User Key Input– Must set up specific session for User Key Input

48th IETF SIP WG 24

Issues

• Application providers need an end-to-end Universal Key Input model for terminal devices in SIP network just like in PSTN

• If an application using SIP needs user input (and most will), the user agent should use SDP to set up a user input session

• User input sessions will be more common than streaming media sessions in the packet network

48th IETF SIP WG 25

Issues

• Gateway may have to sent two different representations of user input - one in RFC 2833 or Info Method form (whichever is used for DTMF transport) AND a User Key Input session

• May want to consider an event aggregation mechanism in future work

48th IETF SIP WG 26

Conclusions

• There are TWO problems– DTMF transport across a packet network– Universal User Key Input mechanism

• The requirements for the solution to these two problems differ

• RFC 2833 or Info Method will work for the specific problem of PSTN-Packet-PSTN Audio & In-band signaling transport

• Neither RFC 2833 or the various Info Methods proposals are appropriate for a universal terminal key input mechanism like that available in the PSTN

48th IETF SIP WG 27

Conclusions

• Packet SIP architecture needs a Universal User Key Input mechanism

• Best choice is a to define a new SDP session specifically for User Key Input

• Need to select most appropriate protocol for User Input SDP session

• User Input should be standardized across all terminal devices– numeric “One” key produces same result for all devices