bliss problem statement jonathan rosenberg cisco
TRANSCRIPT
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?