1 / 15

SIPPING Drafts

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]

charissa-harmon
Download Presentation

SIPPING Drafts

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 don’t 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. 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 Dialog Package Issues

  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 |----------->| Active |----------->| Terminated | | | | | | | +------------+ registered +------------+ expired +------------+ created deactivated probation unregistered rejected

  7. Relationship with Presence PA Reginfo Notifier Geoloc Notifier Publish

  8. Original draft extended presence for this Why the same? Reporting contacts Nice to have unified mechanism PA wouldn’t 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 Main Open Issue: Extend Presence?

  9. Second Open Issue • Adopt as WG item?

  10. Markup and App Interaction

  11. 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 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. Context

  12. Markup draft appears Key-events doesn’t 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! More Context

  13. 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? 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 Where are we now?

  14. 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 Some tough technical problems

  15. 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 How do we move forward?

More Related