220 likes | 339 Vues
This article explores the nuances of Dual-Tone Multi-Frequency (DTMF) signaling, contrasting its traditional roles in PSTN networks with modern packet networks like SIP. DTMF was initially used for address signaling, but as telephony evolved, its purpose shifted, leading to confusion between network and user signaling, particularly with the use of the pound key (#). The discussion includes implications for user input during calls and various proposals for integrating user input into signaling protocols. The future of DTMF and user input standards in packet networks is also analyzed.
E N D
User to User Key Signaling Protocols Ellis K Cave Sr. Principal Engineer InterVoice-Brite
DTMF - is it Signaling or Media? • DTMF was designed to provide address signaling at start of call • network address signaling • DTMF originally turned off during conversation part of call • Left on during call because of tip-ring polarity administration issues SIP WG
DTMF - is it Signaling or Media? • PSTN service and application vendors discovered DTMF control in late 70s • Vendors standardized on the use DTMF for application control during call • simple user input mechanism • standard across all PSTN terminal device • Accidental provision of a standard user input model by the Telco made possible most of today’s complex telephony applications SIP WG
The Infamous Octothorpe (pound sign) • Illustrates the confusion between network signaling and user signaling • VRU vendors use pound ‘#’ for application control • Input field termination • “Press pound when you complete your entry” • Network vendors use pound ‘#’ as call re-originate • “Press pound to disconnect the current LD call, and place another” SIP WG
Network vs User Signaling Confusion • To differentiate between network and application functions, network providers had to require that the pound be held for over 2 seconds for network alerts • VRU vendors may still interpret a 2-second pound as an application function SIP WG
Address Signaling in a Packet Network • Current packet session protocols thoroughly deal with address signaling • DTMF is not required for address signaling on packet terminals • Packet network address signaling standards • H.323 - Q.931, H225 • SIP Invite • Smart terminal aggregates address data input from caller • Terminal transmits aggregated address data in the call setup signaling message when user presses terminate (OK) key. SIP WG
DTMF replacement in a packet network • DTMF-type address signaling is not required in a packet network • However, some type of user input keystroke signaling IS a requirement in a packet network for interactions with applications and other users • What will replace DTMF as application control in a packet network? SIP WG
Most services in the packet network will require standardized user input. • Examples • voicemail • meet-me conferencing • recording/logging services • language translation services • hearing impaired service • To keep these applications simple, user input should be standardized across all terminal types SIP WG
Questions • 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? Answer • The same thing that happens when you press a key on the keyboard of a computer during a SIP call. SIP WG
User 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 doesn’t address user input issue • Schulzrinne made H.323 to SIP proposal • Left out user input indication translation SIP WG
Current Proposals for SIP DTMF • http://www.ietf.org/rfc/rfc2833.txt. • http://www.ietf.org/internet-drafts/draft-ietf-sip-info-method-05.txt. • draft-kuthan-sip-infopayload-00.txt (expired). • 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. • http://www.ietf.org/internet-drafts/draft-agrawal-sip-h323-interworking-reqs SIP WG
Where should you put User Input? • Should it go in the signaling protocol (SIP)? • The current Info Method proposals propose this approach • Does an application protocol belong in the session set-up/teardown signaling? • SIP Info Method has the right transport characteristics • guaranteed delivery • single packet • Should it go in the session description protocol (SDP)? • SDP currently only sets up media sessions SIP WG
Where should you put User Input? • Perhaps User Input needs its own session specifically for user signaling. • If an application using SIP expects to need user input (and most will), the user agent should use SDP to set up a user input session • User input sessions will be as common as streaming media sessions SIP WG
User Key Input Transport Protocol Requirements • Keystroke-based • Requires guaranteed delivery • no dropped packets • Requires guaranteed sequencing • receiver should be able to get transmitted input events in transmit order • Duration information should be an option • User input signaling protocol should be the same whether it is a SIP phone, a PC, or a cell phone! SIP WG
What are the Choices? • RTP stream • Info Method • New SDP session protocol SIP WG
RTP streaming for User Key Input • Pros • Existing protocol • Guaranteed Sequencing • Cons • User Input is not a streaming function • single keystroke events • RTP is not guaranteed delivery • Overly complex protocol for simple keystrokes • RTSP, stats, jitter buffers, etc • Simple text chat apps would require RTP stack • User Input needs to be a separate session from audio stream SIP WG
SIP Info Method for User Key Input • Pros • Existing protocol • Guaranteed delivery • Simple mechanism (part of SIP) • Cons • Architecturally, application and user data should NOT be in the signaling channel • Future 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? SIP WG
New SDP Session for User Key Input • Pros • Allows selection of appropriate transport protocol for reliable keystroke delivery • Separate session for User Key Input • Allows redirect & multi-unicast, etc. • Cons • Need to define new SDP protocol for User Key Input • Must use SDP to set up User Key Input session SIP WG
SDP supports • Video • Audio • Application • Data • Control • Which type of session is most appropriate? SIP WG
Gateway Requirements • Gateway is the intelligent proxy for the dumb black phone in a SIP call. • Gateway never sees PSTN address signaling from terminal, only user key input • Job of the gateway is to convert DTMF to the new SIP User Key Input protocol • Gateway sets up User Key Input SDP session SIP WG
Avoid the WAP/WML/HDML/WebClip Debacle • Different protocol for each type of device • To avoid chaos, the User Key Input protocol should be standardized for all packet terminal devices. • The “one” numeric key should produce the same message in the User Key Input session on all devices. SIP WG
Conclusions • SIP architecture needs a User Key Input mechanism • Best choice is a separate SDP session • Could be “application’ or “control” session type • User Input should be standardized across all terminal devices • Keystroke/event message map defined in standard across all terminal device types SIP WG