SIPPING%20Drafts

1
SIPPING Drafts

• Jonathan Rosenberg
• dynamicsoft

2
Conferencing Package Issues

• Only one scope
• Depends on broader work in conferencing
• May include
• Participant identities yes
• Dialog information yes
• Participant roles yes but we dont know yet
• Floor control no
• Media mixing information ?
• URIs for other things, policy for example ?
• One package or many?

3
Dialog Package Changes

• Defined a dialog FSM
• Just an extraction of words from bis
• Schema for dialog XML
• Abstract Dialog for when the subscriber is not
  authorized for details
• For INVITE only
• Partial updates behavior
• Removed Route element
• Local URI and Remote URI are elements, not
  attributes of dialog element
• IANA registrations

4
Dialog Package Issues

• Ask for a specific dialog
• Right now, SUBSCRIBE is to the UA
• Gets you state for all dialogs you are authorized
  to see
• Do we need to allow to ask for a specific dialog?
• Its filtering
• Proposal no

• Scope of attributes OK?
• I think its OK
• Pretty close to ready wglc on next rev I think
• No dependency on conferencing work

5
Registration Event Package

• History
• Beckmann and Meyer wrote an I-D as part of the
  P-header bundle
• Used presence package, focused on a particular
  authorization problem
• How to tell someone to re-register to
  re-challenge, in case fraud is suspected
• Recognition that there was a general need for a
  registration package

6
Reports General State Transitions



------

refreshed

V

------------ ------------
------------

Init -----------gt Active
-----------gt Terminated

------------ registered
------------ expired ------------
created
deactivated
probation

unregistered
rejected


7
Relationship with Presence
PA
Reginfo Notifier
Geoloc Notifier
Publish
8
Main Open Issue Extend Presence?

• Original draft extended presence for this
• Why the same?
• Reporting contacts
• Nice to have unified mechanism
• PA wouldnt have to munge XML

• Why different?
• Different information in notifications
• Probation, contact expirations, etc.
• A layer lower than whats normally in PIDF AOR
  vs. Contact address

9
Second Open Issue

• Adopt as WG item?

10
Markup and App Interaction
11
Context

• Where did we start
• How to collect DTMF from a UA in order to drive
  an application
• General consensus that rfc2833 is bad here
• Requires media forking
• Synchronization with media not needed
• Doesnt genrealize well

• INFO exists as a proprietary solution
• Many bad things here
• Specific to DTMF what about keys/buttons?
• Key-events draft appears
• Applications SUBSCRIBE to user events
• Users send NOTIFY with DTMF or keypresses,
  switches, etc.

12
More Context

• Markup draft appears
• Key-events doesnt support notion of a UI on the
  UA
• HTML input desired, VoiceXML input
• Models DTMF through markup as well DML
• Uses HTTP to POST form results of markup

• App-session/ new Requirements appears
• Adds support for app interaction through media
  sessions
• Uses SIP sessions to control markup based
  mechanisms as well
• Considers applications with multiple UI
  components, each a different session
• Observation requirements depend a lot on
  framework!

13
Where are we now?

• No agreement on the framework for solving any of
  them
• SIP sessions?
• HTTP sessions?
• SUB/NOT dialogs?
• Small set of participants on the list
• Huge amount of proprietary implementations
• Probably the biggest area of non-interoperability
  because of no solution

• No agreement on the scope of the problem
• DTMF only?
• DTMF keys?
• DTMF keys HTML?
• DTMF keys HTML voice/video?
• 1(DTMF keys HTML voice/video) (I.e., true
  multi-modal)
• SALT?

14
Some tough technical problems

• Capability negotiations
• What input types does UA support and relative
  preferences?
• What are constraints on UI in endpoint?
• Security
• Correlating application interaction with session
• Authentication and privacy issues
• Lifecycle management
• When does interaction begin and end?
• Who can terminate it and when?

• Routing
• Make sure application can communicate back to UA
• UA can send information to application
• Extensibility
• Future proofing to many different types of
  interactions
• Integration with Relevant work
• CC/PP
• SALT
• VoiceXML, HTML, WML

15
How do we move forward?

• We need to agree on high level scope
• We need to develop a basic framework based on
  that scope
• What are the entities
• What are the functional protocols
• We need to develop protocol requirements based on
  framework

• Proposal
• Form a very small design team to hash it out
• Its too complex for list discussion
• Too few participants
• Too critical to let slide a year