From bliss-bounces@ietf.org Tue May 01 13:36:01 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiwGf-00085B-CX; Tue, 01 May 2007 13:36:01 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HiwGd-000855-Nd for bliss@ietf.org; Tue, 01 May 2007 13:35:59 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HiwGc-0000zF-DI for bliss@ietf.org; Tue, 01 May 2007 13:35:59 -0400 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l41HZrZP012985; Tue, 1 May 2007 11:35:53 -0600 Message-ID: <46377A79.5000308@ntt-at.com> Date: Tue, 01 May 2007 10:35:53 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: bliss@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Subject: [BLISS] [Charter updated..] X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org My sincere apology for this belated update of the charter. I have tried to reflect all the comments that were addressed at the IETF 68. The charter is available at http://www.bliss-ietf.org/charter.txt The diff is available at http://www.bliss-ietf.org/diff3.html Some outstanding issues that I am aware of are: 1. Terms to be used. - Service/Feature are both overloaded, I have used feature for now. I would very much appreciate suggestions. 2. Name of the deliverables. - Current division/naming of deliverables may be too specific to a particular call feature, and it may take us down the path of never-ending flood of work. I see value in continuing the work if there are really a needs. But what I want to avoid is to have to work on a new task just to accommodate small variation that could have been resolved if previous effort was general enough. - For example, pick up/park and BLA may share a lot of similarities as we analyze these features, and may be sensible to consolidate them in one deliverable. But we probably do not realize this until we do enough of the analysis. Now, spending extensive time trying to find commonalities among features that are having interoperability issues in the wild, simply to come up with a right name for the deliverable does not make sense to me. I personally see value and propose to focus on one specific feature at time as it has been stated in the charter, and consolidate the mile stones, when we see the true value in doing so. 3. How to progress the work. - The mandate of this work group is to facilitate effective feature interoperability for those features that are seeing interoperability issues in the wild. More information on variable implementations the better, yet overloading the work group with drafts sharing similar name(abc-mla-01, abc-sla-00, bbc-bla-02, bbs-bla-00 etc.), similar reqs, security considerations and small differences is probably not something we want. - To deal with this dilemma, it may be wise and appropriate to form a design team per milestone. Regards Shida _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri May 04 11:10:48 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjzQl-0000qU-3s; Fri, 04 May 2007 11:10:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HjzQk-0000qP-8p for bliss@ietf.org; Fri, 04 May 2007 11:10:46 -0400 Received: from sea02-mxf01.citel.com ([205.234.66.116]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HjzQj-0000hc-1N for bliss@ietf.org; Fri, 04 May 2007 11:10:46 -0400 Received: from [10.8.50.21] (helo=sea02-mxc01.citel.com) by sea02-mxf01.citel.com with smtp (Exim 4.43) id 1HjzR6-0004Pw-BF; Fri, 04 May 2007 08:11:08 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 4 May 2007 08:08:31 -0700 Message-ID: <0D4E483A0E6E0A46861409E5D6C2011C0971@sea02-mxc01.citel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Minor bug in draft-anil-sipping-bla-04 Thread-index: AceOXhOWTwndegAkSAmEWj7ATy6+ug== From: "Michael Procter" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: anil@yahoo-inc.com, mohsen.soroush@sylantro.com, venkatar@sylantro.com Subject: [BLISS] Minor bug in draft-anil-sipping-bla-04 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org (Not sure if this should be to BLISS or SIPPING - let's try BLISS) Throughout the example messages, in the dialog event package XML, the parameters 'appearance' and '+sip.rendering' are given in the form: The use of 'pvalue' is incorrect, as it conflicts with the schema in RFC 4235. The correct attribute name is 'pval'. The interesting bit of the schema is (from pg 21): Whilst relatively minor, it may cause some interesting interoperability problems when changing it to be correct... Regards, Michael _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon May 07 14:27:52 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl7w7-0004gs-15; Mon, 07 May 2007 14:27:51 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl7w6-0004gn-Ep for bliss@ietf.org; Mon, 07 May 2007 14:27:50 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hl7w5-0006DU-N1 for bliss@ietf.org; Mon, 07 May 2007 14:27:50 -0400 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l47IRejv013025; Mon, 7 May 2007 12:27:41 -0600 Message-ID: <463F6F9C.404@ntt-at.com> Date: Mon, 07 May 2007 11:27:40 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: bliss@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 88b11fc64c1bfdb4425294ef5374ca07 Cc: Subject: [BLISS] Revised Charter re-submit X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org 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 BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon May 07 14:40:25 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl88G-0004UU-Ep; Mon, 07 May 2007 14:40:24 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hl88F-0004UP-GL for bliss@ietf.org; Mon, 07 May 2007 14:40:23 -0400 Received: from smtp7.bbsi.ca ([207.229.55.133] helo=smtp.bbsconnect.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hl88E-0002An-98 for bliss@ietf.org; Mon, 07 May 2007 14:40:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Mon, 7 May 2007 12:40:18 -0600 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Revised Charter re-submit (Shida Schubert) Thread-Index: AceQ1TiuY5q6nhXgToCd8u1QTCpaLwAAUrpw References: From: "Peter Musgrave" To: , X-Spam-Score: 0.1 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [BLISS] Re: Revised Charter re-submit (Shida Schubert) X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Hi Shida,=20 I was wondering about the relationship between the BLISS WG and the work being done in SIP Forum's SIPConnect initiative. The goal of their doc was to define a core set of RFCs for service-provider to enterprise SIP connectivity.=20 Do you see this as being "in scope" for BLISS? I am trying to write some basic interop scenarios for testing at some future SIPIT and trying to decide if this was of interest to BLISS and regarded as in/out of scope.=20 Without knowing all the historical details - it seems to me (perhaps naively) that a basic level of interop with SIP-PSTN providers would be a useful addition to BLISS. Cheers,=20 Peter Musgrave _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon May 07 16:53:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlADE-00085j-Pr; Mon, 07 May 2007 16:53:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlADD-00085e-Gn for bliss@ietf.org; Mon, 07 May 2007 16:53:39 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlADC-0004SM-7D for bliss@ietf.org; Mon, 07 May 2007 16:53:39 -0400 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l47KrbfD001284; Mon, 7 May 2007 14:53:37 -0600 Message-ID: <463F91D1.5010209@ntt-at.com> Date: Mon, 07 May 2007 13:53:37 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Peter Musgrave References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: bliss@ietf.org Subject: [BLISS] Re: Revised Charter re-submit X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Peter; SP to Enterprise interconnectivity in a way SIPConnect defines it, I strongly believe is not within the scope of BLISS. If SP is providing the feature mentioned as a milestone in the charter and interoperability is desired, then SP providing the service is likely to have to implement whatever minimum requirements found necessary to obtain interoperability. If that affects the core set of RFCs listed in SIPConnect so be it. As for your last comment about SIP-PSTN interop, if you are talking about basic interoperability(peering), not that of a specific feature it is not in scope of BLISS. If it's of a specific feature, interaction of a feature with the PSTN-GW to accomplish ineterwoking will be considered, and I believe that is as far as we will go. I hope, I answered your question. Regards Shida Peter Musgrave wrote: > Hi Shida, > > I was wondering about the relationship between the BLISS WG and the work > being done in SIP Forum's SIPConnect initiative. The goal of their doc > was to define a core set of RFCs for service-provider to enterprise SIP > connectivity. > > Do you see this as being "in scope" for BLISS? > > I am trying to write some basic interop scenarios for testing at some > future SIPIT and trying to decide if this was of interest to BLISS and > regarded as in/out of scope. > > Without knowing all the historical details - it seems to me (perhaps > naively) that a basic level of interop with SIP-PSTN providers would be > a useful addition to BLISS. > > Cheers, > > Peter Musgrave > > > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon May 07 18:24:36 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlBdD-0007FQ-AL; Mon, 07 May 2007 18:24:35 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlBdB-0007FK-Si for bliss@ietf.org; Mon, 07 May 2007 18:24:33 -0400 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlBdA-0004iJ-Jm for bliss@ietf.org; Mon, 07 May 2007 18:24:33 -0400 Received: from sj-dkim-5.cisco.com ([171.68.10.79]) by sj-iport-3.cisco.com with ESMTP; 07 May 2007 15:24:32 -0700 X-IronPort-AV: i="4.14,502,1170662400"; d="scan'208"; a="484107424:sNHT45488154" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-5.cisco.com (8.12.11/8.12.11) with ESMTP id l47MOWhJ017558; Mon, 7 May 2007 15:24:32 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l47MOVwo022134; Mon, 7 May 2007 22:24:31 GMT In-Reply-To: <463F6F9C.404@ntt-at.com> References: <463F6F9C.404@ntt-at.com> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Cullen Jennings Date: Mon, 7 May 2007 15:23:54 -0700 To: shida@ntt-at.com X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=369; t=1178576672; x=1179440672; c=relaxed/simple; s=sjdkim5002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20Revised=20Charter=20re-submit |Sender:=20; bh=R1JxQDQm5zMiXGqwwsb9jgTPeDUXQUB9IlEW69EZPwk=; b=UjF4HTH5x8P1xv4FAiZ/kuCJ77/R0Ugd65HGK6RFtWoPc+Lu4J32D2+x/pAET5lMGNGTK83K u4gzKnjdTh9qN8tdPj6elY9NEQkLymaa9VumdXlI/9v+FOYQM8+hB7zP; Authentication-Results: sj-dkim-5; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim5002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: bliss@ietf.org Subject: [BLISS] Re: Revised Charter re-submit X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org On May 7, 2007, at 11:27 AM, Shida Schubert wrote: > 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 Can you update each of these to indicate they type of document. For example Submit Bridged Line Appearance as BCP _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon May 07 18:44:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlBwc-0002I4-Nz; Mon, 07 May 2007 18:44:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlBwa-00029n-PQ for bliss@ietf.org; Mon, 07 May 2007 18:44:36 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlBwY-0001H0-TD for bliss@ietf.org; Mon, 07 May 2007 18:44:36 -0400 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l47MiV1Y024677; Mon, 7 May 2007 16:44:32 -0600 Message-ID: <463FABD0.9030007@ntt-at.com> Date: Mon, 07 May 2007 15:44:32 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Cullen Jennings References: <463F6F9C.404@ntt-at.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Cc: bliss@ietf.org Subject: [BLISS] Re: Revised Charter re-submit X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Will do. Thanks Cullen Jennings wrote: > > On May 7, 2007, at 11:27 AM, Shida Schubert wrote: > >> 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 > > Can you update each of these to indicate they type of document. For > example > > Submit Bridged Line Appearance as BCP > > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue May 08 14:20:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlUIN-0000eM-A5; Tue, 08 May 2007 14:20:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlUIM-0000dw-CC for bliss@ietf.org; Tue, 08 May 2007 14:20:18 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlUIJ-0006bK-VR for bliss@ietf.org; Tue, 08 May 2007 14:20:18 -0400 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 08 May 2007 11:20:15 -0700 X-IronPort-AV: i="4.14,506,1170662400"; d="scan'208"; a="146099598:sNHT45392418" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l48IKF25029983; Tue, 8 May 2007 11:20:15 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l48IICFM000434; Tue, 8 May 2007 18:20:15 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 11:20:04 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 8 May 2007 11:20:04 -0700 Message-ID: <4640BF53.6060009@cisco.com> Date: Tue, 08 May 2007 14:20:03 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: shida@ntt-at.com Subject: Re: [BLISS] Re: Revised Charter re-submit References: <463F91D1.5010209@ntt-at.com> In-Reply-To: <463F91D1.5010209@ntt-at.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 May 2007 18:20:04.0376 (UTC) FILETIME=[7FD2C180:01C7919D] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=2551; t=1178648415; x=1179512415; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BLISS]=20Re=3A=20Revised=20Charter=20re-submit |Sender:=20; bh=HpWOxU1nRdFrOFtUy6JgY8FDIf8hEbCuVGHrD5OTpN0=; b=cDkRBnoDXkKZtLJf/S/LZKyZ66l0CJeuWdUmk5TubkG+b7Oj6Cny6X7E6Ck3YTRhOD9AK0hO XHz8XjK8oRSp2E2IRFusaTrMnfiO8C/hoMkoZArQ/Ip8ZlyLYHGMoqyHkWSIgthvmBsWi4TCr0 1dvhryIehwsDFiT0VI2G2Fmh0=; Authentication-Results: sj-dkim-1; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: bliss@ietf.org, Peter Musgrave X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org I agree with Shida here. Our objectives don't include 'SP to enterprise interconnect', but rather, an examination of various features or feature bundles to make sure we get a minimal set of interoperability guidelines specified. If SIPconnect or some other org wants to point to such a document and say that this is required for a certain use case, then great. -Jonathan R. Shida Schubert wrote: > > Peter; > > SP to Enterprise interconnectivity in a way SIPConnect defines it, I > strongly > believe is not within the scope of BLISS. > > If SP is providing the feature mentioned as a milestone in the charter and > interoperability is desired, then SP providing the service is likely to > have to > implement whatever minimum requirements found necessary to obtain > interoperability. If that affects the core set of RFCs listed in SIPConnect > so be it. > > As for your last comment about SIP-PSTN interop, if you are talking > about basic interoperability(peering), not that of a specific feature it is > not in scope of BLISS. If it's of a specific feature, interaction of a > feature > with the PSTN-GW to accomplish ineterwoking will be considered, and > I believe that is as far as we will go. > > I hope, I answered your question. > > Regards > Shida > > Peter Musgrave wrote: > >> Hi Shida, >> I was wondering about the relationship between the BLISS WG and the work >> being done in SIP Forum's SIPConnect initiative. The goal of their doc >> was to define a core set of RFCs for service-provider to enterprise SIP >> connectivity. >> Do you see this as being "in scope" for BLISS? >> >> I am trying to write some basic interop scenarios for testing at some >> future SIPIT and trying to decide if this was of interest to BLISS and >> regarded as in/out of scope. >> Without knowing all the historical details - it seems to me (perhaps >> naively) that a basic level of interop with SIP-PSTN providers would be >> a useful addition to BLISS. >> >> Cheers, >> Peter Musgrave >> >> >> > > > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > -- Jonathan D. Rosenberg, Ph.D. 600 Lanidex Plaza Cisco Fellow Parsippany, NJ 07054-2711 Cisco Systems jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue May 08 14:25:32 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlUNQ-0005Up-4m; Tue, 08 May 2007 14:25:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlUNP-0005UZ-8d for bliss@ietf.org; Tue, 08 May 2007 14:25:31 -0400 Received: from smtp7.bbsi.ca ([207.229.55.133] helo=smtp.bbsconnect.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlULv-0007Vi-Lp for bliss@ietf.org; Tue, 08 May 2007 14:24:04 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [BLISS] Re: Revised Charter re-submit Date: Tue, 8 May 2007 12:23:54 -0600 Message-ID: In-Reply-To: <4640BF53.6060009@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Re: Revised Charter re-submit Thread-Index: AceRnVb7GsFall2KSVGmC6wm6heGCwAAGcxQ References: <463F91D1.5010209@ntt-at.com> <4640BF53.6060009@cisco.com> From: "Peter Musgrave" To: "Jonathan Rosenberg" , X-Spam-Score: 0.1 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Fair enough.=20 I will continue to work on basic interop use-cases within the context of the techwg at SIPForum.=20 Peter _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Wed May 09 04:24:47 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlhTb-0005eC-4M; Wed, 09 May 2007 04:24:47 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HlhTa-0005e4-7I for bliss@ietf.org; Wed, 09 May 2007 04:24:46 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HlhTY-0008GD-Q1 for bliss@ietf.org; Wed, 09 May 2007 04:24:46 -0400 Received: from s4de8psaans.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Wed, 9 May 2007 10:24:43 +0200 Received: from S4DE8PSAAGO.mitte.t-com.de ([10.151.180.14]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Wed, 9 May 2007 10:24:42 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: [BLISS] Re: Revised Charter re-submit X-Mimeole: Produced By Microsoft Exchange V6.5 Date: Wed, 9 May 2007 10:24:40 +0200 Message-Id: <85108216918A984C8C60172D7C84770A011EF83E@S4DE8PSAAGO.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Re: Revised Charter re-submit Thread-Index: AceQ9oDw9R6GqWqGRKiyf1LbWBdSNQBHG0yg From: "Jesske, R" To: , X-OriginalArrivalTime: 09 May 2007 08:24:42.0708 (UTC) FILETIME=[7E768940:01C79213] X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: esasaki@NTT-AT.COM, bliss@ietf.org, "Huelsemann, Martin" X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org 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=FCngliche Nachricht----- > Von: Cullen Jennings [mailto:fluffy@cisco.com]=20 > Gesendet: Dienstag, 8. Mai 2007 00:24 > An: shida@ntt-at.com > Cc: bliss@ietf.org > Betreff: [BLISS] Re: Revised Charter re-submit >=20 >=20 >=20 > On May 7, 2007, at 11:27 AM, Shida Schubert wrote: >=20 > > 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 >=20 > Can you update each of these to indicate they type of document. For =20 > example >=20 > Submit Bridged Line Appearance as BCP >=20 >=20 > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri May 11 09:40:39 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmVMM-0003Yh-Iy; Fri, 11 May 2007 09:40:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmVML-0003Yc-Nj for bliss@ietf.org; Fri, 11 May 2007 09:40:37 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmVML-0003Xq-7Y for bliss@ietf.org; Fri, 11 May 2007 09:40:37 -0400 Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 11 May 2007 09:40:37 -0400 X-IronPort-AV: i="4.14,523,1170651600"; d="scan'208"; a="59993354:sNHT61160574" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id l4BDeamf005968; Fri, 11 May 2007 09:40:36 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4BDe95x014122; Fri, 11 May 2007 13:40:36 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 09:40:25 -0400 Received: from [161.44.174.124] ([161.44.174.124]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 09:40:24 -0400 Message-ID: <46447248.5040100@cisco.com> Date: Fri, 11 May 2007 09:40:24 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: shida@ntt-at.com Subject: Re: [BLISS] Revised Charter re-submit References: <463F6F9C.404@ntt-at.com> In-Reply-To: <463F6F9C.404@ntt-at.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 May 2007 13:40:25.0029 (UTC) FILETIME=[EDCAD750:01C793D1] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=10073; t=1178890836; x=1179754836; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20Revised=20Charter=20re-submit |Sender:=20 |To:=20shida@ntt-at.com; bh=nVtKGLa2mcnUT4f70jjV+z/vOfiLgoenyOG/0lWWRW4=; b=e7UTGUZ6aw1Q/HC602+5Uqb11T7BRBNIZqO0OT9Ewz4K7SM2iDucKnMkv5qMCFAq/AWUoblj gNaFTpcxSLE0skMoLeBT3iwWxFiFys6KRHoK11MGaLdd+6UbXSIjfmkt; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org 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: > > 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 > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri May 11 14:12:26 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmZbN-0000CJ-Vn; Fri, 11 May 2007 14:12:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HmZbN-0000CC-HM for bliss@ietf.org; Fri, 11 May 2007 14:12:25 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HmZbM-0006H8-0H for bliss@ietf.org; Fri, 11 May 2007 14:12:25 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-5.cisco.com with ESMTP; 11 May 2007 11:12:23 -0700 X-IronPort-AV: i="4.14,523,1170662400"; d="scan'208"; a="421134081:sNHT51584230" Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l4BICNQp013224 for ; Fri, 11 May 2007 11:12:23 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4BICJaK020393 for ; Fri, 11 May 2007 18:12:23 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 11:12:20 -0700 Received: from [10.32.241.146] ([10.32.241.146]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 11 May 2007 11:12:19 -0700 Message-ID: <4644B203.5050100@cisco.com> Date: Fri, 11 May 2007 14:12:19 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: bliss@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 May 2007 18:12:19.0750 (UTC) FILETIME=[EA1FB460:01C793F7] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=4755; t=1178907143; x=1179771143; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20features=20and=20the=20dreaded=20sipping-16 |Sender:=20; bh=veytHmQnHfvoGrKlN0FmOYx5gyodOfwZiMjzwpWzsfU=; b=YI9RO8E86m7LMjzrNuU4OszbqD2iZv4cXjfcCBU4GR+x4BsSz/LwFEzlSms22q8ka9rWVS6B QVZsd/biVIjVKP/tFP0e6Vlof0Ier/LG+XjRqo7YQctDyPyTm3ZD9v99; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Subject: [BLISS] features and the dreaded sipping-16 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org 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 jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Mon May 14 22:46:17 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnn3I-0003QJ-7X; Mon, 14 May 2007 22:46:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hnn3G-0003QE-Vt for bliss@ietf.org; Mon, 14 May 2007 22:46:14 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hnn3F-0002mX-Kz for bliss@ietf.org; Mon, 14 May 2007 22:46:14 -0400 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l4F2k70W001374; Mon, 14 May 2007 20:46:08 -0600 Message-ID: <46491EF0.8020702@ntt-at.com> Date: Mon, 14 May 2007 19:46:08 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: "Jesske, R" Subject: Re: AW: [BLISS] Re: Revised Charter re-submit References: <85108216918A984C8C60172D7C84770A011EF83E@S4DE8PSAAGO.mitte.t-com.de> In-Reply-To: <85108216918A984C8C60172D7C84770A011EF83E@S4DE8PSAAGO.mitte.t-com.de> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by agnada.com id l4F2k70W001374 X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: bliss@ietf.org, "Huelsemann, Martin" , esasaki@ntt-at.com X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org 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 thi= nk 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 changin= g the milestone so CCBS/CCNR is targeted for Dec 2007. Regards Shida =20 Jesske, R wrote: > Dear all, > We had discussions about CCBS since 2 Years (see draft-jesske-sipping-t= ispan-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 th= is year. > > Best Regards > > Roland > > =20 >> -----Urspr=C3=BCngliche Nachricht----- >> Von: Cullen Jennings [mailto:fluffy@cisco.com]=20 >> Gesendet: Dienstag, 8. Mai 2007 00:24 >> An: shida@ntt-at.com >> Cc: bliss@ietf.org >> Betreff: [BLISS] Re: Revised Charter re-submit >> >> >> >> On May 7, 2007, at 11:27 AM, Shida Schubert wrote: >> >> =20 >>> 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 >>> =20 >> Can you update each of these to indicate they type of document. For =20 >> example >> >> Submit Bridged Line Appearance as BCP >> >> >> _______________________________________________ >> BLISS mailing list >> BLISS@ietf.org >> https://www1.ietf.org/mailman/listinfo/bliss >> >> =20 > > > =20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue May 15 00:08:07 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnoKT-0007Ra-VE; Tue, 15 May 2007 00:08:05 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnoKS-0007RU-8x for bliss@ietf.org; Tue, 15 May 2007 00:08:04 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnoKR-0002Q0-Sq for bliss@ietf.org; Tue, 15 May 2007 00:08:04 -0400 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l4F4824N000534; Mon, 14 May 2007 22:08:02 -0600 Message-ID: <46493223.2040206@ntt-at.com> Date: Mon, 14 May 2007 21:08:03 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Jonathan Rosenberg Subject: Re: [BLISS] features and the dreaded sipping-16 References: <4644B203.5050100@cisco.com> In-Reply-To: <4644B203.5050100@cisco.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org 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: > 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. _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue May 15 07:38:02 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnvLs-0001BI-7m; Tue, 15 May 2007 07:38:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnvLr-0001BD-2O for bliss@ietf.org; Tue, 15 May 2007 07:37:59 -0400 Received: from rtp-iport-1.cisco.com ([64.102.122.148]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnvLq-0003Jt-KQ for bliss@ietf.org; Tue, 15 May 2007 07:37:59 -0400 Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 15 May 2007 07:37:58 -0400 X-IronPort-AV: i="4.14,537,1170651600"; d="scan'208"; a="60248058:sNHT53102842" Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id l4FBbw5n030602; Tue, 15 May 2007 07:37:58 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id l4FBbH67011652; Tue, 15 May 2007 11:37:58 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 07:37:45 -0400 Received: from [10.86.242.80] ([10.86.242.80]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 07:37:44 -0400 Message-ID: <46499B88.5090605@cisco.com> Date: Tue, 15 May 2007 07:37:44 -0400 From: Paul Kyzivat User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: shida@ntt-at.com Subject: Re: [BLISS] features and the dreaded sipping-16 References: <4644B203.5050100@cisco.com> <46493223.2040206@ntt-at.com> In-Reply-To: <46493223.2040206@ntt-at.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 May 2007 11:37:44.0994 (UTC) FILETIME=[7485A020:01C796E5] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=5889; t=1179229078; x=1180093078; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20features=20and=20the=20dreaded=20sipping-16 |Sender:=20 |To:=20shida@ntt-at.com; bh=Z0f/wvYsQLxVgxwQipBC/iRc5ql1okybnf0EAOYvo2c=; b=DCvaO6eHx4kmG3nFcxfV+cPthc8H9CX9jibxsBVmwosNWcplYwKL9ur892fXRuxgDGhjb/6+ Ar0a3mk+YHp13ahxeO5s8w9oeBQ5TpRK3C8UfvgLk9FDqs8mrS4+nbGd; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a1852b4f554b02e7e4548cc7928acc1f Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Shida Schubert wrote: > > 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? 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 > Regards > Shida > > Jonathan Rosenberg wrote: >> 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. > > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue May 15 11:44:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnzCr-0002QE-K6; Tue, 15 May 2007 11:44:57 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HnzCr-0002Q1-5v for bliss@ietf.org; Tue, 15 May 2007 11:44:57 -0400 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HnzCo-00052t-Ig for bliss@ietf.org; Tue, 15 May 2007 11:44:57 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 15 May 2007 08:44:53 -0700 X-IronPort-AV: i="4.14,538,1170662400"; d="scan'208"; a="660623:sNHT25426950" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l4FFirPg027975; Tue, 15 May 2007 08:44:53 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l4FFiYtl018778; Tue, 15 May 2007 15:44:53 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 08:44:53 -0700 Received: from [128.107.111.183] ([128.107.111.183]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 15 May 2007 08:44:52 -0700 Message-ID: <4649D574.60907@cisco.com> Date: Tue, 15 May 2007 11:44:52 -0400 From: Jonathan Rosenberg User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050511 X-Accept-Language: en-us, en MIME-Version: 1.0 To: shida@ntt-at.com Subject: Re: [BLISS] features and the dreaded sipping-16 References: <4644B203.5050100@cisco.com> <46493223.2040206@ntt-at.com> In-Reply-To: <46493223.2040206@ntt-at.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 May 2007 15:44:52.0918 (UTC) FILETIME=[FAA74560:01C79707] DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=6317; t=1179243893; x=1180107893; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jdrosen@cisco.com; z=From:=20Jonathan=20Rosenberg=20 |Subject:=20Re=3A=20[BLISS]=20features=20and=20the=20dreaded=20sipping-16 |Sender:=20; bh=EcpRHJ913R8EVxKEr7pth6g95kEcX5E9Uo8O1F+UxEw=; b=T+ligD1LhRKXBrI0XU2oG5bq/bYwDSjiG9hy6DJz/KAyx2F/qKHUXDw+VdXVppD2B48B+Vgj 2elZfbUwL89IYP6y7dq3f53eMdKCkyLNslUR1r5oYEhNIYQ6mLF4kH3+; Authentication-Results: sj-dkim-4; header.From=jdrosen@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org 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. Shida Schubert wrote: > > 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: > >> 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 jdrosen@cisco.com FAX: (973) 952-5050 http://www.jdrosen.net PHONE: (973) 952-5000 http://www.cisco.com _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue May 22 06:04:41 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqREO-0004Ph-Cr; Tue, 22 May 2007 06:04:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqREN-0004Pc-Ht for bliss@ietf.org; Tue, 22 May 2007 06:04:39 -0400 Received: from tcmail31.telekom.de ([217.6.95.238]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqREL-0002ZX-0y for bliss@ietf.org; Tue, 22 May 2007 06:04:39 -0400 Received: from S4DE8PSAANQ.mitte.t-com.de by tcmail31.telekom.de with ESMTP; Tue, 22 May 2007 12:04:35 +0200 Received: from S4DE8PSAAGO.mitte.t-com.de ([10.151.180.14]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.1830); Tue, 22 May 2007 12:04:35 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: AW: AW: [BLISS] Re: Revised Charter re-submit X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Tue, 22 May 2007 12:04:34 +0200 Message-Id: <85108216918A984C8C60172D7C84770A011EF88F@S4DE8PSAAGO.mitte.t-com.de> In-Reply-To: <46491EF0.8020702@ntt-at.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [BLISS] Re: Revised Charter re-submit Thread-Index: AceWmze12qzQnxbZThGGjaxoKyO8FQFvT3vQ From: "Jesske, R" To: X-OriginalArrivalTime: 22 May 2007 10:04:35.0438 (UTC) FILETIME=[99C750E0:01C79C58] X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: bliss@ietf.org, "Huelsemann, Martin" , esasaki@ntt-at.com X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org 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 > -----Urspr=FCngliche Nachricht----- > Von: Shida Schubert [mailto:shida@ntt-at.com]=20 > Gesendet: Dienstag, 15. Mai 2007 04:46 > An: Jesske, Roland > Cc: fluffy@cisco.com; bliss@ietf.org; H=FClsemann, Martin;=20 > esasaki@ntt-at.com > Betreff: Re: AW: [BLISS] Re: Revised Charter re-submit >=20 >=20 >=20 > Hi, >=20 > Sorry for my belated response. >=20 > 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=20 > 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=20 > charter, I think > we need to see what other's thoughts are in this. >=20 > Please speak up if you agree and believe that CCBS/CCNR > can be finished within this year and are ready to contribute=20 > your time to > make it happen. Also please speak up if you oppose to the=20 > idea of changing > the milestone so CCBS/CCNR is targeted for Dec 2007. >=20 > Regards > Shida > =20 > Jesske, R wrote: > > Dear all, > > We had discussions about CCBS since 2 Years (see=20 > draft-jesske-sipping-tispan-requirements) within IETF. I=20 > confused about the timing of CCBS for next year. We see a=20 > much higher priority for this issue. Latest end of this year. > > > > Best Regards > > > > Roland > > > > =20 > >> -----Urspr=FCngliche Nachricht----- > >> Von: Cullen Jennings [mailto:fluffy@cisco.com]=20 > >> Gesendet: Dienstag, 8. Mai 2007 00:24 > >> An: shida@ntt-at.com > >> Cc: bliss@ietf.org > >> Betreff: [BLISS] Re: Revised Charter re-submit > >> > >> > >> > >> On May 7, 2007, at 11:27 AM, Shida Schubert wrote: > >> > >> =20 > >>> 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 > >>> =20 > >> Can you update each of these to indicate they type of=20 > document. For =20 > >> example > >> > >> Submit Bridged Line Appearance as BCP > >> > >> > >> _______________________________________________ > >> BLISS mailing list > >> BLISS@ietf.org > >> https://www1.ietf.org/mailman/listinfo/bliss > >> > >> =20 > > > > > > =20 >=20 >=20 _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Tue May 22 11:26:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqWG1-0008Ra-Dx; Tue, 22 May 2007 11:26:41 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HqWG0-0008RV-FK for bliss@ietf.org; Tue, 22 May 2007 11:26:40 -0400 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HqWFz-0003ER-Om for bliss@ietf.org; Tue, 22 May 2007 11:26:40 -0400 Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 22 May 2007 08:26:39 -0700 X-IronPort-AV: i="4.14,566,1170662400"; d="scan'208"; a="152742344:sNHT47093382" Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id l4MFQdaj029380; Tue, 22 May 2007 08:26:39 -0700 Received: from [72.215.68.171] (sjc-vpn5-243.cisco.com [10.21.88.243]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id l4MFQYtV015722; Tue, 22 May 2007 15:26:38 GMT In-Reply-To: <85108216918A984C8C60172D7C84770A011EF88F@S4DE8PSAAGO.mitte.t-com.de> References: <85108216918A984C8C60172D7C84770A011EF88F@S4DE8PSAAGO.mitte.t-com.de> Mime-Version: 1.0 (Apple Message framework v752.3) Content-Type: text/plain; charset=ISO-8859-1; delsp=yes; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Cullen Jennings Subject: Re: AW: AW: [BLISS] Re: Revised Charter re-submit Date: Tue, 22 May 2007 08:26:26 -0700 To: "Jesske, R" X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=3903; t=1179847599; x=1180711599; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Re=3A=20AW=3A=20AW=3A=20[BLISS]=20Re=3A=20Revised=20Charter=2 0re-submit |Sender:=20; bh=KOhWOCmUF3lD65hdya6qyxOVKb4OuWNB8a3FlK7HQA4=; b=Ri7yZXz/yPmpiK/Hw14KHGlt1zhKiT25m4x/6s3gMbFH3Ed7WoDItVCAvyMXRKYMVJrM/2o+ kD2BgG1mtN06/gEcbbIyWP0qaIw276vIw7m/EEHe7q/RhJgQvSJCAwe9; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Cc: bliss@ietf.org, "Huelsemann, Martin" , esasaki@ntt-at.com X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org HI All, Just a note about milestone dates in general ... the chairs can =20 change the dates easily at any point to reflect their best guess of =20 when the milestone will get done. There is basically just need to =20 notify the right folks (including ADs). So if we get the dates wrong =20 here, we can easily change them as we learn more and the work =20 progresses. That said, it would be nice if the dates were a realistic =20= estimate. The important thing to me about the dates is they show the =20 order that we expect the work to get done in and they help prioritize =20= which items and priority for agenda time. One other notes is that across IETF, the date estimates are almost =20 always too optimistic. If you want to see some dates that I =20 personally got really wrong - check out my original proposed dates =20 for the BEHAVE WG :-) Cullen PS - Don't let me discourage you - if this can all be done in a year =20 I would love to see that happen and though I know past history might =20 indicate it will take longer, I see no reason that it could not be =20 done in a year. I would like to push RAI to work on less things and =20 complete them faster then move on to next thing instead of having a =20 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 =20 > is heavily involved within this work can progress it. We can also =20 > provide such work power to make it happen. Who can we act further =20 > on this issue? > > Best Regards > > Roland > >> -----Urspr=FCngliche Nachricht----- >> Von: Shida Schubert [mailto:shida@ntt-at.com] >> Gesendet: Dienstag, 15. Mai 2007 04:46 >> An: Jesske, Roland >> Cc: fluffy@cisco.com; bliss@ietf.org; H=FClsemann, Martin; >> esasaki@ntt-at.com >> Betreff: Re: AW: [BLISS] Re: Revised Charter re-submit >> >> >> >> Hi, >> >> Sorry for my belated response. >> >> The milestone is merely a guide to get work done and to set =20 >> 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 >> >> Jesske, R wrote: >>> 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=FCngliche Nachricht----- >>>> Von: Cullen Jennings [mailto:fluffy@cisco.com] >>>> Gesendet: Dienstag, 8. Mai 2007 00:24 >>>> An: shida@ntt-at.com >>>> Cc: bliss@ietf.org >>>> Betreff: [BLISS] Re: Revised Charter re-submit >>>> >>>> >>>> >>>> On May 7, 2007, at 11:27 AM, Shida Schubert wrote: >>>> >>>> >>>>> 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 >>>>> >>>> Can you update each of these to indicate they type of >> document. For >>>> example >>>> >>>> Submit Bridged Line Appearance as BCP >>>> >>>> >>>> _______________________________________________ >>>> BLISS mailing list >>>> BLISS@ietf.org >>>> https://www1.ietf.org/mailman/listinfo/bliss >>>> >>>> >>> >>> >>> >> >> _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri May 25 00:21:23 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrRIp-0005fi-AT; Fri, 25 May 2007 00:21:23 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HrRIo-0005fc-Du for bliss@ietf.org; Fri, 25 May 2007 00:21:22 -0400 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HrRIn-0000wm-3R for bliss@ietf.org; Fri, 25 May 2007 00:21:22 -0400 Received: from sj-dkim-8.cisco.com ([171.68.10.93]) by sj-iport-5.cisco.com with ESMTP; 24 May 2007 21:21:20 -0700 X-IronPort-AV: i="4.14,577,1170662400"; d="scan'208"; a="157373311:sNHT40572144" Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-8.cisco.com (8.12.11/8.12.11) with ESMTP id l4P4LKAC026000 for ; Thu, 24 May 2007 21:21:20 -0700 Received: from [192.168.4.177] (sjc-fluffy-vpn1.cisco.com [10.25.236.82]) by sj-core-4.cisco.com (8.12.10/8.12.6) with SMTP id l4P4LJV2023967 for ; Fri, 25 May 2007 04:21:20 GMT Mime-Version: 1.0 (Apple Message framework v752.3) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: bliss@ietf.org From: Cullen Jennings Date: Thu, 24 May 2007 21:20:37 -0700 X-Mailer: Apple Mail (2.752.3) DKIM-Signature: v=0.5; a=rsa-sha256; q=dns/txt; l=145; t=1180066880; x=1180930880; c=relaxed/simple; s=sjdkim8002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Status=20update=20on=20chartering... |Sender:=20; bh=dhH3Q2cIfK58c6DDh/CXMy7v/5an9h3rH4IulCE26Xs=; b=aZpKKIBhIcSsfWuQTC5ZuPOsILWvnJPrULW709iPdZ5vAIXW1EGzDXBbFRMbWplmLyIp9+HX dPEVZLzMJRSfqVZvZ+XKNQWv+mvF8B+kpr2O4OLUaqCXrPV9xkw1s1pp; Authentication-Results: sj-dkim-8; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim8002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 01485d64dfa90b45a74269b3ca9d5574 Subject: [BLISS] Status update on chartering... X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Just wanted to let people know that the IESG discussed the charter today and will soon be sending the charter out for IETF wide last call. _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri May 25 12:58:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hrd7L-00005H-NV; Fri, 25 May 2007 12:58:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hrd7J-00005C-RT for bliss@ietf.org; Fri, 25 May 2007 12:58:17 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hrd7J-0002Uh-CS for bliss@ietf.org; Fri, 25 May 2007 12:58:17 -0400 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l4PGwGPE017516 for ; Fri, 25 May 2007 10:58:16 -0600 Message-ID: <46571599.3080401@ntt-at.com> Date: Fri, 25 May 2007 09:58:01 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: bliss@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c Subject: [BLISS] Charter discussed by the IESG X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Below is the Charter that was submitted to IESG to be discussed. We modified the charter to reflect Jonathan's comments about making the deliverables less specific to a particular feature and to focus on functional primitives. Regards Shida ************** CHARTER TEXT (ver.6) **************************** General Information: Name : Basic Level of Interoperability for SIP Services (BLISS) Chairs : Jason Fischl, Shida Schubert Technical Advisor : Jonathan Rosenberg RAI Area Advisor : Cullen Jennings 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 Queing Description: this covers functionality required to queue a call when the callee is not available, handling of a que 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 *************************************************************** _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss From bliss-bounces@ietf.org Fri May 25 12:59:58 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hrd8w-0000kE-MU; Fri, 25 May 2007 12:59:58 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Hrd8v-0000Zd-3j for bliss@ietf.org; Fri, 25 May 2007 12:59:57 -0400 Received: from agnada.com ([69.36.182.244]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Hrd8s-00030c-Oe for bliss@ietf.org; Fri, 25 May 2007 12:59:57 -0400 Received: from [192.168.1.101] (S0106001839eceb7a.vc.shawcable.net [70.79.14.230]) (authenticated bits=0) by agnada.com (8.12.11.20060308/8.12.11) with ESMTP id l4PGxn76018183; Fri, 25 May 2007 10:59:49 -0600 Message-ID: <465715F7.4020804@ntt-at.com> Date: Fri, 25 May 2007 09:59:35 -0700 From: Shida Schubert User-Agent: Thunderbird 1.5.0.10 (Windows/20070221) MIME-Version: 1.0 To: Cullen Jennings Subject: Re: [BLISS] Status update on chartering... References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: bliss@ietf.org X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: shida@ntt-at.com List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bliss-bounces@ietf.org Cullen; That's great, and thanks for the update. Regards Shida Cullen Jennings wrote: > > Just wanted to let people know that the IESG discussed the charter > today and will soon be sending the charter out for IETF wide last call. > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www1.ietf.org/mailman/listinfo/bliss > > _______________________________________________ BLISS mailing list BLISS@ietf.org https://www1.ietf.org/mailman/listinfo/bliss