SIPPING Drafts Jonathan Rosenberg dynamicsoft Conferencing Package Issues
SIPPING Drafts Jonathan Rosenberg dynamicsoft
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 don’t know yet] Floor control [no] Media mixing information [? ] URIs for other things, policy for example [? ] • One package or many?
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
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
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
Reports General State Transitions +------+ | | refreshed | | V | +------------+ +------+ | | | Init |------>| | Active |------>| Terminated | | | +------+ registered +------+ expired created | +------+ deactivated probation unregistered rejected |
Relationship with Presence PA Reginfo Notifier Geoloc Notifier Publish
Main Open Issue: Extend Presence? • Original draft extended • Why different? presence for this – Different information in notifications • Why the same? – Reporting contacts – Nice to have unified mechanism – PA wouldn’t have to munge XML • Probation, contact expirations, etc. – A layer lower than whats normally in PIDF – AOR vs. Contact address
Second Open Issue • Adopt as WG item?
Markup and App Interaction
Context • Where did we start – How to collect DTMF from a UA in order to drive an application – General consensus that rfc 2833 is bad here • Requires media forking • Synchronization with media not needed • Doesn’t 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.
More Context • Markup draft appears – Key-events doesn’t support notion of a UI on the UA – HTML input desired, Voice. XML 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!
Where are we now? • No agreement on the scope of the problem – – DTMF only? DTMF + keys + HTML? DTMF + keys + HTML + voice/video? – 1*(DTMF + keys + HTML + voice/video) (I. e. , true multi-modal) – SALT? • 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
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 – Voice. XML, HTML, WML
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
- Slides: 15