1. BLISS Problem Statement Jonathan Rosenberg Cisco

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

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?