DTMF & Universal User Key Input Skip Cave InterVoice-Brite Inc.

48th IETFSIP WG2 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 IETFSIP WG3 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 IETFSIP WG4 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 IETFSIP WG5 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 –Voic Network applications –Calling Card –Universal Messaging

48th IETFSIP WG6 Address Signaling in a Packet Network Current packet session protocols thoroughly deal with address signaling Packet network address signaling standards –H Q.931, H225 –SIP Invite The original function of DTMF (address signaling) is not needed in packet network

48th IETFSIP WG7 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 IETFSIP WG8 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 IETFSIP WG9 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 IETFSIP WG10 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 IETFSIP WG11 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 IETFSIP WG12 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 IETFSIP WG13 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 IETFSIP WG14 What are the Choices for User Input? Info Method RTP stream Other SDP session protocol

48th IETFSIP WG15 SIP Info Method The current Info Method proposals – method-05.txt. – info-digit-00.txt. – info-event-00.txt. –draft-kuthan-sip-infopayload-00.txt (expired)

48th IETFSIP WG16 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 IETFSIP WG17 RTP “Telephone Event” Payload The current RTP Stream Proposal for DTMF – –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 IETFSIP WG18 RTP “Telephone Event” Payload for User Key Input Pros –Uses Existing protocol –Guaranteed Sequencing –Focused on PSTN to Packet to PSTN - DTMF transport

48th IETFSIP WG19 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 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 IETFSIP WG20 RTP “Telephone Event” Payload RFC 2833 Does not address (at least not explicitly) the Universal User Input problem

48th IETFSIP WG21 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 IETFSIP WG22 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 IETFSIP WG23 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 IETFSIP WG24 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 IETFSIP WG25 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 IETFSIP WG26 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 IETFSIP WG27 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