From michael@voip.co.uk Mon Jun 8 14:49:23 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6584C3A6820 for ; Mon, 8 Jun 2009 14:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hs1lOVqyT678 for ; Mon, 8 Jun 2009 14:49:22 -0700 (PDT) Received: from na3sys009aog101.obsmtp.com (na3sys009aog101.obsmtp.com [74.125.149.67]) by core3.amsl.com (Postfix) with SMTP id 499123A63CB for ; Mon, 8 Jun 2009 14:49:22 -0700 (PDT) Received: from source ([209.85.218.208]) by na3sys009aob101.postini.com ([74.125.148.12]) with SMTP ID DSNKSi2HZy+6uJhYXAUuGjoSV8g9vIpogYwh@postini.com; Mon, 08 Jun 2009 14:49:28 PDT Received: by bwz4 with SMTP id 4so3820364bwz.6 for ; Mon, 08 Jun 2009 14:49:27 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.248.17 with SMTP id a17mr2578813mus.83.1244497767020; Mon, 08 Jun 2009 14:49:27 -0700 (PDT) In-Reply-To: <20090608214507.8C84B3A6BCA@core3.amsl.com> References: <20090608214507.8C84B3A6BCA@core3.amsl.com> Date: Mon, 8 Jun 2009 22:49:26 +0100 Message-ID: From: Michael Procter To: bliss@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [BLISS] Fwd: New Version Notification for draft-procter-bliss-call-park-extension-05 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2009 21:49:23 -0000 I have updated this draft in the light of recent comments. In particular, the orbit is defined to be a 'pvalue', and I have added some comments concerning policies for implementors. Using GRUUs and ua-privacy are also mentioned as possible ways of meeting the requirements. There is an open issue of a procedural nature in the IANA considerations section, and the Security section could do with some text. Michael ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: 2009/6/8 Subject: New Version Notification for draft-procter-bliss-call-park-extensi= on-05 To: michael@voip.co.uk A new version of I-D, draft-procter-bliss-call-park-extension-05.txt has been successfuly submitted by Michael Procter and posted to the IETF repository. Filename: =A0 =A0 =A0 =A0draft-procter-bliss-call-park-extension Revision: =A0 =A0 =A0 =A005 Title: =A0 =A0 =A0 =A0 =A0 Implementing Call Park and Retrieve using the Se= ssion Initiation Protocol (SIP) Creation_date: =A0 2009-06-08 WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission Number_of_pages: 19 Abstract: Call Park and Call Retrieve are useful telephony services that are familiar to many users. =A0Existing implementations using the Session Initiation Protocol (SIP) show that a variety of approaches can be taken, with varying degrees of interoperability. =A0This draft discusses a number of feature variations, and how they may be implemented using existing techniques. =A0An additional URI parameter is also described, which enables further common use-cases to be implemented. The IETF Secretariat. From dworley@nortel.com Tue Jun 9 11:54:44 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0298D3A6D66 for ; Tue, 9 Jun 2009 11:54:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OMA4LzJMT0eQ for ; Tue, 9 Jun 2009 11:54:43 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 5585F28C1AB for ; Tue, 9 Jun 2009 11:54:42 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n59IrP702959 for ; Tue, 9 Jun 2009 18:53:25 GMT Received: from [47.141.31.232] ([47.141.31.232]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Jun 2009 14:54:39 -0400 From: "Dale Worley" To: BLISS Content-Type: text/plain Organization: Nortel Networks Date: Tue, 09 Jun 2009 14:54:39 -0400 Message-Id: <1244573679.4164.53.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jun 2009 18:54:40.0075 (UTC) FILETIME=[BE3889B0:01C9E933] Subject: [BLISS] draft-ietf-bliss-shared-appearances-02.txt X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2009 18:54:44 -0000 I'd like to ask that a sentence in draft-ietf-bliss-shared-appearances-02 be changed because it is ambiguous and easy to misinterpret. (A developer on the sipXecs project already got caught by it.) It is buried in the example of section 10.4, discussing how the Appearance Agent receives the statuses of appearances and passes them on to subscribing UAs: The Appearance Agent notifies Alice of the same event by forwarding the NOTIFY payload provided by Bob after appropriately changing the dialog id field in the XML payload to a unique value towards each of the entities it is forwarding to (Alice in this example). The problem with the sentence is that it can easily be read to suggest that the NOTIFYs provided by the AA to each subscribing UA are different, whereas the issue really being addressed is the fact that the AA is "unioning" the dialog events provided by the UAs, and in so doing has to make sure the id attributes of the elements are unique within the resulting overall status. I would like to propose this revision: The Appearance Agent notifies Alice (and all other appearances) of the same event by forwarding the NOTIFY payload provided by Bob. Since the Appearance Agent is combining Bob's dialog status with statuses provided by other appearances, it may have to change the dialog id attributes in the XML to prevent values from being duplicated by different appearances. Dale From AUDET@nortel.com Tue Jun 16 17:09:58 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 97A573A67AD for ; Tue, 16 Jun 2009 17:09:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.881 X-Spam-Level: X-Spam-Status: No, score=-5.881 tagged_above=-999 required=5 tests=[AWL=-0.282, BAYES_00=-2.599, J_BACKHAIR_22=1, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6719N4feuGYU for ; Tue, 16 Jun 2009 17:09:57 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 34A123A6849 for ; Tue, 16 Jun 2009 17:09:56 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n5H08dW06511; Wed, 17 Jun 2009 00:08:40 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Jun 2009 19:09:12 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1E8D43C8@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Expert Review requests on Shared Line Appearance thread-index: AcnecT9z79dZMZrFSQKQrc4rGyV1QAQS3A8w References: <1ECE0EB50388174790F9694F77522CCF1E2F8C9B@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: , Cc: "Khan, Sohel" , Shida Schubert Subject: [BLISS] Expert Review requests on Shared Line Appearance X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 00:09:58 -0000 This is my expert review on draft-ietf-bliss-shared-appearances-02. Overall, document is in good shape and has no major issue. It would = benefit from removing a lot of the "historical" or "discussion" material that is not relevant anymore. Also, I make some recommendation on how to make the Call flow examples = clearer. This review also highlights the need for up-issuing = draft-alexeitsev-bliss-alert-infor-urns (which is also needed by external standards bodies). --------------------- Section 1: 4th paragraph. NIT: incomplete sentence "...what gives this feature its.". NIT: s/lamp that can change color or blink/e.g.. a lamp that can change = color or blink, or an screen icon Section 4.2: p. 9, 2nd full paragraph: s/not discussed in this draft but instead is = left as a=20 research project for future standardization/outside the scope of this = draft p. 10, bullet 5: Reword as follows: 5. For outgoing calls, the operation depends on the implementation. If line seizing is supported, the UA publishes this information = and waits for a 200 OK before sending the INVITE. (In other words, some implentations may allow for the user to "select" = the appearance by pressing the button, but not seize the line. For that same reason, = I'm changing "select" to "seize" in a few places in the document). Section 5.3: p. 13, bullet 1: Reword as follows (this is same as previous point): 1. When the user selects a particular appearance number for an = outgoing=20 and wishes to seize the apperance and appearing "off-hook" (if = the UA's user interface uses this methaphor). 2nd paragraph after numbered items: s/UA selects/UA seizes This section needs to describe that either a PUBLISH model or a = SUBSCRIBE model can=20 be used for the state/appearance information to be sent to the = Appearance Agent. Currently, it appears written for the PUBLISH model only. The SUBSCRIBE = model, as=20 illustrated in section 10.13, is very useful for cases where the = Appearance Agent is a stand-alone UA that does not share state/appearance information = with the Proxy/B2BUA. This section also needs to describe that when the SUBSCRIBE = model is used, the NOTIFY message is sent to "seize" a line (there is no need for a = PUBLISH in this case). (I'm assuming I'm right: let's discuss if not). Section 8: Remove Editor's note. Section 9: Delete first paragraph. Clarify the UA also REGISTERs to the AOR. Discuss the security = implications, i.e., you either use the same shared username/password, or you use a different = username/password for HTTP digest, per user. Perhaps the security considerations can be = described in section 15. Section 10: General: The call flows are confusing because Alice is both the end user AOR, as = well as the shared apperance AOR. This makes it very difficult to follow the call = flows. I would like all the call flows to use Alice and Bob as the Endpoint, = and the shared AOR to be, say, sharedline@example.com (or something similar). See below = for details. Section 10.1: p. 22, 2nd paragraph: delete "or Appearance Agent" at end of paragraph. Figure 1 and Call Flow: I would like to also see Bob's registration, to illustrate the idea that Alice and Bob share the same AOR for both=20 registration and subscription. Something like this: Registrar Appearance Agent Alice Bob | | | | | | | | |<--------------------------- REGISTER F1<| | | | | | |>F2 200 OK ----------------------------->| | | | | | | |<----- SUBSCRIBE F3<| | | | | | | |>F4 202 Accepted -->| | | | | | | |>F5 NOTIFY -------->| | | | | | | |<-------- 200 OK F6<| | | | | | |<--------------------------- REGISTER F7---------------<| | | | | |>F8 200 OK -------------------------------------------->| | | | | | |<----- SUBSCRIBE F9---------------<| | | | | | |>---------F10 202 Accepted ------->| | | | | | |>--------F11 NOTIFY -------------->| | | | | | |<-------- 200 OK F12--------------<| The, in the call flows, all the To headers for REGISTER=20 and SUBSCRIBE are instead of=20 . I REALLY think this will make the spec much more readable. Question: Why is "202" used for responding to SUBSCRIBE instead of = "200"? If 202 is used, I think it deserves an explanation in the document. Section 10.2 Again, all the AOR in "To" headers should be = (e.g., F7 & F8). This will help reader's understanding. Alert-Info in F7 should not use a example.=20 Preferably, we need to use a urn, like in = draft-alexeitsev-bliss-alert-infor-urns. For example: Alert-Info: ;alert=3Dnormal;appearances=3D1 Section 10.3 In first paragraph, s/selecting/seizing. It would be useful to show the content of the NOTIFY messages going to = Alice (e.g., F4). I'm a bit confused by this example. It shows Bob making a call NOT using = an=20 appearance (i.e., From: Bob instead of From: sharedline). And then both = Alice and Bob are notified of Bob's state instead of the sharedline? Why is = that a shared appearance scenario??? Section 10.4 Title: s/Pre-Selection/Seizing Again, use sip:sharedline@example.com when appropriate.=20 It would be nice to see the content of message 7. Section 10.5 Again, use sip:sharedline@example.com when appropriate.=20 It would be nice to see the content of message 7. Section 10.7 Are messages F32-F35 necessary when line seizing is NOT used? I think the answer is "no, they would not be used if there is no line seizing". If so, I'd like to see a note explaining it. Section 10.9 Are messages F32-F33 necessary when line seizing is NOT used? I think the answer is "no, they would not be used if there is no line seizing". If so, I'd like to see a note explaining it. Section 10.10 Are messages F22-F23 necessary when line seizing is NOT used? I think the answer is "no, they would not be used if there is no line seizing". If so, I'd like to see a note explaining it. Section 10.13 If the Appearance Agent subscribes to Bob's dialog-event package (as in this example), is the expectation that Bob would never really use=20 PUBLISH, and rather, would always use NOTIFY? I am assuming that the answer is yes. I am also assuming that it would even be the case for the line seizing mechanism. Is this correct? If this is the case, it would be useful to section 10 (before the=20 individual call flows) that all the sections expect 1.13 use a model where the Appearance agent does NOT use a subscription model, but a=20 publish model instead. And then add a note that if a subscription model was used instead, there would be NOTIFYs instead of PUBLISHes, as per=20 section 10.13. Section 11.1 First line: delete "also". Section 12 Appendix A This whole section should not be an Appendix and should be moved to the = core=20 document; it seems this section is necessary for REQ-9. Alert-Info should not use a example.=20 Preferably, we need to use a urn, like in = draft-alexeitsev-bliss-alert-infor-urns. For example: Alert-Info: ;alert=3Dnormal;appearances=3D1 (I think that "tone" one is the default, so we can get rid of the OPEN = issue. Need to add draft-alexeitsev-bliss-alert-infor-urns to References. Also = need to up-issue that draft and move it forward). Section 13: Appendix B I think it is time to remove this whole Appendix B. This whole section = was useful reference when we were discussing various options, but now, it is = totally out of place since the choices have been made. Section 15: Security Considerations See comment on section 9. From shida@agnada.com Tue Jun 16 20:17:13 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9100D3A6DC7 for ; Tue, 16 Jun 2009 20:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.265 X-Spam-Level: X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E+MF5cFT8fVb for ; Tue, 16 Jun 2009 20:17:12 -0700 (PDT) Received: from gateway09.websitewelcome.com (gateway09.websitewelcome.com [69.93.243.4]) by core3.amsl.com (Postfix) with SMTP id ACF773A6B8D for ; Tue, 16 Jun 2009 20:17:12 -0700 (PDT) Received: (qmail 30269 invoked from network); 17 Jun 2009 03:22:11 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway09.websitewelcome.com with SMTP; 17 Jun 2009 03:22:11 -0000 Received: from flh1ajn231.tky.mesh.ad.jp ([125.195.59.231]:63983 helo=[192.168.1.5]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MGle3-0005vX-Of; Tue, 16 Jun 2009 22:17:04 -0500 Message-Id: <5256023D-61D7-48E0-9FEF-8B6A927E2AA4@agnada.com> From: Shida Schubert To: Michael Procter , Scott Orton , Dale Worley , Francois Audet , Andrew Hutton In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 17 Jun 2009 12:17:01 +0900 References: <20090608214507.8C84B3A6BCA@core3.amsl.com> X-Mailer: Apple Mail (2.935.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - agnada.com X-Mailman-Approved-At: Tue, 16 Jun 2009 21:01:59 -0700 Cc: bliss@ietf.org Subject: Re: [BLISS] Fwd: New Version Notification for draft-procter-bliss-call-park-extension-05 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 03:17:13 -0000 All; Are people happy with where the drafts is? There were quite a few people showing interests in the draft and provided comments few weeks back. I would very much appreciate it if the same people who provided comments can have a look at the draft and make sure their concerns are addressed in the revised version. Regards Shida On 9-Jun-09, at 6:49 AM, Michael Procter wrote: > I have updated this draft in the light of recent comments. In > particular, the orbit is defined to be a 'pvalue', and I have added > some comments concerning policies for implementors. Using GRUUs and > ua-privacy are also mentioned as possible ways of meeting the > requirements. > > There is an open issue of a procedural nature in the IANA > considerations section, and the Security section could do with some > text. > > Michael > > > ---------- Forwarded message ---------- > From: IETF I-D Submission Tool > Date: 2009/6/8 > Subject: New Version Notification for draft-procter-bliss-call-park- > extension-05 > To: michael@voip.co.uk > > > > A new version of I-D, draft-procter-bliss-call-park-extension-05.txt > has been successfuly submitted by Michael Procter and posted to the > IETF repository. > > Filename: draft-procter-bliss-call-park-extension > Revision: 05 > Title: Implementing Call Park and Retrieve using the Session > Initiation Protocol (SIP) > Creation_date: 2009-06-08 > WG ID: Independent Submission > Number_of_pages: 19 > > Abstract: > Call Park and Call Retrieve are useful telephony services that are > familiar to many users. Existing implementations using the Session > Initiation Protocol (SIP) show that a variety of approaches can be > taken, with varying degrees of interoperability. This draft > discusses a number of feature variations, and how they may be > implemented using existing techniques. An additional URI parameter > is also described, which enables further common use-cases to be > implemented. > > > > The IETF Secretariat. > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss From wwwrun@core3.amsl.com Mon Jun 22 09:53:07 2009 Return-Path: X-Original-To: bliss@ietf.org Delivered-To: bliss@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 81D0428C1E9; Mon, 22 Jun 2009 09:53:07 -0700 (PDT) To: alan@sipstation.com,mohsen.soroush@sylantro.com,vvenkatar@gmail.com From: IETF Secretariat Message-Id: <20090622165307.81D0428C1E9@core3.amsl.com> Date: Mon, 22 Jun 2009 09:53:07 -0700 (PDT) X-Mailman-Approved-At: Mon, 22 Jun 2009 18:07:50 -0700 Cc: bliss@ietf.org, ipr-announce@ietf.org, rjsparks@nostrum.com Subject: [BLISS] Posting of IPR Disclosure related to Verizon Patent and Licensing Inc.'s Statement about IPR related to draft-ietf-bliss-shared-appearances-02 X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Jun 2009 16:53:07 -0000 Dear Alan Johnston, Mohsen Soroushnejad, Venkatesh Venkataramanan: An IPR disclosure that pertains to your Internet-Draft entitled "Shared Appearances of a Session Initiation Protocol (SIP) Address of Record (AOR)" (draft-ietf-bliss-shared-appearances) was submitted to the IETF Secretariat on 2009-06-19 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1157/). The title of the IPR disclosure is "Verizon Patent and Licensing Inc.'s Statement about IPR related to draft-ietf-bliss-shared-appearances-02." The IETF Secretariat From andrew.hutton@siemens-enterprise.com Fri Jun 26 07:41:43 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B1AB73A6B8F for ; Fri, 26 Jun 2009 07:41:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8GBEhoPeQQD for ; Fri, 26 Jun 2009 07:41:42 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 550DE3A6B89 for ; Fri, 26 Jun 2009 07:41:42 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KLU00A0COTNFI@siemenscomms.co.uk> for bliss@ietf.org; Fri, 26 Jun 2009 15:41:47 +0100 (BST) Date: Fri, 26 Jun 2009 15:41:45 +0100 From: "Hutton, Andrew" In-reply-to: <1ECE0EB50388174790F9694F77522CCF1E8D43C8@zrc2hxm0.corp.nortel.com> To: bliss@ietf.org, alan@sipstation.com Message-id: <719F9BBB3E7E71428A2D13F3D76C768F01D5BB14@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: Expert Review requests on Shared Line Appearance Thread-Index: AcnecT9z79dZMZrFSQKQrc4rGyV1QAQS3A8wAeNkK0A= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1ECE0EB50388174790F9694F77522CCF1E2F8C9B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E8D43C8@zrc2hxm0.corp.nortel.com> Cc: "Khan, Sohel" , Shida Schubert Subject: [BLISS] Expert Review requests on Shared Line Appearance X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 14:41:43 -0000 Hi All, These are my review comments on draft-ietf-bliss-shared-appearances-02. Overall I think the draft covers most of the requirements but needs some editorial work to remove some of the unnecessary sections and text. I also think that it is necessary to explore some scenarios in more detail especially the glare conditions. For example in 10.7 (appearance pickup) what happens if the pickup fails and the already published state needs to be cancelled. It is the glare and recover scenarios that make this feature so hard to implement and the draft says very little about failure scenarios. The inclusion of the appearance number in the incoming INVITE (appendix A) is I believe a must have to make this work and should be a mandatory part of the main specification. My detailed comments are as follows. Section 1 3rd Para. "Different approaches will be discussed including the use of URI parameters....". Can we now remove the discussion on different approaches. 4th Para. "...gives this feature its" - Should this be "..its name" ? Section 3.1 "An assistant can make outgoing calls using the identity of either the executive or their own". This should be removed as making calls with the different identities is not part of this feature. Section 3.2. Replace "SIP Telephony devices" with "SIP UA's" for consistency with other sections. Possibly replace "Another phone can request to be added to an appearance resulting in a conference call" with "Another phone can request to be added joined or bridged in with the existing appearance". Again this is for consistency with section 3.3. Section 4.1. REQ-4 contains the statement "UAs registering against the group AOR should be able to learn about each other and join the appearance group". I don't think it is a requirement that the UA's "learn about each other". Section 4.2. 4th Para. Contains the statement "The next section discusses normal SIP operations used to implement parts of the shared appearance feature". This refers to the bulleted list below which appears to contain many statements that I would not include in "normal SIP operations" and should be part of the normative section. Bullet 4 contains the statement "UAs receive a notification from the Appearance Agent indicating the appearance number to use in rendering the incoming call". I think it is a must that the incoming INVITE contains the appearance number otherwise the UA cannot render the incoming call until it receives this leading to all kind of race and glare conditions. Bullet 7. What does the UA publish in this scenario? Section 5.2.1.=20 The statement "When sent in a notification in state Trying to the Appearance Agent" is incorrect because it is actually a publish which is used. Section 5.2.4 Replace "convey" with "to convey". Section 5.3. 1st Para. "defined in this draft". Please add a reference to the section that defines this. 3rd Para. "Upon initialization and at regular intervals, the UA SHOULD subscribe" should replace the statement about regular intervals with a reference to RFC 3265. 3rd Para. "or returns a 482 Loop Detected" why is this singled out is it just one of many possible failure cases. 4th Para. "User Agents MUST support sending an INVITE with a Join [RFC3911] header field to initiate bridging". Why is this a MUST strength requirement it should be optional for the UA to support bridging so a MAY would seem to be appropriate. 4th Para Note. "Note that the Join operation can be implemented outside the UA, for example, in a B2BUA. This is why UAs must support sending Join header fields even if they do not necessarily support receiving them". I think this can be removed and as previous comment I don't think this is a reason for mandating that a UA can initiate bridging. Section 7 (User Interface Considerations). I don't think we need this section the purpose of the draft is to promote interoperability between SA implementations. Those implementing this will be well aware of the UI considerations that may be different depending on their particular type of UA. Section 8.3. 1st Para. "This type of UA will be detected by the Appearance Agent by the absence of the ma event parameter in SUBSCRIBE or PUBLISH messages" I think the event type is "shared" not "ma" also if the UA does not support SA then I assume it will not PUBLISH to the appearance agent. Section 10.1.=20 I think the REGISTER from bob needs to be shown. Section 10.2 2nd Para. "then the Appearance Agent will need to resolve the situation by moving either Alice or Bob's dialog to a different appearance". This is one glare condition that I worry about what would happen if all other appearances are busy ?. The diagram seems to imply that the INVITE (F7/F8) is not sent to Bob until after the NOTIFY's have been sent but I don't think this is the case and it would therefore seem better to move the sending of the INVITE to before the NOTIFY (F2/F4).=20 Section 10.7.=20 The PUBLISH (F32) indicating the dialog to be replaced is sent before the INVITE/replaces (F38) is this the correct order and if so it introduces some glare conditions that we need to explain how to get out of. Section 10.9.=20 It is not explained how Bob indicates in the PUBLISH that he does not want an appearance number assigned. The NOTIFY (F32) contains the dialog identifiers for the dialog with alice but since the INVITE (F34) has not yet been generated it is likely that Bob's UA will not know this information so it cannot be included in the NOTIFY with state "trying". Section 12 Appendix A.=20 I think this should become part of the main specification and included in the normative section. Section 13 Appendix B. I think this should be removed to reduce the size of the document. Regards Andy From alan@sipstation.com Tue Jun 30 13:34:18 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 033FA3A6962 for ; Tue, 30 Jun 2009 13:34:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LRoSQJHnkFA0 for ; Tue, 30 Jun 2009 13:34:17 -0700 (PDT) Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 357613A6CDE for ; Tue, 30 Jun 2009 13:34:14 -0700 (PDT) Received: from 24-107-193-18.dhcp.stls.mo.charter.com ([24.107.193.18] helo=aidan-DS.sipserver.homeip.net) by mho-02-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MLk1d-000NIp-Ui; Tue, 30 Jun 2009 20:33:58 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.193.18 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX18imSesDXmBD3m5SW397wncWu+4u3b1020= Message-ID: <4A4A76B4.7040608@sipstation.com> Date: Tue, 30 Jun 2009 15:33:56 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Dale Worley References: <1244573679.4164.53.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: <1244573679.4164.53.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: BLISS Subject: Re: [BLISS] draft-ietf-bliss-shared-appearances-02.txt X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 20:34:18 -0000 Dale, I am fine making this change in the next version. Thanks, Alan Dale Worley wrote: > I'd like to ask that a sentence in > draft-ietf-bliss-shared-appearances-02 be changed because it is > ambiguous and easy to misinterpret. (A developer on the sipXecs project > already got caught by it.) It is buried in the example of section 10.4, > discussing how the Appearance Agent receives the statuses of appearances > and passes them on to subscribing UAs: > > The Appearance Agent notifies Alice of the same event by forwarding > the NOTIFY payload provided by Bob after appropriately changing the > dialog id field in the XML payload to a unique value towards each > of the entities it is forwarding to (Alice in this example). > > The problem with the sentence is that it can easily be read to suggest > that the NOTIFYs provided by the AA to each subscribing UA are > different, whereas the issue really being addressed is the fact that the > AA is "unioning" the dialog events provided by the UAs, and in so doing > has to make sure the id attributes of the elements are unique > within the resulting overall status. > > I would like to propose this revision: > > The Appearance Agent notifies Alice (and all other appearances) of > the same event by forwarding the NOTIFY payload provided by Bob. > Since the Appearance Agent is combining Bob's dialog status with > statuses provided by other appearances, it may have to change the > dialog id attributes in the XML to prevent values from being > duplicated by different appearances. > > Dale > > > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss > > From alan@sipstation.com Tue Jun 30 14:26:44 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DAFA828C399 for ; Tue, 30 Jun 2009 14:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DhO17vf6AdPc for ; Tue, 30 Jun 2009 14:26:43 -0700 (PDT) Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by core3.amsl.com (Postfix) with ESMTP id 2EF473A67AE for ; Tue, 30 Jun 2009 14:26:43 -0700 (PDT) Received: from 24-107-193-18.dhcp.stls.mo.charter.com ([24.107.193.18] helo=aidan-DS.sipserver.homeip.net) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1MLkr1-000HKK-Kw; Tue, 30 Jun 2009 21:27:04 +0000 X-Mail-Handler: MailHop Outbound by DynDNS X-Originating-IP: 24.107.193.18 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX1+z4IaiSHsdmqttX3yUw3k2Xj10Pow6OuM= Message-ID: <4A4A8324.8000902@sipstation.com> Date: Tue, 30 Jun 2009 16:27:00 -0500 From: Alan Johnston User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "Hutton, Andrew" References: <1ECE0EB50388174790F9694F77522CCF1E2F8C9B@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1E8D43C8@zrc2hxm0.corp.nortel.com> <719F9BBB3E7E71428A2D13F3D76C768F01D5BB14@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <719F9BBB3E7E71428A2D13F3D76C768F01D5BB14@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bliss@ietf.org Subject: Re: [BLISS] Expert Review requests on Shared Line Appearance X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2009 21:26:44 -0000 Andy, Thanks for this detailed review. See my comments below. I also have a few questions for the chairs, which are summarized here: 1. How to proceed with Appendix A which defines a new Alert-Info header field parameter? 2. Should we remove Appendix B on alternative approaches? Thanks, Alan Hutton, Andrew wrote: > Hi All, > > These are my review comments on draft-ietf-bliss-shared-appearances-02. > > Overall I think the draft covers most of the requirements but needs some > editorial work to remove some of the unnecessary sections and text. I > also think that it is necessary to explore some scenarios in more detail > especially the glare conditions. For example in 10.7 (appearance pickup) > what happens if the pickup fails and the already published state needs > to be cancelled. If the INVITE with Replaces fails (presumably because the dialog has gone away or been marked exclusive), then the UQ will need to PUBLISH again this failure. I agree a call flow showing this would be useful. This would apply equally well to the INVITE Join case as well. > It is the glare and recover scenarios that make this > feature so hard to implement and the draft says very little about > failure scenarios. > Yes, we need to include more failure and race conditions in the call flows. Your INVITE Replaces suggestion will be included - other suggestions? > The inclusion of the appearance number in the incoming INVITE (appendix > A) is I believe a must have to make this work and should be a mandatory > part of the main specification. > I agree it is also very important. I'd like to hear from the chairs how we should proceed on this - I doubt that BLISS is chartered to do a SIP extension such as a header field parameter. Will we need to discuss this in DISPATCH? If so, it would be good to get started on this now. > My detailed comments are as follows. > > > Section 1 > > 3rd Para. > "Different approaches will be discussed including the use of URI > parameters....". Can we now remove the discussion on different > approaches. > This text is currently in Appendix B of the document. I agree it is not critical to an implementor, however, it is the kind of thing that BLISS is chartered to do. I'd like to hear the opinions of the chairs and others on this. I'm fine with either including or removing Appendix B. > 4th Para. > "...gives this feature its" - Should this be "..its name" ? > > Yes. > Section 3.1 > "An assistant can make outgoing calls using the identity of either the > executive or their own". This should be removed as making calls with > the different identities is not part of this feature. > Agreed. > Section 3.2. > > Replace "SIP Telephony devices" with "SIP UA's" for consistency with > other sections. > Agreed. > Possibly replace "Another phone can request to be added to an appearance > resulting in a conference call" with "Another phone can request to be > added joined or bridged in with the existing appearance". Again this is > for consistency with section 3.3. > Yes. > Section 4.1. > > REQ-4 contains the statement "UAs registering against the group AOR > should be able to learn about each other and join the appearance group". > I don't think it is a requirement that the UA's "learn about each > other". > We were trying to say that UAs should not have to be configured with information about other UAs in the group - I'll restate this requirement. > Section 4.2. > > 4th Para. Contains the statement "The next section discusses normal SIP > operations used to implement parts of the shared appearance feature". > This refers to the bulleted list below which appears to contain many > statements that I would not include in "normal SIP operations" and > should be part of the normative section. > You are correct that this should not be described as "normal SIP operations", so I'll get rid of that. The steps in this list are already repeated in normative language starting in Section 5.3. > Bullet 4 contains the statement "UAs receive a notification from the > Appearance Agent indicating the appearance number to use in rendering > the incoming call". I think it is a must that the incoming INVITE > contains the appearance number otherwise the UA cannot render the > incoming call until it receives this leading to all kind of race and > glare conditions. > This bullet should also mention the Alert-Info parameter as well. If we make it mandatory, we will need to address which one has precedence over the other, i.e. if Alert-Info says appearance 1 while the NOTIFY for the same early dialog says appearance 2. I'd vote for the NOTIFY having precedence. > Bullet 7. What does the UA publish in this scenario? > It is described in Section 5.3: A UA wanting to place a call but not have an appearance number assigned publishes before sending the INVITE without an 'appearance' element but with the 'shared' event package parameter present. Perhaps a forward reference to this section would make this clearer. > Section 5.2.1. > > The statement "When sent in a notification in state Trying to the > Appearance Agent" is incorrect because it is actually a publish which is > used. > You are correct. > Section 5.2.4 > > Replace "convey" with "to convey". > Right. > Section 5.3. > > 1st Para. "defined in this draft". Please add a reference to the section > that defines this. > I will reference Section 11.1. > 3rd Para. "Upon initialization and at regular intervals, the UA SHOULD > subscribe" should replace the statement about regular intervals with a > reference to RFC 3265. > How about: Upon initialization, the UA SHOULD subscribe to the dialog event package of the AOR and refresh the subscription per RFC 3265. > 3rd Para. "or returns a 482 Loop Detected" why is this singled out is it > just one of many possible failure cases. > I thought it was a likely error case. We don't want an implementation that gets an error at this stage to give up on the entire shared appearances feature. > 4th Para. "User Agents MUST support sending an INVITE with a Join > [RFC3911] header field to initiate bridging". Why is this a MUST > strength requirement it should be optional for the UA to support > bridging so a MAY would seem to be appropriate. > I'm worried that if we made it less than a MUST, implementors will just skip it and the resulting feature will be very weak. I think that only UAs that do line appearance monitoring don't need to support Join. > 4th Para Note. "Note that the Join operation can be implemented outside > the UA, for example, in a B2BUA. This is why UAs must support sending > Join header fields even if they do not necessarily support receiving > them". I think this can be removed and as previous comment I don't think > this is a reason for mandating that a UA can initiate bridging. > This is badly worded. What is meant is that a UA can request to be joined to another call even though it is not necessarily capable of doing the mixing if another UA requests it. Handling this kind of asymmetric feature is something we've done very very badly in SIP, I'm afraid. I'll try to reword this text. > Section 7 (User Interface Considerations). I don't think we need this > section the purpose of the draft is to promote interoperability between > SA implementations. Those implementing this will be well aware of the UI > considerations that may be different depending on their particular type > of UA. > I think this section is useful. Perhaps it would tie in better if we had introduced these phones in Section 3.1. What do others think about this section? > Section 8.3. > > 1st Para. "This type of UA will be detected by the Appearance Agent by > the absence of the ma event parameter in SUBSCRIBE or PUBLISH messages" > I think the event type is "shared" not "ma" also if the UA does not > support SA then I assume it will not PUBLISH to the appearance agent. > > Yes, ma is from an older draft. A non SA UA would not likely PUBLISH but it may still SUBSCRIBE. > Section 10.1. > > I think the REGISTER from bob needs to be shown. > OK. > Section 10.2 > > 2nd Para. "then the Appearance Agent will need to resolve the situation > by moving either Alice or Bob's dialog to a different appearance". This > is one glare condition that I worry about what would happen if all other > appearances are busy ?. > Hmm. This would imply an upper limit to the number of appearances in the group. We once had a requirement and scenarios for this but they were removed as people thought they didn't fit the feature. Of course, a hard phone with lamps and buttons might run out of button and lamp positions, but this should be addressed in Section 7. > The diagram seems to imply that the INVITE (F7/F8) is not sent to Bob > until after the NOTIFY's have been sent but I don't think this is the > case and it would therefore seem better to move the sending of the > INVITE to before the NOTIFY (F2/F4). Why? The INVITE can not be forwarded with the appearance number until the appearance agent knows about it and processes it. In processing the appearance number allocation, I would expect it to immediately send NOTIFYs - for it to delay would not give a good user experience for this feature. As such, I prefer showing the NOTIFYs arrriving first. They are effectively happening in parallel, although we have no way of showing that on the figure. Some text perhaps could explain this. > > > Section 10.7. > > The PUBLISH (F32) indicating the dialog to be replaced is sent before > the INVITE/replaces (F38) is this the correct order and if so it > introduces some glare conditions that we need to explain how to get out > of. > Yes, this order is critical, otherwise the Appearance Agent will probably reject the INVITE. I agree we should show the case where the PUBLISH succeeds but the INVITE Replace or Join fails. > Section 10.9. > > It is not explained how Bob indicates in the PUBLISH that he does not > want an appearance number assigned. > How about adding this: He indicates this in his PUBLISH F32 by the inclusion of the 'shared' event parameter with no element. This PUBLISH is sent before the INVITE to Alice to ensure no appearance number is assigned by the Appearance Agent. > The NOTIFY (F32) contains the dialog identifiers for the dialog with > alice but since the INVITE (F34) has not yet been generated it is likely > that Bob's UA will not know this information so it cannot be included in > the NOTIFY with state "trying". > This is the same thing we are doing in 10.4 and other places in this specification. If any dialog information is available, it should be included in the publish. This is described in Section 5.3: Note that when a UA selects an appearance prior to establishment of a dialog (#1 and #2 in above list), not all dialog information will be available. In particular, when a UA publishes an attempt to select an appearance prior to knowing the destination URI, minimal or no dialog information may be available. For example, in some cases, only the local target URI for the call will be known and no dialog information. If no dialog identification information is present in the initial PUBLISH, the UA MUST PUBLISH again after receiving the 100 Trying response. > Section 12 Appendix A. > > I think this should become part of the main specification and included > in the normative section. > Unless I am mistaken, I don't think that the BLISS WG can do this work, so we will likely have to spin this off into a separate document and reference it normatively in this document. > Section 13 Appendix B. > > I think this should be removed to reduce the size of the document. > > I am sympathetic to reducing the size. > Regards > Andy > > > > >