1. User to User Key Signaling Protocols
Ellis K Cave
Sr. Principal Engineer
InterVoice-Brite

2. 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
48th IETF
SIP WG

3. 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
48th IETF
SIP WG

4. 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”
48th IETF
SIP WG

5. 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
48th IETF
SIP WG

6. 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 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.
48th IETF
SIP WG

7. 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?
48th IETF
SIP WG

8. Most services in the packet network will require standardized user input.
Examples
voic
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
48th IETF
SIP WG

9. 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.
48th IETF
SIP WG

10. 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
48th IETF
SIP WG

11. Current Proposals for SIP DTMF
draft-kuthan-sip-infopayload-00.txt (expired).
48th IETF
SIP WG

12. 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
48th IETF
SIP WG

13. 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
48th IETF
SIP WG

14. 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!
48th IETF
SIP WG

15. What are the Choices? RTP stream Info Method New SDP session protocol
48th IETF
SIP WG

16. 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
48th IETF
SIP WG

17. 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?
48th IETF
SIP WG

18. 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
48th IETF
SIP WG

19. SDP supports Video Audio Application Data Control
Which type of session is most appropriate?
48th IETF
SIP WG

20. 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
48th IETF
SIP WG

21. 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.
48th IETF
SIP WG

22. 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
48th IETF
SIP WG