The mandate of this working group is to facilitate effective service interoperability utilizing SIP

1
The mandate of this working group is to
facilitate effective service interoperability
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.
2
While this approach brings great flexibility and
generality, it complicates interoperability.
Without any kind of standardized definition of a
particular service, each implementation creates
its own definition and corresponding set of call
flows and primitives used to realize this
service. In practice, this has resulted in a poor
track record for interoperability, especially for
features which make assumptions on supported SIP
extensions and behaviors from other elements.
3
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,
and for the desire to work across domain
boundaries and to interwork with the PSTN, when
applicable.
4
The focus will not be on rigorous definition of
what the specific service is and exactly how it
works. Rather, the focus will be on documenting
the variations that exist in the wild, figure
out a minimum baseline requirement for a UA
(minimum set of primitives etc.), defining
minimum levels of functionality required to
realize a broad class of related services, and on
interoperating with other elements which might
implement one of those services in different ways.
5
The BLISS working group will coordinate closely
with the SIP, SIPPING and SIMPLE 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 either SIPPING or SIMPLE. Of course,
any features considered by BLISS will support the
full range of multimedia supported by SIP -
audio, video, text, messaging, and so on.
6
MLA/SLA/BLADescription Service that allows two
or more SIP address to be shared by multiple
devices and allow each device to monitor the
shared line status usage. Usage The service is
generally used by administrative assistants
taking a calls for an executive. The
administrative assistants with this service is
able to pick up the call for the executive which
they share the line with and monitor the busy
status of the executive's device on the shared
line. Issue This service is implemented by
various vendors and generally do not inter-work
among devices developed by different vendors.
7
Call Park/PickupDescription Service that
allows a person to put a call on hold at one
device and continue the conversation from any
other device set. Usage The service allows the
user to move within an office and pick up a call
on hold without the knowledge of the phone to be
used in the destination office. It also allows
the callee to put the caller on hold when the
desired called party is not at the
extension.Issue This service is implemented by
various vendors and generally do not inter-work
among devices developed by different vendors.
8
Do Not Disturb (DND) Description Service that
allows a callee to trigger a feature to
ignore/reject/decline any incoming call. Usage
Allows the callee to set up a service so the
phone doesn't interfere with the user by means
such as muting the phone, forwarding to
voice-mail etc. Issue The service itself has
different ways to deal with the user's
requirement "Do not disturb". Some implementation
simply mutes the phone and forward the call to
voicemail, some returns a busy signal when DND is
set etc. Due to the fact that implementation may
have different interpretations of what "Do not
disturb" is supposed to trigger, interoperability
depends not only on how a service may be
implemented but what feature service is supposed
to be triggered as well.
9
Call Completion (CCBS/CCNR) Description Allows
callers to recognize unavailable (busy, call
waiting) or unreachable (device turned off, out
of service area) parties when the target
(callee) becomes available/ reachable. It gives
the caller the option of receiving a notification
when desired callee is available. Usage Allows
a caller to be alerted when an unavailable/unreach
able callee becomes available. Customer Service
center that receives large volume of calls that
need to put users in a queue, some commercial
stores wanting to provide good customer
experience generally have similar services
installed.Issue Interest in this service has
been increasing and seeing variations in how it
may be implemented.
10
Guiding Principles
11
1. Identify service interoperability issues,
based on an analysis of specific services 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 services that are already
implemented.
12
2. Document minimum baseline requirements
relevant to the specific service for addressing
the interoperability issue. Criteria to
consider who is responsible for invoking a
service? who is respondible for implementing a
service? how does the service interact with
multiple media types? how does the service work
between administrative domains?
13
3. Initiate analysis of the pros and cons of key
approaches to addressing the requirements.4.
Where the requirements can be satisfied within
the capabilities of the current standards,
produce BCPs (and appropriate call-flows) to
document the best approach.
14
5. Where extensions to standards are required,
bring the analysis and need for new extensions to
the appropriate working group (SIP, SIPPING or
SIMPLE).6. As in the SIPPING charter, the
security of all the deliverables will be of
special importance.
15
Milestone
16
Aug 2007 Submit .. BLISS Problem StatementDec
2007 Submit .. Bridged/Shared/Multi Line
Appearance Apr 2007 Submit .. DND Apr 2008
Submit .. Call Park/Pickup Aug 2008 Submit ..
CCBS/CCNR