BLISS Problem Statement

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?