Subject: [BLISS] features and the dreaded sipping-16

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 11 May 2007 14:12:19 -0400

One of the things we need to have some discussion on, which came up 
during the BoF, is how to scope and define our work in such a way that 
it achieves the following two objectives:

1. makes it clear that, if you are interested in implementing feature X, 
then this is a document containing a set of recommendations you need to 
follow so that you are interoperable for feature X, even including 
diversity in implementation and functionality

2. avoids producing a never-ending series of documents, one for every 
feature and variant out there, producing the SIP equivalent of H.450.X 
and realizing the thing sipping-16 warns against (except it would be 
sipping-3 corresponding to our three documents).

I think you can, in fact, simultaneously achieve these objectives.

The idea is, that there are many aspects of various features that aren't 
sources of interop problems. For example, in the DND case, it really 
doesn't matter whether the call gets forwarded to voicemail, or to an 
IVR, or rejected, when DND is enabled. The interop problem is agreeing 
on how to signal that DND Is required and who implements it. Thus, the 
"DND" problem really covers a bunch of different features which all 
share this common interop problem.

So, I'd suggest that what we are really targeting here are 'functional 
primitives', each of which cover a core capability that is required by 
many features that depend on it. So, we have here three functional 
primitives in our charter:

* "line sharing" - 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" - 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 includign:

   * park
   * parked retrieval
   * directed park
   * directed pickup

and so on

* "automated handling" - 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
   * etc

Indeed, in the 'DND' case, I think its interesting and important to note 
that I believe that the problem covers the various call forwarding and 
call blocking cases too. This really indicates that there is, in fact, a 
common functional primitive that is going to help address a larger 
number of actual features.

I'd suggest that, the *final* deliverable for each of these have a title 
which states the functional primitive, and the abstract describe the 
primitive and enumerate a bunch of features which, if you want to be 
interoperable for, require you to implementthis functional primitive. 
This way, it is clear to marketing folks and product managers that if 
they want the phone to do feature X, this is the spec they need to point 
to, and the phone or other box has to do everything in there.

This structure also sends the clear message that this is not the 
sipping-16 since each document itself allows many features which share 
the same common primitive, including ones we may not have thought of yet.

As part of the development of these final products, I think it would be 
enormously useful to have intermediate drafts which just capture call 
flows for what people do today for the various features within the 
functional primitive. So, we'd have a draft on vendor A's flows for 
shared line (including receiving calls, making calls, holding on one 
line, picking up on another et.c). So we end up with a bunch of these 
documents, we can then sort through what the interop problems would be, 
and produce the actual deliverable, which shows only enough flows to 
demonstrate what the problems are, and then makes recommendations on how 
to fix it. The intermediate drafts could either be published as 
informational or simply discarded once the final product is achieved for 
each functional primitive.

Comments on this proposal?

Thanks,
Jonathan R.
-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

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

---

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

I haven't seen any comments to this, I remember there were
few people at the BoF that had contention to how the current
deliverables were organized (categorized), and it would be good
to hear from those that spoke up at Prague.

 As a personal concern, by broadening the scope to "features that
likely have commonality in ABC" although seems to be a good approach
to avoid the SIPPING-16, it seems to open up a door for 
never ending variations to come in that may utilize the commonality
(sets of primitives) of the deliverable to be considered.

 Any idea to prevent this so we can actually get something out there in
the world in a reasonable time frame?

 Regards
  Shida

Jonathan Rosenberg wrote:
> 1. makes it clear that, if you are interested in implementing feature 
> X, then this is a document containing a set of recommendations you 
> need to follow so that you are interoperable for feature X, even 
> including diversity in implementation and functionality
>
> The idea is, that there are many aspects of various features that 
> aren't sources of interop problems. For example, in the DND case, it 
> really doesn't matter whether the call gets forwarded to voicemail, or 
> to an IVR, or rejected, when DND is enabled. The interop problem is 
> agreeing on how to signal that DND Is required and who implements it. 
> Thus, the "DND" problem really covers a bunch of different features 
> which all share this common interop problem.
>
> UA instances to be able to see and utilize sessions made to/from 
> either one. It covers a range of features including:
>
> * "parking" - 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 includign:
>
>   * park
>   * parked retrieval
>   * directed park
>   * directed pickup
>
> and so on
>
> Indeed, in the 'DND' case, I think its interesting and important to 
> note that I believe that the problem covers the various call 
> forwarding and call blocking cases too. This really indicates that 
> there is, in fact, a common functional primitive that is going to help 
> address a larger number of actual features.
>
> I'd suggest that, the *final* deliverable for each of these have a 
> title which states the functional primitive, and the abstract describe 
> the primitive and enumerate a bunch of features which, if you want to 
> be interoperable for, require you to implementthis functional 
> primitive. This way, it is clear to marketing folks and product 
> managers that if they want the phone to do feature X, this is the spec 
> they need to point to, and the phone or other box has to do everything 
> in there.
>
> As part of the development of these final products, I think it would 
> be enormously useful to have intermediate drafts which just capture 
> call flows for what people do today for the various features within 
> the functional primitive. So, we'd have a draft on vendor A's flows 
> for shared line (including receiving calls, making calls, holding on 
> one line, picking up on another et.c). So we end up with a bunch of 
> these documents, we can then sort through what the interop problems 
> would be, and produce the actual deliverable, which shows only enough 
> flows to demonstrate what the problems are, and then makes 
> recommendations on how to fix it. The intermediate drafts could either 
> be published as informational or simply discarded once the final 
> product is achieved for each functional primitive.
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 15 May 2007 07:37:44 -0400

Shida Schubert wrote:
> to avoid the SIPPING-16, it seems to open up a door for never ending 
> variations to come in that may utilize the commonality

I'm not sure that is really a problem. If there are more related 
submissions for consideration, why not consider them? I don't think 
there will be a never ending set of these things. This will be limited 
by what people are willing to work on.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 15 May 2007 11:44:52 -0400

I agree with Paul here; this is something we can evaluate as we prepare 
the final deliverable. I'd suggest that, for each deliverable, we start 
with the set of features we think is in scope for that, and ask folks to 
contribute flows for those features so we can identify interoperability 
problems. If folks want to contribute flows for other related features, 
the group can evaluate them and decide whether we should consider them 
as part of this functional group or not.

-Jonathan R.