Subject: [BLISS] Revised Charter re-submit

From: Shida Schubert <[email-masked]>
Date: Mon, 07 May 2007 11:27:40 -0700

I haven't received any comments on the revised charter.
So I will try again.. Below is the revised charter reflecting
comments received at IETF 68.

*******************************************************************
BLISS CHARTER
*******************************************************************

-- General Information ------------------

 WG Name : Basic Level of Interoperability for SIP features (BLISS)
 Chairs : Jason Fischl, Shida Schubert
 RAI Area Director(s) : Cullen Jennings and Jon Peterson
 RAI Area Advisor : Cullen Jennings

-- Description of the working group -----

The mandate of this working group is to facilitate effective feature
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.

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, especially for 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
environment, 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 that causes interoperability problems,
figure out a minimum baseline requirement for a UA and servers(minimum set
of primitives etc.), defining minimum levels of functionality 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 features as an initial milestone. Summary for each of the features
are as follows.

 On top of these features, a document describing the problem this working
group is trying to address, criteria to be met for items to be accepted and
template for documenting a draft for this working group will be documented
as a "Problem Statement" chartered to be the first deliverable of this
working group.

Bridged/Shared Line Appearance (BLA/SLA)   

Description: feature 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 feature is generally used by administrative assistants
 taking a calls for an executive. The administrative assistants with
 this feature 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 feature is implemented by various vendors and generally does
not inter-work among devices developed by different vendors.

Call Park/Pickup

Description: feature that allows a person to put a call on hold at one
device and continue the conversation from any other device set.   

Usage: The feature 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 feature is implemented by various vendors and generally does
 not inter-work among devices developed by different vendors.   

Do Not Disturb (DND)

Description: feature that allows a callee to trigger a feature to
 ignore/reject/decline any incoming call.   

Usage: Allows the callee to set up a feature so the phone doesn't
 interfere with the user by means such as muting the phone, forwarding
 to voice-mail etc.

Issue: The feature 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 feature may be implemented but
what feature is supposed to be triggered as well. 

Call Completion to Busy Signal/Call Completion on NO Reply (CCBS/CCNR)   

Description: Allows callers to recognize unavailable (busy, call waiting)
 or unreachable (device turned off, out of feature 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/unreachable
 callee becomes available. Customer feature 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 features installed.

Issue: Interest in this feature has been increasing and various approaches
to satisfy the requirement have been discussed with several variations of
implementations in the wild with potential interoperability issues.

-- Guiding principles for this working group work will include ----

- Identify feature interoperability issues, based on an analysis of
  specific features 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 specific feature
  for addressing the interoperability issue.
    Criteria to consider:   
    * who is responsible for invoking a feature?
    * who is responsible for implementing a feature?   
    * how does the feature interact with multiple media types?
    * how does the feature 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.

 *Deliverable may attempt to...
  1. Define a single approach to solve the problem.
  2. Allow variations but mandate support for more than one mechanism.
  3. Demonstrate that interoperability is possible even when entities
     provide feature differently.

-- Goals and Milestones -------

  Aug 2007 Submit .. Problem Statement
  Dec 2007 Submit .. Bridged Line Appearance
  Apr 2008 Submit .. Call Park/Pickup
  Apr 2008 Submit .. DND
  Aug 2008 Submit .. CCBS/CCNR

*****************************************************************************

Regards
  Shida

_______________________________________________
BLISS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bliss

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 7 May 2007 15:23:54 -0700

>  Aug 2008 Submit .. CCBS/CCNR

Can you update each of these to indicate they type of document. For  
example

  Submit Bridged Line Appearance as BCP

---

From: Shida Schubert <[email-masked]>
Date: Mon, 07 May 2007 15:44:32 -0700

Will do.

 Thanks

---

From: "Jesske, R" <[email-masked]>
Date: Wed, 9 May 2007 10:24:40 +0200

Dear all,
We had discussions about CCBS since 2 Years (see draft-jesske-sipping-tispan-requirements) within IETF. I confused about the timing of CCBS for next year. We see a much higher priority for this issue. Latest end of this year.

Best Regards

Roland

> -----Ursprüngliche Nachricht-----
> Von: Cullen Jennings [mailto:[email-masked]] 
> Gesendet: Dienstag, 8. Mai 2007 00:24
> An: [email-masked]
> Cc: [email-masked]
> Betreff: [BLISS] Re: Revised Charter re-submit
> 
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 May 2007 09:40:24 -0400

Shida,

Here is a point one of my associates identified:

He felt the term "Park/Pickup" was confusing because there is a 
different feature that is often described using the term "Pickup". So he 
wanted the to use a different term here, such as "Park/Park-Retrieval".

I'm not especially hung up about this as long as everyone knows what we 
mean, and the full description that comes with the term makes that clear.

But I think it does raise the question of whether the *other* Pickup 
feature should be on the table as well. He stated this as: "Pickup 
pertains to what may actually be a group of calls across several
phones, in the ringing state, arbitrarily selecting one of the calls,
and moving it to a specific phone."

	Paul

Shida Schubert wrote:
>    Criteria to consider:      * who is responsible for invoking a feature?
>    * who is responsible for implementing a feature?      * how does the 
> feature interact with multiple media types?

---

From: Shida Schubert <[email-masked]>
Date: Mon, 14 May 2007 19:46:08 -0700

Hi,

 Sorry for my belated response.

 The milestone is merely a guide to get work done and to set priority.
If the work is done before the milestone's date, I don't see why it can't
be called to go through WGLC sooner than the current date on the
charter, if you still want to have the date changed on the charter, I think
we need to see what other's thoughts are in this.

 Please speak up if you agree and believe that CCBS/CCNR
can be finished within this year and are ready to contribute your time to
make it happen. Also please speak up if you oppose to the idea of changing
the milestone so CCBS/CCNR is targeted for Dec 2007.

 Regards
  Shida

---

From: "Jesske, R" <[email-masked]>
Date: Tue, 22 May 2007 12:04:34 +0200

Dear Shida,
We think that the work could be done within this year. Martin who is heavily involved within this work can progress it. We can also provide such work power to make it happen. Who can we act further on this issue?

Best Regards

Roland

> Von: Shida Schubert [mailto:[email-masked]] 
> Gesendet: Dienstag, 15. Mai 2007 04:46
> An: Jesske, Roland
> Cc: [email-masked]; [email-masked]; Hülsemann, Martin; 
> [email-masked]
> Betreff: Re: AW: [BLISS] Re: Revised Charter re-submit
> 
> 
> 
> Hi,
> 
> > We had discussions about CCBS since 2 Years (see 
> draft-jesske-sipping-tispan-requirements) within IETF. I 
> confused about the timing of CCBS for next year. We see a 
> much higher priority for this issue. Latest end of this year.
> >
> > Best Regards
> >
> > Roland
> >
> >

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 22 May 2007 08:26:26 -0700

HI All,

Just a note about milestone dates in general ... the chairs can  
change the dates easily at any point to reflect their best guess of  
when the milestone will get done. There is basically just need to  
notify the right folks (including ADs). So if we get the dates wrong  
here, we can easily change them as we learn more and the work  
progresses. That said, it would be nice if the dates were a realistic  
estimate. The important thing to me about the dates is they show the  
order that we expect the work to get done in and they help prioritize  
which items and priority for agenda time.

One other notes is that across IETF, the date estimates are almost  
always too optimistic. If you want to see  some dates that I  
personally got really wrong - check out my original proposed dates  
for the BEHAVE WG :-)

Cullen

PS - Don't let me discourage you - if this can all be done in a year  
I would love to see that happen and though I know past history might  
indicate it will take longer, I see no reason that it could not be  
done in a year. I would like to push RAI to work on less things and  
complete them faster then move on to next thing instead of having a  
zillion things all in slow motion.

On May 22, 2007, at 3:04 AM, Jesske, R wrote:

> Dear Shida,
> We think that the work could be done within this year. Martin who  
> is heavily involved within this work can progress it. We can also  
> provide such work power to make it happen. Who can we act further  
> on this issue?
>
> Best Regards
>
> Roland
>