1. User Application Control (Keypress Events) SIPPING WG - IETF 53 Robert Fairlie-Cuninghame, Bert Culpepper, Jean-François Mulé

2. User Application Control Need: Application Servers need to receive user activity indications independently of the media path of established sessions and in some cases outside of the signaling path of established sessions as well. Observation: End-to-end (media path) user activity indications [UAI] are currently conveyed using RTP, for example, RFC2833. Question: Are RTP based solutions, suitable for transporting asynchronous user activity indications outside of the media plane? Conjecture: No. If the UAI’s are transported in the signaling plane then the number of messages and bandwidth is critical. Reliability through blind retransmission is not acceptable. Tight media synchronization is not a requirement for Async UAI and so reliability can be achieved by message delivery acknowledgement. Furthermore, Async UAI’s should only be generated when explicitly requested by application servers. Question: Is the transport of DTMF-derived user activity indications deemed sufficient for future user application interaction? Conjecture: No, it is not acceptable to limit future user application interaction to only using telephone keypad keys. At the very least generic keyboards and device-specific buttons must be supported.

3. User Application Control (Cont.) Conclusion: End-to-end and asynchronous user activity indications have different functional and performance requirements; as some of the requirements are at odds this suggests separate mechanisms are desirable. A new asynchronous user activity indication transport mechanism is needed to generate indications outside of the media plane such that activity indications are only generated on request and in a way that is sensitive to the bandwidth constraints outside of the media plane. What are the requirements for such a system?

4. Key Events Requirements Transport user indications to network elements participating in the session signaling and independent from the session media. Support for user indications via keys or buttons. A network entity desiring user indications must be able to request user indications from another network entity. The entity receiving a request must be able to respond with its intent/willingness to transmit user indications. The mechanism must support multiple network entities in the signaling path requesting and receiving indications independently from each other. Separation between the transport mechanism in the signaling plane (SUB/NOT or INFO) and the message syntax. The mechanism must support filtering so that only user indications of interest are transmitted. The mechanism must support reliable delivery at least as good as the session control protocol.

5. Key Events Requirements (Cont.) The mechanism must support collecting device input both within and outside of established sessions. The mechanism must support devices with richer user interfaces than simple keypads. A requestor must be able to determine the makeup/contents of the user interface possessed by a target device. The mechanism must support device and/or user-specific buttons. The mechanism must provide some form of indication of key press duration. The mechanism must provide some form of indication of relative key press start time (relative to other key presses). The mechanism must allow for end-to-end security/privacy between source and destination. Both entities must be able to authenticate each other.

6. Related Proposals: draft-mahy-sipping-signaled-digits-00.txt This proposal describes carrying the RFC 2833 defined audio/telephone-event MIME type in the message bodies in INFO. Also defines an Event Package for carrying the RFC 2833 defined audio/telephone-event MIME type in the NOTIFY message body. draft-culpepper-sip-key-events-01.txt This proposal defines a SIP Events package and defines a key/keypress protocol for placing in SUB/NOT message bodies. Open Issues: What should this new mechanism be? Is the SIP Events framework appropriate? If so, what should the payload format be? (Potential) Next Steps: 1.Prepare requirements I-D (include SIMPLE requirements) 2.Define an Events Package 3.Define a "key" representation