BLISS Problem Statement Jonathan Rosenberg Cisco

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

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

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

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

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

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

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

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

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

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

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