User%20Application%20Control%20(Keypress%20Events)

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 UAIs 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 UAIs 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
• Prepare requirements I-D (include SIMPLE
  requirements)
• Define an Events Package
• Define a "key" representation