|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
## BLISSwg
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
Last Update: Feb 27, 2008
-- Color Legend: RFC Editor Queue
/ Processed by IESG
/ ID Exists
/ Recently Expired
-- Each I-D name is a link to an I-D description, which points to a text version, a two-page and fit-in-window PDF version, as well as the IETF Tools' HTML version.
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
## BLISSwg
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
## BLISSwg
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
| The charter of the BLISS working group
is reported below.
|
|
|
|
The focus of the group is to facilitate effective feature
interoperability for features sharing common functional primitives
utilizing SIP in heterogeneous network environments as noted below.
SIP's approach to supporting more advanced features and applications
has been to specify a number of primitive operations, including refer,
dialog replacement and joining, and event packages, and then to allow
those primitives to be combined in many ways to realize different
features. This approach avoids the need for standardized definitions of
a feature, which can severely limit innovation and broad
applicability.
While this approach brings great flexibility and generality, it
complicates interoperability. Without any kind of standardized
definition of a particular feature, each implementation creates its
own definition and corresponding set of call flows and primitives used
to realize this feature. In practice, this has resulted in a poor
track record for interoperability for more advanced features which
make assumptions on supported SIP extensions and behaviors from other
elements.
The problem is exacerbated by the desire for these features to work
across many types of SIP endpoints, including SIP hardphones,
softphones, and gateways to the PSTN and other VoIP networks including
non-centralized environments, and for the desire to work across domain
boundaries and to interwork with the PSTN, when applicable.
The focus will not be on rigorous definition of what the specific
feature is and exactly how it works. Rather, the focus will be on
documenting the variations that exist in the wild sharing common
interop problems, figuring out a minimum baseline requirement for a UA
and servers (minimum set of primitives etc.), defining minimum levels
of functionality and functional primitives required to realize a broad
class of related features, and on interoperating with other elements
which might implement one of those features in different ways.
The BLISS working group will coordinate closely with the SIP and
SIPPING working groups. Like SIPPING, its role is to focus on
applications of the SIP protocol and not on core extensions to SIP
itself. The difference between SIPPING and BLISS, is that BLISS is
focused on a particular type of SIP application - call features, and
in particular, advanced call features requiring non-trivial call
control. SIP applications such as configuration, presence, SIP
extensions for IM, and session policy are clearly out of scope for
BLISS and remain the sole province of SIPPING. Of course, any features
considered by BLISS will support the full range of multimedia
supported by SIP - audio, video, text, messaging, and so on.
The BLISS working group will focus on resolving interpretability issues
on four functional primitives as an initial milestone. Summary for each
of the functional primitives are as follows.
A "Problem Statement" document will also be charted as the first
deliverable of this working group. This document will describe the
problem this working group is trying to address, the criteria to be
met for items to be accepted and a template for documenting a draft
for this working group.
Line Sharing
Description: this covers the functionality required for multiple UA
instances to be able to see and utilize sessions made to/from either
one. It covers a range of features including:
- multiple call appearances
- call suspend/resume
- retrieve
- conference across appearances
Parking
Description: this covers functionality required to move calls from
one instance to another without pre-arranged knowledge of the set of
instances on which the call is to be shared. Basically a dynamic
version of line sharing in a sense. It would cover features including:
- park
- parked retrieval
- directed park
- directed pickup
Automated Handling
Description: this covers functionality required for a user to
indicate, asynchronously from the time of a call, what the handling of
a future call should be. It covers the rules on who implements the
processing and how it is signaled. Covers features including:
- DND
- CFU
- CFNA
Call Queuing
Description: this covers functionality required to queue a call when
the callee is not available, handling of a queue and notifying when
callee is ready to receive a call. Covers features including:
- CCBS
- CCNR
Guiding principles for this working group work will include:
|
|
| - |
Identify functional primitives with interoperability issues, based
on an analysis of variations of features sharing same or similar
functional primitives within heterogeneous network(s). Provide a clear
description of any interoperability problems that are identified by
documenting the variations that exist in the wild for features that is
already implemented.
|
| - |
Document minimum baseline requirements relevant to the functional
requirements for addressing the interoperability issue. Criteria to
consider:
- who is responsible for invoking?
- who is responsible for implementing?
- how does the functional primitive interact with multiple media types?
- how does the functional primitive work between administrative
domains?
|
| - |
Initiate analysis of the pros and cons of key approaches to
addressing the requirements.
|
| - |
Where the requirements can be satisfied within the capabilities of
the current standards, produce BCPs [and appropriate call-flows] to
document the best approach.
|
| - |
Where normal event packages or SIP uri parameter is all what's
needed to prevent interoperability issues, appropriate extensions and
its usage would be defined and documented.
|
| - |
Where extensions to standards are required beyond what's mentioned
above, bring the analysis, requirements and need for new extensions to
the appropriate working group (SIP, SIPPING or SIMPLE).
|
| - |
As in the SIPPING charter, the security of all the deliverables
will be of special importance.
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
## BLISSwg
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
| -
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
## BLISSwg
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
| -
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
## BLISSwg
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
bliss-call-
completion-01
ID Exists
Feb 24, 2008
(28 p.)
[pdf(2)]
[html]
|
D. Worley
M. Huelsemann
D. Alexeitsev |
|
Call Completion for SIP |
|
This document analyzes the interoperability problems surrounding the
call-completion feature that allows a callee to put a caller's
request into a queue by which the caller can be notified to call back
the callee at later time. This document analyzes how different
solutions inter-operate and tries to make recommendation on how to
best meet this requirement.
|
|
|
|
|
|
|
|
|
|
|
| | |
bliss-problem-
statement-02
ID Exists
Feb 24, 2008
(20 p.)
[pdf(2)]
[html]
|
J. Rosenberg |
|
Basic Level of Interoperability for SIP Services (BLISS) Problem Statement |
|
The Session Initiation Protocol (SIP) has been designed as a general
purpose protocol for establishing and managing multimedia sessions.
It provides many core functions and extensions in support of features
such as transferring of calls, parking calls, and so on. However,
interoperability of more advanced features between different vendors
has been poor. This document describes the reason behind these
interoperability problems, and presents a framework for addressing
them.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| Real-time Applications & Infrastructure (RAI) area |
|
|
|
|
|
|
|
##
##
##
##
## BLISSwg
##
##
##
##
##
##
##
##
##
##
##
##
|
|
|
|
|
|
|
|
|
|
| | |
elwell-bliss-
dnd-01
ID Exists
Nov 16, 2007
(13 p.)
[pdf(2)]
[html]
|
J. Elwell
S. Srinivasan |
|
An Analysis of Do Not Disturb (DND) Implementations in SIP |
|
Do Not Disturb (DND) is a commonly used expression for indicating a
condition where a human user of real-time communications does not
wish to be interrupted by incoming calls or other forms of
communication. This document discusses the nature of DND, ways of
observing DND, and limitations of and possible improvements to DND
support in the Session Initiation Protocol (SIP) and the Rich
Presence Information Data Format (RPID).
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
| | |
johnston-bliss-
mla-req-01
ID Exists
Feb 25, 2008
(57 p.)
[pdf(2)]
[html]
|
A. Johnston
M. Soroushnejad
V. Venkataramanan
P. Pepper
A. Kumar |
|
The Multiple Appearance Feature using SIP |
|
This document describes the requirements and implementation of a
group telephony feature commonly known as Bridged Line Appearance
(BLA) or Multiple Line Appearance (MLA), or Shared Call/Line
Appearance (SCA). When implemented using the Session Initiation
Protocol (SIP), it is referred to as Multiple Appearances (MA) since
SIP does not have lines. This feature is commonly offered in the IP
Centrex services and IP-PBX offerings and is likely to be implemented
on SIP IP telephones and SIP feature servers used in a business
environment. This document lists requirements and compares
implementation options for this feature. Extensions to the SIP
dialog event package are proposed.
|
|
|
|
|
|
|
|
|
|
|
| | |
ligot-bliss-
sip-services-
guide-01
ID Exists
Feb 25, 2008
(33 p.)
[pdf(2)]
[html]
|
A. Ligot
T. Froment |
|
Providing guidance for SIP services |
|
Implementing Session Initiation Protocol (SIP) advanced features and
services requires to use numerous specifications. Today, for each
service in the scope of BLISS, one can already find references to
many possible specifications which do not cover the same things.
Some of them are primitive operations, requirements or call flow
examples, some have a scope larger than the others, or can not be
compared at the same level. Very often, architecture hypothesis are
hidden behind the same service name, either assuming that an
intermediary; like an application server, has an active role in the
service, or, as opposed, assuming a pure end-to-end model where only
endpoint implementations are involved. The goal of this document is
not to present the best solutions or give recommendations; but to
give an overview of every standard specification related to these
services, centralizing and categorizing them as input to the working
group.
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
| |
| Up List |
Intended Status: | Informational |
|
|
|
|
|
|
|
|
|
|
