draft-ietf-bliss-problem-statement-01.txt   draft-ietf-bliss-problem-statement-02.txt 
BLISS J. Rosenberg BLISS J. Rosenberg
Internet-Draft Cisco Internet-Draft Cisco
Intended status: Informational November 19, 2007 Intended status: Informational February 24, 2008
Expires: May 22, 2008 Expires: August 27, 2008
Basic Level of Interoperability for Session Initiation Protocol (SIP) Basic Level of Interoperability for Session Initiation Protocol (SIP)
Services (BLISS) Problem Statement Services (BLISS) Problem Statement
draft-ietf-bliss-problem-statement-01 draft-ietf-bliss-problem-statement-02
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 22, 2008. This Internet-Draft will expire on August 27, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
The Session Initiation Protocol (SIP) has been designed as a general The Session Initiation Protocol (SIP) has been designed as a general
purpose protocol for establishing and managing multimedia sessions. purpose protocol for establishing and managing multimedia sessions.
It provides many core functions and extensions in support of features It provides many core functions and extensions in support of features
such as transferring of calls, parking calls, and so on. However, such as transferring of calls, parking calls, and so on. However,
interoperability of more advanced features between different vendors interoperability of more advanced features between different vendors
has been poor. This document describes the reason behind these has been poor. This document describes the reason behind these
interoperability problems, and presents a framework for addressing interoperability problems, and presents a framework for addressing
them. them.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. The Confusion of Tongues . . . . . . . . . . . . . . . . . . . 4 2. The Confusion of Tongues . . . . . . . . . . . . . . . . . . . 4
3. Concrete Examples . . . . . . . . . . . . . . . . . . . . . . 5 3. Concrete Examples . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Call Forward No Answer . . . . . . . . . . . . . . . . . . 5 3.1. Call Forward No Answer . . . . . . . . . . . . . . . . . . 5
3.1.1. Approach 1: UA Redirects . . . . . . . . . . . . . . . 6 3.1.1. Approach 1: UA Redirects . . . . . . . . . . . . . . . 6
3.1.2. Approach II: Proxy Forwards . . . . . . . . . . . . . 7 3.1.2. Approach II: Proxy Forwards . . . . . . . . . . . . . 7
3.1.3. Approach III: UA Proxies . . . . . . . . . . . . . . . 7 3.1.3. Approach III: UA Proxies . . . . . . . . . . . . . . . 8
3.1.4. Approach IV: Call Processing Language . . . . . . . . 8 3.1.4. Approach IV: Call Processing Language . . . . . . . . 9
3.1.5. Failure Cases . . . . . . . . . . . . . . . . . . . . 9 3.1.5. Failure Cases . . . . . . . . . . . . . . . . . . . . 10
3.1.5.1. No One Implements . . . . . . . . . . . . . . . . 10 3.1.5.1. No One Implements . . . . . . . . . . . . . . . . 11
3.1.5.2. Both Implement . . . . . . . . . . . . . . . . . . 10 3.1.5.2. Both Implement . . . . . . . . . . . . . . . . . . 11
3.1.5.3. Missing Half . . . . . . . . . . . . . . . . . . . 10 3.1.5.3. Missing Half . . . . . . . . . . . . . . . . . . . 11
4. Solution Considerations . . . . . . . . . . . . . . . . . . . 10 4. Solution Considerations . . . . . . . . . . . . . . . . . . . 11
5. BLISS Solution Framework . . . . . . . . . . . . . . . . . . . 12 5. BLISS Solution Framework . . . . . . . . . . . . . . . . . . . 13
5.1. Phase I - Identify a Feature Group . . . . . . . . . . . . 12 5.1. Phase I - Identify a Feature Group . . . . . . . . . . . . 13
5.2. Phase II - Submit Feature Flows . . . . . . . . . . . . . 13 5.2. Phase II - Gather Data . . . . . . . . . . . . . . . . . . 15
5.3. BLISS Phase III - Problem Definition . . . . . . . . . . . 14 5.3. BLISS Phase III - Problem Definition . . . . . . . . . . . 15
5.4. BLISS Phase 4 - Minimum Interop Definition . . . . . . . . 15 5.4. BLISS Phase 4 - Minimum Interop Definition . . . . . . . . 16
6. Structure of the BLISS Final Deliverable . . . . . . . . . . . 16 6. Structure of the BLISS Final Deliverable . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
9. Informative References . . . . . . . . . . . . . . . . . . . . 17 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17 10. Informative References . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
Intellectual Property and Copyright Statements . . . . . . . . . . 20
1. Introduction 1. Introduction
The Session Initiation Protocol (SIP) [RFC3261] has been designed as The Session Initiation Protocol (SIP) [RFC3261] has been designed as
a general purpose protocol for establishing and managing multimedia a general purpose protocol for establishing and managing multimedia
sessions. In this role, it provides many core functions and sessions. In this role, it provides many core functions and
extensions to support "session management features". In this extensions to support "session management features". In this
context, session management features (or just features in this context, session management features (or just features in this
specification) are operations, typically invoked by the user, that specification) are operations, typically invoked by the user, that
provide some form value-added functionality within the context of a provide some form value-added functionality within the context of a
skipping to change at page 3, line 26 skipping to change at page 3, line 26
conferences, having calls automatically forwarded, and so on. conferences, having calls automatically forwarded, and so on.
The SIP specification itself includes primitives to support some of The SIP specification itself includes primitives to support some of
these features. For example, RFC 3264 [RFC3264] defines SDP these features. For example, RFC 3264 [RFC3264] defines SDP
signaling parameters for placing a call on hold. Numerous SIP signaling parameters for placing a call on hold. Numerous SIP
extensions have been developed which focus on functionality needed extensions have been developed which focus on functionality needed
for session management features. The REFER specification, RFC 3515 for session management features. The REFER specification, RFC 3515
[RFC3515], defines a primitive operation for a user agent to ask [RFC3515], defines a primitive operation for a user agent to ask
another user agent to send a SIP request, typically to initiate a another user agent to send a SIP request, typically to initiate a
session. REFER is used to support many features, such as transfer, session. REFER is used to support many features, such as transfer,
park, and refer. The Replaces specification, RFC 3891 [RFC3891], park, and hold. The Replaces specification, RFC 3891 [RFC3891],
allows one dialog to replace another. This header field is useful allows one dialog to replace another. This header field is useful
for consultation transfer features. The dialog event package, RFC for consultation transfer features. The dialog event package, RFC
4235 [RFC4235], allows one UA to learn about the dialog states on 4235 [RFC4235], allows one UA to learn about the dialog states on
another UA. This package is useful for features such as shared line. another UA. This package is useful for features such as shared line.
However, despite this veritable plethora of specifications that can However, despite this veritable plethora of specifications that can
support session management features, in practice, interoperability support session management features, in practice, interoperability
has been quite poor for these kinds of functions. One user agents has been quite poor for these kinds of functions. When user agents
from one vendor are connected to servers and user agents from other from one vendor are connected to servers and user agents from other
vendors, very few of these types of features actually work. In most vendors, very few of these types of features actually work. In most
cases, call hold and basic transfer are broadly interoperable, but cases, call hold and basic transfer are broadly interoperable, but
more advanced features such as park and resume, music-on-hold, and more advanced features such as park and resume, music-on-hold, and
shared line appearances, do not work. shared line appearances, do not work.
In some cases, these interoperability failures are the fault of poor In some cases, these interoperability failures are the fault of poor
implementations. In other cases, they are purposeful failures, meant implementations. In other cases, they are purposeful failures, meant
to ensure that third party equipment is not utilized in a vendor's to ensure that third party equipment is not utilized in a vendor's
solution. However, in many cases the problem is with the solution. However, in many cases the problem is with the
skipping to change at page 4, line 32 skipping to change at page 4, line 32
SIP is typically deployed in environments a large number of user SIP is typically deployed in environments a large number of user
agents and some number of servers, such as proxy servers, registrars, agents and some number of servers, such as proxy servers, registrars,
feature servers, and so on. Put together, these form a distributed feature servers, and so on. Put together, these form a distributed
system used to realize a multimedia communications network. system used to realize a multimedia communications network.
Architecturally, a SIP-based multimedia network can be though of as a Architecturally, a SIP-based multimedia network can be though of as a
distributed state machine. Each node in the network implements a distributed state machine. Each node in the network implements a
state machine, and messages sent by the protocol serve the purpose of state machine, and messages sent by the protocol serve the purpose of
synchronizing the state machines across nodes. If one considers synchronizing the state machines across nodes. If one considers
these session management features (hold, transfer, park, etc.), each these session management features (hold, transfer, park, etc.), each
of them is ultimately trying to achieve a change in states in the of them is ultimately trying to achieve a state change in the state
state machines of two or more nodes in the network. Call hold, for machines of two or more nodes in the network. Call hold, for
example, attempts to change the state of media transfer between a example, attempts to change the state of media transfer between a
pair of user agents. More complex features, such as transfer, are an pair of user agents. More complex features, such as transfer, are an
attempt to synchronize dialog and call states across three or more attempt to synchronize dialog and call states across three or more
user agents. In all cases, SIP messaging is used between these user agents. In all cases, SIP messaging is used between these
agents to change the state machinery of the protocol. agents to change the state machinery of the protocol.
If we consider a particular feature, the protocol machinery for If we consider a particular feature, the protocol machinery for
accomplishing the feature requires logic on each node involved in the accomplishing the feature requires logic on each node involved in the
feature. Let us say that feature X can be implemented using two feature. Let us say that feature X can be implemented using two
different techniques - X.1 and X.2. Each technique is composed of a different techniques - X.1 and X.2. Each technique is composed of a
skipping to change at page 5, line 12 skipping to change at page 5, line 12
the logic for X.2, the outcome is unpredicable and the feature may the logic for X.2, the outcome is unpredicable and the feature may
not interoperate. not interoperate.
We call this problem "the confusion of tongues". It arises whenever We call this problem "the confusion of tongues". It arises whenever
there is more than one way to implement a particular feature amongst there is more than one way to implement a particular feature amongst
a set of nodes. While each approach is, by itself, conformant to the a set of nodes. While each approach is, by itself, conformant to the
specifications, there are interoperability failures because of a specifications, there are interoperability failures because of a
heterogeneous selection of methodologies within a particular heterogeneous selection of methodologies within a particular
deployment. deployment.
This problem is ameliorated when the logic required for a particular
feature exists almost entirely within a single node. Any feature
involving multiple parties ultimately requires some form of logic in
other nodes. However, when the logic required for a feature requires
that the other nodes only support for the basic SIP specs - [RFC3261]
and [RFC3263] - we call this a single ended feature. Single-ended
features tend to be more interoperable because they rely on just the
lingua franca - basic SIP - from everyone else. An example of a
single-ended feature is mute, which can be done locally within a node
without any signaling at all. Another feature is basic hold (without
music), which requires only that the other side support [RFC3263].
Unfortunately, many features are fundamentally not single ended. A
feature that is not single ended is called a multi-ended feature.
Examples include transfer (which relies on at least support for
REFER) and music-on-hold.
3. Concrete Examples 3. Concrete Examples
Several concrete examples can be demonstrated which show this Several concrete examples can be demonstrated which demonstrate the
problem. confusion of tongues.
3.1. Call Forward No Answer 3.1. Call Forward No Answer
Call Forward No Answer (CFNA), is a very basic feature. In this Call Forward No Answer (CFNA), is a very basic feature. In this
feature, user X calls user Y. If user Y is not answering, the call is feature, user X calls user Y. If user Y is not answering, the call is
forwarded to another user, user Z. Typically this forwarding takes forwarded to another user, user Z. Typically this forwarding takes
place after a certain amount of time. place after a certain amount of time.
Even for a simple feature like this, there are several ways of Even for a simple feature like this, there are several ways of
implementing it. Consider the reference architecture in Figure 1. implementing it. Consider the reference architecture in Figure 1.
skipping to change at page 9, line 46 skipping to change at page 10, line 46
logic in the proxy is guided by the CPL script. logic in the proxy is guided by the CPL script.
3.1.5. Failure Cases 3.1.5. Failure Cases
We have now described four different call forwarding implementations. We have now described four different call forwarding implementations.
All four are compliant to RFC 3261. All four assume some form of All four are compliant to RFC 3261. All four assume some form of
"feature logic" in some of the components in order to realize this "feature logic" in some of the components in order to realize this
feature. For Approach I, this logic is entirely in the UA, and feature. For Approach I, this logic is entirely in the UA, and
consists of the activation of the feature, configuration of the consists of the activation of the feature, configuration of the
forward-to URI, execution of the timer, and then causing of a forward-to URI, execution of the timer, and then causing of a
redirect to the forward-to URI. In approach I, no other logic beyond redirect to the forward-to URI. This implementation of the feature
RFC 3261 compliance is needed. For approach II, the logic is is single ended. For approach II, the logic is entirely in the
entirely in the proxy, and consists of the activation of the feature proxy, and consists of the activation of the feature through the web,
through the web, configuration of the forward-to URI through the web, configuration of the forward-to URI through the web, execution of the
execution of the timer, and then causing of CANCEL and sequential timer, and then causing of CANCEL and sequential fork to the
fork to the forward-to URI. In approach II, no other "feature logic" forward-to URI. This implementation approach is also single-ended.
is required on any other component. In approach III, all of the
logic exists on the UA, and consists of the activation of the In approach III, all of the logic exists on the UA, and consists of
feature, configuration of the forward-to URI, execution of the timer, the activation of the feature, configuration of the forward-to URI,
and then causing of a proxy to the forward-to URI. In approach IV, execution of the timer, and then causing of a proxy to the forward-to
all of the feature logic is in the proxy, but it is implemented by URI. This approach is also single-ended. In approach IV, all of the
CPL, and the UA has a CPL implementation that establishes the feature logic is in the proxy, but it is implemented by CPL, and the
forwarding number configuration. UA has a CPL implementation that establishes the forwarding number
configuration. Consequently, this approach is multi-ended.
If one considers several different combinations of implementation, If one considers several different combinations of implementation,
several error cases arise. several error cases arise.
3.1.5.1. No One Implements 3.1.5.1. No One Implements
In this case, the UA assumes approach II (that is, it assumes the In this case, the UA assumes approach II (that is, it assumes the
proxy handles call forwarding), while the proxy assumes approaches I proxy handles call forwarding), while the proxy assumes approaches I
or III (that is, the UA handles call forwarding). In this case, the or III (that is, the UA handles call forwarding). In this case, the
call will arrive at the proxy, which forwards it to UA Y, where it call will arrive at the proxy, which forwards it to UA Y, where it
skipping to change at page 11, line 16 skipping to change at page 12, line 16
configured (timeout, activation state, call forwarding URI), and configured (timeout, activation state, call forwarding URI), and
describe the timer and how it operates. This approach would actually describe the timer and how it operates. This approach would actually
lead to excellent interoperability, but would come at high cost. The lead to excellent interoperability, but would come at high cost. The
set of interoperable features would be limited to only those which we set of interoperable features would be limited to only those which we
explicitly specify, and there would be little room for innovation. explicitly specify, and there would be little room for innovation.
To avoid this pitfall and others like it, a proper solution to the To avoid this pitfall and others like it, a proper solution to the
interoperability has to be structured in such a way that it achieves interoperability has to be structured in such a way that it achieves
the following goals: the following goals:
Covers Everything: Ultimately, the goal of the solution is to make
things work in reality. This means that the solution has to cover
all aspects of the feature that can be a source of
interoperability problems. This includes traditional signaling,
media, and even provisioning and configuration issues. For
example, the failure of Section 3.1.5.3 was caused by an
inconsistent provisioning mechanism between the UA and the server.
Consequently, interoperability requires this mechanism to be
agreed upon to the degree required for interop. The objective of
BLISS is that the resulting specifications ensure that you can
take a UA from one vendor, plug it into the server of another, and
it works - full stop.
Avoid Enumeration: One of the main goals of SIP is to provide a rich Avoid Enumeration: One of the main goals of SIP is to provide a rich
set of features. If it requires a specification to be developed set of features. If it requires a specification to be developed
for each and every feature, this goal of SIP is lost. Instead, for each and every feature, this goal of SIP is lost. Instead,
SIP will be limited to a small number of features and it will be SIP will be limited to a small number of features and it will be
hard to add new ones. Therefore, any solution to the hard to add new ones. Therefore, any solution to the
interoperability problem must avoid the need to enumerate each and interoperability problem must avoid the need to enumerate each and
every feature and document something about it. every feature and document something about it.
Allow Variability in Definition: It should not be necessary to Allow Variability in Definition: It should not be necessary to
rigorously define the behavior of any particular feature. It is rigorously define the behavior of any particular feature. It is
skipping to change at page 12, line 28 skipping to change at page 13, line 44
5. BLISS Solution Framework 5. BLISS Solution Framework
The framework for solving this interoperability dilemma is called The framework for solving this interoperability dilemma is called
BLISS - Basic Level of Interoperability for SIP Services. This BLISS - Basic Level of Interoperability for SIP Services. This
solution is actually a process that a working group can follow to solution is actually a process that a working group can follow to
identify interoperability problems and then develop solutions. identify interoperability problems and then develop solutions.
5.1. Phase I - Identify a Feature Group 5.1. Phase I - Identify a Feature Group
The first step is to identify a set of features which have been known The first step is to identify a feature or set of features which have
to be problematic in actual deployments. These features are been known to be problematic in actual deployments. These features
collected into bundles called a feature group. A feature group is a are collected into bundles called a feature group. A feature group
collection of actual features that all have a similar flow, and for is a collection of actual features that all have a similar flow, and
which it is believed the source of interoperability failures may be for which it is believed the source of interoperability failures may
common. For example, Call Forward No Answer, Call Forward Busy, Call be common. A feature group can also have just one feature. For
Forward Unconditional are all very similar, and clearly all have the example, Call Forward No Answer, Call Forward Busy, Call Forward
same interoperability problem described in Section 3.1. However, the Unconditional are all very similar, and clearly all have the same
root issue with these flows is that there needs to be a common interoperability problem described in Section 3.1. However, the root
issue with these flows is that there needs to be a common
understanding of where call treatment feature logic is executed, and understanding of where call treatment feature logic is executed, and
how the desired treatment is signaled from the user to the place how the desired treatment is signaled from the user to the place
where it is implemented. Thus, other features that are similar, in where it is implemented. Thus, other features that are similar, in
that they make a decision on call handling based on user input or that they make a decision on call handling based on user input or
conditions, will likely also benefit from consideration. conditions, will likely also benefit from consideration.
Thus, a feature group is defined by a characteristic that identifies Thus, a feature group is defined by a characteristic that identifies
a large (and in fact, possibly infinite) number of actual "features" a large (and in fact, possibly infinite) number of actual "features"
that all belong to the group. This characteristic is called its that all belong to the group. This characteristic is called its
functional primitive. The first step in the BLISS process is to functional primitive. The first step in the BLISS process is to
identify feature groups and their functional primitives that are identify feature groups and their functional primitives that are
narrow enough so they are meaningful, yet broad enough that they are narrow enough so they are meaningful, yet broad enough that they are
not overly constraining. This is not exact, and the initial not overly constraining. This is not exact, and the initial
definitions do not need to be exact. They can be refined as the definitions do not need to be exact. They can be refined as the
BLISS process proceeds. In the case of CFNA, clearly a functional BLISS process proceeds. Indeed, in many cases, investigations can
primitive of "call forwarding features that execute on no-answer" is start with a single feature - for example call park - and analysis
too narrow. A functional primitive of "features that handle an can proceed with just one. As work proceeds, the definition of the
initial INVITE" is too broad. An ideal starting point would probably feature group can be broadened. In the case of CFNA, clearly a
be, "features that result in a retargeting or response operation that functional primitive of "call forwarding features that execute on no-
depend on user-specified criteria". This covers all of the call answer" is too narrow. A functional primitive of "features that
forwarding variations, but also includes features like Do-Not- handle an initial INVITE" is too broad. An ideal starting point
Disturb. would probably be, "features that result in a retargeting or response
operation that depend on user-specified criteria". This covers all
of the call forwarding variations, but also includes features like
Do-Not-Disturb.
Each feature group should be defined in a similar way, through the Each feature group should be defined in a similar way, through the
definition of a functional primitive by which one could decide definition of a functional primitive by which one could decide
whether or not a particular feature was included. As part of this whether or not a particular feature was included. As part of this
definition, the group can consider specific features and agree definition, the group can consider specific features and agree
whether or not they are covered by the primitive. For example, would whether or not they are covered by the primitive. For example, would
"send call to voicemail" be covered by the functional primitive "send call to voicemail" be covered by the functional primitive
"features that result in a retargeting or response operation that "features that result in a retargeting or response operation that
depend on user-specified criteria"? The answer is yes in this case. depend on user-specified criteria"? The answer is yes in this case.
Discussion of what features are covered by a functional primitive is Discussion of what features are covered by a functional primitive is
part of the discussion in this phase. part of the discussion in this phase.
Care must be taken not to define the functional primitive in such a Care must be taken not to define the functional primitive in such a
way as to eliminate the possibility of any but a defined and way as to eliminate the possibility of any but a defined and
enumerated set of features from being included. The functional enumerated set of features from being included. The functional
primitive should clearly cover features which are in existence today, primitive should clearly cover features which are in existence today,
and of interest, but allow for future ones that could be covered by and of interest, but allow for future ones that could be covered by
the primitive. This avoids the perils of enumeration as discussed in the primitive. This avoids the perils of enumeration as discussed in
Section 4. Section 4.
5.2. Phase II - Submit Feature Flows 5.2. Phase II - Gather Data
With the functional primitive identified and a shared understanding With the functional primitive identified and a shared understanding
of which features fit within it, the next step is for working group of which features fit within it, the next step is for working group
participants to document how their implementations implement features participants to document how their implementations implement features
in the group. This takes the form of call flows along with in the group.
explanatory text that clearly articulates what kind of logic,
specific to that feature, is assumed in each component of the system.
The approaches for CFNA documented in Section 3.1 are exactly what is
required at this stage. Ideally, there would be a document submitted
to the working group for each implementation. For example, "Company
Foo Flows for Call Forward" would be a document submitted by an
employee of company Foo, documenting their flow for call forward.
THis document can include flows for each variation that the
implementation supports. For example, it might have a separate call
flow documented for CFNA, for CFB, and for CFU.
Obviously, other documentation procedures are possible. A single This can be done any number of ways. Ideally, call flows would be
editor can work with a team, and the team all suggest specific flows collected that document the mechanism implemented by each vendor.
that are accumulated into one document. This avoids the need for However, experience has shown that vendors frequently consider this
vendor-specific documents. Participants can also suggest flows they information proprietary or sensitive. An alternate model is to
think might exist or might work, even if there is no known define a survey which asks high level questions about how the feature
implementation of the flow. That is fine too. The primary objective or feature group is implemented. Yet another model is to merely ask
of this phase is to collect as many flows as possible for features vendors to submit freeform text which describes their implementation.
that are covered by the feature group definition.
It is a decision of the working group as to whether to actually It is a decision of the working group as to whether to actually
publish these flows as an RFC, or to use the flows as working publish the collected information as an RFC, use them as a working
documents. The flows themselves are not actually the output of the internet draft, or just keep them on a web page. The gathered data
BLISS process; they are only an intermediate step. If the flows are is not an output of the BLISS process; they are only an intermediate
to be published as an RFC, it is suggested that a single document be step. If the information is to be published as an RFC, it is
published for each functional primitive. The title of the document suggested that a single document be published for each functional
would be something like, "Enumeration of Existing Practices for Foo" primitive. The title of the document would be something like,
where "Foo" is some moniker for the functional primitive. Such a "Enumeration of Existing Practices for Foo" where "Foo" is some
document must be clear that it is NOT a best practice. It would moniker for the functional primitive. Such a document must be clear
strictly be informational. The document would have subsections for that it is NOT a best practice. It would strictly be informational.
each flow contributed and considered by the group.
5.3. BLISS Phase III - Problem Definition 5.3. BLISS Phase III - Problem Definition
With flows for a particular feature group collected, the next step in With current practice for a particular feature group collected, the
the process is to an analysis on the flows. The analysis considers next step in the process is to an analyze the data. The analysis
each permutation of implementation of logic from the flows submitted considers each permutation of implementation of logic from the data
in the previous phase, and determines which combinations work, and gathered in the previous phase, and determines which combinations
which ones do not. work, and which ones do not.
General speaking, this analysis is performed by taking the components General speaking, this analysis is performed by taking the components
associated with the feature (for example, in the case of CFNA, there associated with the feature (for example, in the case of CFNA, there
are four components - three UA and one proxy), and for each one are four components - three UA and one proxy), and for each one
considering what happens when it implements one of the logical considering what happens when it implements one of the logical
behaviors identified in the flow documents from the previous phase. behaviors identified in the cases identified from the previous phase.
Thus, if four variations on a feature have been submitted to the Thus, if four variations on a feature have been submitted to the
group, and that feature has four components, there are 16 possible group, and that feature has four components, there are 16 possible
deployment scenarios that can be considered. In practice, many of deployment scenarios that can be considered. In practice, many of
these are equivalent or moot, and therefore the number in practice these are equivalent or moot, and therefore the number in practice
will be much smaller. The group should work to identify those cases will be much smaller. The group should work to identify those cases
that are going to be of interest, and then based on the logic in each that are going to be of interest, and then based on the logic in each
component, figure out where interoperability failures occur. component, figure out where interoperability failures occur.
This phase can be accomplished using documents that contain flows, or This phase can be accomplished using documents that contain flows, or
can be purely a thinking exercise carried out on the mailing list. can be purely a thinking exercise carried out on the mailing list or
In all likelihood, it will depend on the feature group and the level in a design team. In all likelihood, it will depend on the feature
of complexity. Regardless of the intermediate steps, the end goal of group and the level of complexity. Regardless of the intermediate
this phase should be an enumeration of combinations with known steps, the end goal of this phase should be an enumeration of
interoperability problems. This output would look exactly like the combinations with known interoperability problems. One possible
contents of Section 3.1.5, which describe several failure modes that output would look exactly like the contents of Section 3.1.5, which
are possible. describe several failure modes that are possible.
5.4. BLISS Phase 4 - Minimum Interop Definition 5.4. BLISS Phase 4 - Minimum Interop Definition
The final step in the BLISS process is to repair the interopreability The final step in the BLISS process is to repair the interopreability
failures identified in the previous phase. This is done by coming up failures identified in the previous phase. This is done by coming up
with a set of recommendations on behaviors of various components, with a set of recommendations on behaviors of various components,
such that, were those rules to be followed, those interoperability such that, were those rules to be followed, those interoperability
failure cases would not have occurred. failure cases would not have occurred.
In some cases, these recommendations identify a place in the network In some cases, these recommendations identify a place in the network
skipping to change at page 17, line 18 skipping to change at page 18, line 27
7. Security Considerations 7. Security Considerations
Interoperability of security functions is also a critical part of the Interoperability of security functions is also a critical part of the
overall interoperability problem, and must be considered as well. overall interoperability problem, and must be considered as well.
8. IANA Considerations 8. IANA Considerations
There are no IANA considerations associated with this specification. There are no IANA considerations associated with this specification.
9. Informative References 9. Acknowledgements
I'd like to thank Shida Schubert, Jason Fischl, and John Elwell for
actually running the BLISS process and providing feedback on its
effectiveness.
10. Informative References
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M., and E. A., Peterson, J., Sparks, R., Handley, M., and E.
Schooler, "SIP: Session Initiation Protocol", RFC 3261, Schooler, "SIP: Session Initiation Protocol", RFC 3261,
June 2002. June 2002.
[RFC3263] Rosenberg, J. and H. Schulzrinne, "Session Initiation
Protocol (SIP): Locating SIP Servers", RFC 3263,
June 2002.
[RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model
with Session Description Protocol (SDP)", RFC 3264, with Session Description Protocol (SDP)", RFC 3264,
June 2002. June 2002.
[RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer [RFC3515] Sparks, R., "The Session Initiation Protocol (SIP) Refer
Method", RFC 3515, April 2003. Method", RFC 3515, April 2003.
[RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation [RFC3891] Mahy, R., Biggs, B., and R. Dean, "The Session Initiation
Protocol (SIP) "Replaces" Header", RFC 3891, Protocol (SIP) "Replaces" Header", RFC 3891,
September 2004. September 2004.
skipping to change at page 19, line 7 skipping to change at page 20, line 7
Cisco Cisco
Edison, NJ Edison, NJ
US US
Phone: +1 973 952-5000 Phone: +1 973 952-5000
Email: jdrosen@cisco.com Email: jdrosen@cisco.com
URI: http://www.jdrosen.net URI: http://www.jdrosen.net
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 24 change blocks. 
104 lines changed or deleted 138 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/