SlideServe
Menu
Préférences
© SlideServe · v2026

Enhancing Interoperability through the BLISS Framework: A Structured Approach

shlomo avatar
12 diapositives · 264 Views · Aug 31, 2014

The BLISS (Building Layered Interoperable Specifications and Standards) framework, proposed by Jonathan Rosenberg from Cisco, addresses challenges in interoperability terminology through a structured process. The BLISS methodology consists of four phases: defining functional primitives, submitting feature flows, determining problems, and establishing a minimum interoperability specification. It emphasizes the need for variability in definitions, multimedia assumptions, and diverse implementation environments. The deliverables aim to encapsulate both current practices and challenges, paving the way for a more integrated and efficient interoperability landscape.

Enhancing Interoperability through the BLISS Framework: A Structured Approach - slide 1
01 / 12Enhancing Interoperability through the BLISS Framework: A Structured Approach
1 / 17

Télécharger la présentation

Enhancing Interoperability through the BLISS Framework: A Structured Approach
Une image / un lien ci-dessous est fourni (tel quel) pour télécharger la présentation

Politique de téléchargement : le contenu du site vous est fourni TEL QUEL pour votre information et votre usage personnel ; il ne peut être vendu, concédé sous licence ni partagé sur d’autres sites sans l’accord de son auteur.Le contenu vous est fourni TEL QUEL, pour votre information et votre usage personnel uniquement. Téléchargez la présentation en cliquant sur ce lien. Lors du téléchargement, si vous ne parvenez pas à télécharger une présentation, l’éditeur a peut-être supprimé le fichier de son serveur.Pendant le téléchargement, si vous ne parvenez pas à obtenir une présentation, le fichier a peut-être été supprimé par l’éditeur.

F I N

Plus de contenu associé

Transcription de la présentation
  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?