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.

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.

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.

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.

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.

MLA/SLA/BLA Description: 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.

Call Park/Pickup Description: 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.

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 voic 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 voic , 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.

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/unreachable 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.

Guiding Principles

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.

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?

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.

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.

Milestone

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