A new IETF working group has been proposed in the RAI Area. The IESG has not made any determination as yet. The following draft charter was submitted, and is provided for informational purposes only. Please send your comments to the IESG mailing list (iesg@ietf.org) by June 4th. +++ Basic Level of Interoperability for SIP Services (bliss) ========================================================= Current Status: Proposed Working Group Chairs: TBD Technical Advisor: TBD RAI Area Advisor : TBD RAI Area Director(s): Cullen Jennings and Jon Peterson Description of the working group: 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. *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 the feature with the functional primitive differently. Goals and Milestones Aug 2007 Submit .. Problem Statement to the IESG as Informational RFC Dec 2007 Submit .. Line Sharing to the IESG as BCP Apr 2008 Submit .. Parking to the IESG as BCP Apr 2008 Submit .. Automated Handling to the IESG as BCP Aug 2008 Submit .. Call Queing to the IESG as BCP _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
