1 / 12

BLISS Problem Statement

BLISS Problem Statement. Jonathan Rosenberg Cisco. “Confusion of Tongues” Concrete examples (CFNA) with failure cases Solution Considerations BLISS Process Structure of BLISS deliverable. What the draft says. Solution Considerations. Avoid Enumeration Allow Variability of Definition

shlomo
Download Presentation

BLISS Problem Statement

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. BLISS Problem Statement Jonathan Rosenberg Cisco

  2. “Confusion of Tongues” Concrete examples (CFNA) with failure cases Solution Considerations BLISS Process Structure of BLISS deliverable What the draft says

  3. Solution Considerations • Avoid Enumeration • Allow Variability of Definition • Assume Multimedia • Allow Variability of Implementation • Multiplicity of Environments

  4. BLISS Process • Phase 1: Define Functional Primitives • Phase 2: Submit feature flows • Phase 3: Problem Determination • Phase 4: Minimum Interop Definition

  5. Phase 1: Define Functional Primitives • How to do it? • Collect together features with similar flows • Identify common element interactions that are a potential source of interop failures • Define the functional primitive which captures the set of features • Example: Automated Handling • Common interactions: • User “enables/configures” call treatment • Call treatment signaled to originator • Side effects of presence

  6. Phase 2: Submit Feature Flows • Folks contribute the calls flows they are using for various specific features covered by the functional group • Per vendor or product • From SDOs • Also need to state behavior driving state flows • Not targeted as a WG deliverable, just a working document • Compilation documents OK too

  7. Phase 3: Problem Determination • Analyze what happens when elements from different implementations get plugged together • Analysis is based on behavior driving the implementations from documents from phase 2 • Can be in the form of list discussions, drafts, etc., as appropriate

  8. Phase 4: Minimum Interop Spec • Actual deliverable of the group • Defines the minimum functional reqiurement of each component in the system • Specifications • Portions of specifications • Whatever else is needed

  9. BLISS Deliverable • Title reflects functional primitive • E.g., “Interoperability Requirements for SIP Features for Automated Call Handling” • Abstract gives examples of features in the group • Summarize kinds of interop problems that were seen • Implementation requirements on UA, proxies

  10. Issue #1: Is provisioning in scope? • Proposal: conditional yes • If it seems acceptable for the provisoning interface to be single-ended, based on user-interaction (vxml, web, ajax, etc.), only need to state that some mechanism exists • If an automated interface is REQUIRED we need to pick minimum required one and define procedures to discover others

  11. Issue #2: Single ended • Document needs to introduce and define concept of ‘single ended’ features • Need a crisp definition • Brian’s proposal: requires more than basic call setup

  12. Next steps • Update based on comments • Accept as a WG item?

More Related