DTMF

1
DTMF Universal User Key Input

• Skip Cave
• InterVoice-Brite Inc.

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

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
  todays automated telephony applications
  services

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

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

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

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.

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.

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

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

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

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)

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

14
What are the Choices for User Input?

• Info Method
• RTP stream
• Other SDP session protocol

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-choudhur
  i-sip-info-digit-00.txt.
• http//www.ietf.org/internet-drafts/draft-culpeppe
  r-sip-info-event-00.txt.
• draft-kuthan-sip-infopayload-00.txt (expired)

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?

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

18
RTP Telephone Event Payload for User Key Input

• Pros
• Uses Existing protocol
• Guaranteed Sequencing
• Focused on PSTN to Packet to PSTN - DTMF transport

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?

20
RTP Telephone Event Payload

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

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.

22
The Problem

• These proposals arent 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

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

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

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

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

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