From michael@voip.co.uk Fri May 1 04:40:09 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 535EE3A6CA6 for ; Fri, 1 May 2009 04:40:09 -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 O2Q173CYhBJv for ; Fri, 1 May 2009 04:40:08 -0700 (PDT) Received: from na3sys009aog108.obsmtp.com (na3sys009aog108.obsmtp.com [74.125.149.199]) by core3.amsl.com (Postfix) with SMTP id 459F53A6AA7 for ; Fri, 1 May 2009 04:40:07 -0700 (PDT) Received: from source ([209.85.128.188]) by na3sys009aob108.postini.com ([74.125.148.12]) with SMTP ID DSNKSfrf64+nr+6kUC0uhTr+K2qe4WOdWWbF@postini.com; Fri, 01 May 2009 04:41:32 PDT Received: by fk-out-0910.google.com with SMTP id z22so994519fkz.2 for ; Fri, 01 May 2009 04:41:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.172.7 with SMTP id z7mr1623734muo.15.1241178090585; Fri, 01 May 2009 04:41:30 -0700 (PDT) In-Reply-To: <1241127003.19498.104.camel@victoria-pingtel-com.us.nortel.com> References: <1241127003.19498.104.camel@victoria-pingtel-com.us.nortel.com> Date: Fri, 1 May 2009 12:41:30 +0100 Message-ID: From: Michael Procter To: Dale Worley Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: bliss@ietf.org, Scott Orton Subject: Re: [BLISS] Comments on draft-procter-bliss-call-park-extension-04 (Privacy Interactions) 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, 01 May 2009 11:40:09 -0000 Hi, 2009/4/30 Dale Worley : > If you want to use anything approaching "endpoint call control", that > is, anything more complex than an in-dialog REFER, then the anonymized > Contact has to route to Alice, or rather, the privacy service fronting > for Alice. =A0So it would have to be similar to a "temporary GRUU" (see > draft-ietf-sip-gruu-15), a URI which is secretly mapped to a unique > target but for only a limited time. > As Dale notes, this isn't a call-park specific problem, but a more generic call control problem. And he also notes that Alice should implement temporary GRUUs or some similar feature. These sorts of issues are discussed more fully in draft-ietf-sip-ua-privacy-09, and a UA hoping to achieve private operations should consider the mechanisms discussed in there to achieve it. Michael From michael@voip.co.uk Fri May 1 04:42:30 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 067BB3A6802 for ; Fri, 1 May 2009 04:42:30 -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 aVF7GbwGzWVi for ; Fri, 1 May 2009 04:42:29 -0700 (PDT) Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) by core3.amsl.com (Postfix) with SMTP id DC64F3A6926 for ; Fri, 1 May 2009 04:42:28 -0700 (PDT) Received: from source ([209.85.134.184]) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKSfrgeENxaqfIJkz3VEMf4F4iLgZ0Zq3J@postini.com; Fri, 01 May 2009 04:43:53 PDT Received: by mu-out-0910.google.com with SMTP id g7so786804muf.2 for ; Fri, 01 May 2009 04:43:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.102.228.10 with SMTP id a10mr1588559muh.26.1241178231726; Fri, 01 May 2009 04:43:51 -0700 (PDT) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1DC32AC4@zrc2hxm0.corp.nortel.com> References: <1241127003.19498.104.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1DC32AC4@zrc2hxm0.corp.nortel.com> Date: Fri, 1 May 2009 12:43:51 +0100 Message-ID: From: Michael Procter To: Francois Audet Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: bliss@ietf.org, Scott Orton Subject: Re: [BLISS] Comments on draft-procter-bliss-call-park-extension-04(Privacy Interactions) 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, 01 May 2009 11:42:30 -0000 2009/4/30 Francois Audet : > Why do we send the REFER to the Park server (to replace the call to the other user), > as opposed to sending the REFER to the other user to direct him/her to the Park > server? Section 2 of my draft discusses this. Here is an extract: By following the Call Park model, we ensure that Bob has visibility over the success or failure of the park attempt. We also ensure that Bob does not rely on Alice to correctly pass the orbit parameter back from the Park Server for the centrally-allocated orbit number situation. Finally, because Bob sends the REFER to the Park Server, we give the Park Server the opportunity to challenge Bob and ensure that appropriate authorisation exists for the feature. Michael From shida@ntt-at.com Mon May 4 00:17:59 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 90DF828C0F4 for ; Mon, 4 May 2009 00:17:59 -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 w0TsqM+8Qcpl for ; Mon, 4 May 2009 00:17:52 -0700 (PDT) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [69.93.239.22]) by core3.amsl.com (Postfix) with SMTP id A2B8C28C14A for ; Mon, 4 May 2009 00:17:03 -0700 (PDT) Received: (qmail 24957 invoked from network); 4 May 2009 07:21:07 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway03.websitewelcome.com with SMTP; 4 May 2009 07:21:07 -0000 Received: from p4143-ipad409marunouchi.tokyo.ocn.ne.jp ([222.146.172.143]:51175 helo=[192.168.11.11]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1M0sRT-0004i6-Nn; Mon, 04 May 2009 02:18:24 -0500 Message-Id: <2407672E-59F5-4DCC-9F57-6F197B264747@ntt-at.com> From: Shida Schubert To: "Elwell, John" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001D4AED1@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 4 May 2009 16:18:22 +0900 References: <1ECE0EB50388174790F9694F77522CCF1DA436E8@zrc2hxm0.corp.nortel.com> <719F9BBB3E7E71428A2D13F3D76C768F01A1EF33@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1DAA2BE6@zrc2hxm0.corp.nortel.com> <719F9BBB3E7E71428A2D13F3D76C768F01A1F19E@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1DAFDC77@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D001D4AED1@GBNTHT12009MSX.gb002.siemens.net> X-Mailer: Apple Mail (2.930.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 - ntt-at.com Cc: bliss@ietf.org, Scott Orton Subject: Re: [BLISS] Comments ondraft-procter-bliss-call-park-extension-04(AutoRetrieve proposal) 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, 04 May 2009 07:17:59 -0000 Unless the feature is broken to start with without whatever it is people are claiming is necessary, I would like people to keep the spec simple so we are more likely to see the spec's adaptation. .. Focus on basic level of interoperability.. Though that's not to say that we should withhold ourselves from adding text describing why the feature currently deployed out there may be unsafe with some description of what implementers can do to make it more secure.. Regards Shida On 29-Apr-09, at 10:22 PM, Elwell, John wrote: > I agree - I would like something to be said about it. > > John > >> -----Original Message----- >> From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] >> On Behalf Of Francois Audet >> Sent: 28 April 2009 16:13 >> To: Michael Procter; Hutton, Andrew >> Cc: bliss@ietf.org; Scott Orton >> Subject: Re: [BLISS] Comments >> ondraft-procter-bliss-call-park-extension-04(AutoRetrieve proposal) >> >> Basically, I think a CallPark without an autoretrieve is >> effectively an "unsafe" feature, since it will result in >> users (typically customers) to wait forever in the >> parking space. >> >>> -----Original Message----- >>> From: Michael Procter [mailto:michael@voip.co.uk] >>> Sent: Tuesday, April 28, 2009 02:00 >>> To: Hutton, Andrew >>> Cc: Audet, Francois (SC100:3055); bliss@ietf.org; Orton, >>> Scott (RICH1:B620) >>> Subject: Re: [BLISS] Comments on >>> draft-procter-bliss-call-park-extension-04(AutoRetrieve proposal) >>> >>> 2009/4/28 Hutton, Andrew : >>>> >>>> I agree with Francois it would I assume be the Referred-by >>> header that >>>> contains the URI of the park server and as long as the UA >> can match >>>> this against it's local configuration then this will be ok. >>> >>> That would probably be more straightforward. But it assumes >>> a particular way of achieving the feature. >>> >>>> I do think we should have a short description of the >> auto-retrieve >>>> procedure including an example message flow in the draft. >>> >>> I'm still not entirely convinced that it belongs in this >>> draft, although I agree it is an important aspect to consider >>> in an implementation. I'm also not sure that it is within >>> scope for BLISS, given that it does seem to be trying to >>> standardise a feature over and above the level needed for >>> 'basic interoperability'. >>> >>> However, I am open to persuasion! To that end, I'd >>> appreciate contributions of text / message flows. >>> >>> Michael >>> >> _______________________________________________ >> BLISS mailing list >> BLISS@ietf.org >> https://www.ietf.org/mailman/listinfo/bliss >> > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss From ORTON@nortel.com Tue May 5 06:40:09 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 51BCE3A68BF for ; Tue, 5 May 2009 06:40:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 R2cSQlFqAYVL for ; Tue, 5 May 2009 06:40:08 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 334DD3A68B2 for ; Tue, 5 May 2009 06:40:08 -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 n45DeW613629; Tue, 5 May 2009 13:40:32 GMT 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: Tue, 5 May 2009 08:40:49 -0500 Message-ID: In-Reply-To: <1241127003.19498.104.camel@victoria-pingtel-com.us.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Comments on draft-procter-bliss-call-park-extension-04(Privacy Interactions) Thread-Index: AcnJ2tQLZDo5mcqCSq2yhKx7C3mmQgDql/pw References: <1241127003.19498.104.camel@victoria-pingtel-com.us.nortel.com> From: "Scott Orton" To: "Dale Worley" Cc: bliss@ietf.org Subject: Re: [BLISS] Comments on draft-procter-bliss-call-park-extension-04(Privacy Interactions) 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, 05 May 2009 13:40:09 -0000 Dale, I agree that if we use the temporary GRUU it will work. But my concern is that we are now adding another requirement to the draft. If a UA is requesting privacy either from its Proxy or by itself then they have to also support draft-ietf-sip-gruu. Where making a simple change to parking the call will work for all scenarios without causing another draft to be implemented. If the Refer is sent to the party being parked there is no need for a special contact. But both can be handled without a change to a client. In addition the client does not even have to know that it is being parked.=20 Sending the Refer to the client means that any client that supports Refer can support being parked. I think we are adding complications by requiring that a client support the draft-ietf-sip-gruu draft in order to be parked. To me Parking a call should require no development on the client being parked since we do not want the functionality of the call park to be dependant on the party being parked. As I do not necessarily control the client being parked, I have no way of enforcing what that client implements. If a user from the Yahoo domain calls a user in the Example domain. The user in the Example domain needs to be able to park a call from the user in the Yahoo domain. But I as a user in the example domain will have no control over the clients in the Yahoo domain.=20 I really think it will be a mistake to try to enforce another draft as a requirement to park a call. If the parking user subscribes to the dialog event for calls that it parks then the park server could deliver the orbit to the parking party.=20 In this way there is no need for the parked client to support any particular draft except for Refer.=20 Scott =20 -----Original Message----- From: Worley, Dale (BL60:9D30)=20 Sent: Thursday, April 30, 2009 4:30 PM To: Orton, Scott (RICH1:B620) Cc: Michael Procter; Audet, Francois (SC100:3055); bliss@ietf.org Subject: Re: Comments on draft-procter-bliss-call-park-extension-04(Privacy Interactions) On Tue, 2009-04-28 at 17:22 -0400, Orton, Scott (RICH1:B620) wrote: > Lets take for example a case where Alice calls bob. Alice is using=20 > privacy as defined in RFC 3325. In this case the from header and the=20 > contact for Alice will anonymous. The contact is likely just an IP=20 > address and the from header will be sip:anonymous@anonymous.invalid. > The contact header being an IP address is enough to exchange messages=20 > in a dialog but is unlikely to be enough to route a new call to the=20 > Alice. If it was enough then you privacy is not very good as nothing=20 > is preventing the user from returning a private call. If you want to use anything approaching "endpoint call control", that is, anything more complex than an in-dialog REFER, then the anonymized Contact has to route to Alice, or rather, the privacy service fronting for Alice. So it would have to be similar to a "temporary GRUU" (see draft-ietf-sip-gruu-15), a URI which is secretly mapped to a unique target but for only a limited time. But assuming that the privacy service can provide such Contacts, I think the proposed parking method (out-of-dialog REFER sent to the Park Server so that it sends INVITE-with-Replace to the caller) should work. Dale From ORTON@nortel.com Tue May 5 06:51:40 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 957263A706D for ; Tue, 5 May 2009 06:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.492 X-Spam-Level: X-Spam-Status: No, score=-6.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 UUCxO+b5LktB for ; Tue, 5 May 2009 06:51:39 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id CA42F3A6EAB for ; Tue, 5 May 2009 06:51:33 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n45Dqrm21275; Tue, 5 May 2009 13:52:53 GMT 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: Tue, 5 May 2009 08:50:23 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Comments ondraft-procter-bliss-call-park-extension-04(Privacy Interactions) Thread-Index: AcnKUiQqvC4sZ6y6Tve/RcGEb1V91ADNctnQ References: <1241127003.19498.104.camel@victoria-pingtel-com.us.nortel.com><1ECE0EB50388174790F9694F77522CCF1DC32AC4@zrc2hxm0.corp.nortel.com> From: "Scott Orton" To: "Michael Procter" , "Francois Audet" Cc: bliss@ietf.org Subject: Re: [BLISS] Comments ondraft-procter-bliss-call-park-extension-04(Privacy Interactions) 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, 05 May 2009 13:51:40 -0000 Michael, Can this also be addressed by subscribing to the dialog event? We might want to specify in a subscription to the dialog event that we want to be informed of any call parked by the subscribing user. This is a change from the current draft and would require a new uri parm in the Subscription. This way we can send the refer to the party being parked instead of using the unsolicited refer.=20 Scott -----Original Message----- From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] On Behalf Of Michael Procter Sent: Friday, May 01, 2009 6:44 AM To: Audet, Francois (SC100:3055) Cc: bliss@ietf.org; Orton, Scott (RICH1:B620) Subject: Re: [BLISS] Comments ondraft-procter-bliss-call-park-extension-04(Privacy Interactions) 2009/4/30 Francois Audet : > Why do we send the REFER to the Park server (to replace the call to=20 > the other user), as opposed to sending the REFER to the other user to=20 > direct him/her to the Park server? Section 2 of my draft discusses this. Here is an extract: By following the Call Park model, we ensure that Bob has visibility over the success or failure of the park attempt. We also ensure that Bob does not rely on Alice to correctly pass the orbit parameter back from the Park Server for the centrally-allocated orbit number situation. Finally, because Bob sends the REFER to the Park Server, we give the Park Server the opportunity to challenge Bob and ensure that appropriate authorisation exists for the feature. Michael _______________________________________________ BLISS mailing list BLISS@ietf.org https://www.ietf.org/mailman/listinfo/bliss From dworley@nortel.com Wed May 13 15:00:19 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 15ED83A6DA2 for ; Wed, 13 May 2009 15:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.514 X-Spam-Level: X-Spam-Status: No, score=-6.514 tagged_above=-999 required=5 tests=[AWL=0.085, 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 KW+qpAs6Oayp for ; Wed, 13 May 2009 15:00:18 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 2098F3A6D4B for ; Wed, 13 May 2009 15:00:17 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n4DM1hP06443; Wed, 13 May 2009 22:01:43 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 May 2009 18:01:28 -0400 From: "Dale Worley" To: "Scott Orton" In-Reply-To: References: <1241127003.19498.104.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1DC32AC4@zrc2hxm0.corp.nortel.com> Content-Type: text/plain Organization: Nortel Networks Date: Wed, 13 May 2009 18:01:27 -0400 Message-Id: <1242252087.26396.12.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: 13 May 2009 22:01:28.0349 (UTC) FILETIME=[5DB82CD0:01C9D416] Cc: bliss@ietf.org Subject: Re: [BLISS] Comments ondraft-procter-bliss-call-park-extension-04(Privacy Interactions) 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, 13 May 2009 22:00:19 -0000 On Tue, 2009-05-05 at 08:50 -0500, Scott Orton wrote: > Can this also be addressed by subscribing to the dialog event? We > might want to specify in a subscription to the dialog event that we want > to be informed of any call parked by the subscribing user. This is a > change from the current draft and would require a new uri parm in the > Subscription. This way we can send the refer to the party being parked > instead of using the unsolicited refer. That would require extending the dialog event specification, and require the executing phone and the park server to support that extension. It would also not quite work, since there might be two calls from the same subscriber being parked on the same park server at the same time. A better approach would be for the calling phone to send, in its NOTIFYs for the REFER-created subscription, not just the status lines but also the To, From, and Call-Id headers. Then the executing phone would know the dialog identifiers of the parked call dialog. Dale From dworley@nortel.com Wed May 13 15:03:12 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 682373A6ADD for ; Wed, 13 May 2009 15:03:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.516 X-Spam-Level: X-Spam-Status: No, score=-6.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 ZReQMf1KLu4p for ; Wed, 13 May 2009 15:03:11 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 68A0328C21B for ; Wed, 13 May 2009 15:02:02 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n4DM3SP06781; Wed, 13 May 2009 22:03:28 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 13 May 2009 18:03:26 -0400 From: "Dale Worley" To: "Scott Orton" In-Reply-To: References: <1241127003.19498.104.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain Organization: Nortel Networks Date: Wed, 13 May 2009 18:03:25 -0400 Message-Id: <1242252205.26396.14.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: 13 May 2009 22:03:26.0491 (UTC) FILETIME=[A42336B0:01C9D416] Cc: bliss@ietf.org Subject: Re: [BLISS] Comments on draft-procter-bliss-call-park-extension-04(Privacy Interactions) 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, 13 May 2009 22:03:12 -0000 On Tue, 2009-05-05 at 09:40 -0400, Orton, Scott (RICH1:B620) wrote: > I agree that if we use the temporary GRUU it will work. But my > concern is that we are now adding another requirement to the draft. If a > UA is requesting privacy either from its Proxy or by itself then they > have to also support draft-ietf-sip-gruu. Where making a simple change > to parking the call will work for all scenarios without causing another > draft to be implemented. In the sipX project, which is a non-centralized PBX system, our experience is that having proper Contact addresses is mandatory for most sophisticated call-control activities. The project hasn't addressed sophisticated privacy questions at all. So we are already expecting that all UAs will support "public GRUUs", and from that point of view, we don't see it as burdensome to expect that a UA that supports proper privacy (and the proxy that fronts for it) also supports "temporary GRUUs". We expect that to be the least of the tasks needed to support proper privacy. The benefit of the current draft's signaling flow is that it allows an extremely clever way of having a park server that assigns park orbits to transmit the orbit identifier to the executing UA. Dale From michael@voip.co.uk Wed May 13 23:11:46 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 8BE6028C204 for ; Wed, 13 May 2009 23:11:46 -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 fK10Z4e9idHA for ; Wed, 13 May 2009 23:11:45 -0700 (PDT) Received: from na3sys009aog111.obsmtp.com (na3sys009aog111.obsmtp.com [74.125.149.205]) by core3.amsl.com (Postfix) with SMTP id D1BCB3A6A95 for ; Wed, 13 May 2009 23:10:59 -0700 (PDT) Received: from source ([209.85.128.189]) by na3sys009aob111.postini.com ([74.125.148.12]) with SMTP ID DSNKSgu2UP45GdhFNDqmu+LG9vJExVAgPfHB@postini.com; Wed, 13 May 2009 23:12:33 PDT Received: by fk-out-0910.google.com with SMTP id z22so493773fkz.2 for ; Wed, 13 May 2009 23:12:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.238.4 with SMTP id p4mr1306640mur.68.1242281551773; Wed, 13 May 2009 23:12:31 -0700 (PDT) In-Reply-To: References: <1241127003.19498.104.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1DC32AC4@zrc2hxm0.corp.nortel.com> Date: Thu, 14 May 2009 07:12:31 +0100 Message-ID: From: Michael Procter To: Scott Orton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: bliss@ietf.org Subject: Re: [BLISS] Comments ondraft-procter-bliss-call-park-extension-04(Privacy Interactions) 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: Thu, 14 May 2009 06:11:46 -0000 Scott, Apologies for the delay. 2009/5/5 Scott Orton : > =A0Michael, > =A0 Can this also be addressed by subscribing to the dialog event? We > might want to specify in a subscription to the dialog event that we want > to be informed of any call parked by the subscribing user. This is a > change from the current draft and would require a new uri parm in the > Subscription. This way we can send the refer to the party being parked > instead of using the unsolicited refer. > > Scott As Dale has just pointed out, it won't work without extensions to the dialog event package and/or changes to the parked UA. Since all this is to work around a parked UA that doesn't provide a usable contact, it seems that putting more requirements on it is unlikely to make the problem better! On balance, I think we are better off staying with the approach in the draft. I will be updating the draft shortly, in light of the comments raised (I am waiting for one last set of comments offlist). Regards, Michael From ORTON@nortel.com Thu May 14 09:12:33 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 596E728C10B for ; Thu, 14 May 2009 09:12:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.506 X-Spam-Level: X-Spam-Status: No, score=-6.506 tagged_above=-999 required=5 tests=[AWL=0.093, 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 Uav9obIFD36A for ; Thu, 14 May 2009 09:12:32 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 41CAA3A681E for ; Thu, 14 May 2009 09:12:32 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n4EGDuo15942; Thu, 14 May 2009 16:13:56 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: Thu, 14 May 2009 11:13:37 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Comments ondraft-procter-bliss-call-park-extension-04(Privacy Interactions) Thread-Index: AcnUWvrDIYgPUpAuQvaCHcYS7obgRAATVtVg References: <1241127003.19498.104.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1DC32AC4@zrc2hxm0.corp.nortel.com> From: "Scott Orton" To: "Michael Procter" Cc: bliss@ietf.org Subject: Re: [BLISS] Comments ondraft-procter-bliss-call-park-extension-04(Privacy Interactions) 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: Thu, 14 May 2009 16:12:33 -0000 Michael, I think we are making a mistake in relying on the temporary GRUU = draft to handle privacy. There are way too many clients and Gateways = already in the field that will not be following this draft. I think this = is going to cause issues in deployments where there are older clients = already in the field as we will not be able to park these existing = deployments if they have privacy enabled.=20 If the major concern is the concern is making extensions to the Dialog = event package then maybe the solution is to create a Callpark event = package.=20 I realize that I seem to hold the minority opinion on interacting with = clients and privacy, so at a minimum can we add a section on the issues = with private clients and routing and the recommendation that all clients = in the network have to support draft-ietf-sip-gruu-15 or there will be = park failures. I can write up the issues if that would help.=20 Scott -----Original Message----- From: Michael Procter [mailto:michael@voip.co.uk]=20 Sent: Thursday, May 14, 2009 1:13 AM To: Orton, Scott (RICH1:B620) Cc: Audet, Francois (SC100:3055); bliss@ietf.org Subject: Re: [BLISS] Comments = ondraft-procter-bliss-call-park-extension-04(Privacy Interactions) Scott, Apologies for the delay. 2009/5/5 Scott Orton : > =A0Michael, > =A0 Can this also be addressed by subscribing to the dialog event? We=20 > might want to specify in a subscription to the dialog event that we=20 > want to be informed of any call parked by the subscribing user. This=20 > is a change from the current draft and would require a new uri parm in = > the Subscription. This way we can send the refer to the party being=20 > parked instead of using the unsolicited refer. > > Scott As Dale has just pointed out, it won't work without extensions to the = dialog event package and/or changes to the parked UA. Since all this is = to work around a parked UA that doesn't provide a usable contact, it = seems that putting more requirements on it is unlikely to make the = problem better! On balance, I think we are better off staying with the approach in the = draft. I will be updating the draft shortly, in light of the comments = raised (I am waiting for one last set of comments offlist). Regards, Michael From michael@voip.co.uk Fri May 15 00:34:42 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 AF2443A703E for ; Fri, 15 May 2009 00:34:42 -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=[AWL=0.000, 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 MMAGdrle4bhM for ; Fri, 15 May 2009 00:34:41 -0700 (PDT) Received: from na3sys009aog109.obsmtp.com (na3sys009aog109.obsmtp.com [74.125.149.201]) by core3.amsl.com (Postfix) with SMTP id 5918F3A6C99 for ; Fri, 15 May 2009 00:34:41 -0700 (PDT) Received: from source ([209.85.218.208]) by na3sys009aob109.postini.com ([74.125.148.12]) with SMTP ID DSNKSg0bbt3ULe9A2YhYSt/59GoTspq7JReF@postini.com; Fri, 15 May 2009 00:36:15 PDT Received: by mail-bw0-f208.google.com with SMTP id 4so2083241bwz.18 for ; Fri, 15 May 2009 00:36:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.171.20 with SMTP id y20mr2096443muo.104.1242372974344; Fri, 15 May 2009 00:36:14 -0700 (PDT) In-Reply-To: References: <1241127003.19498.104.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1DC32AC4@zrc2hxm0.corp.nortel.com> Date: Fri, 15 May 2009 08:36:14 +0100 Message-ID: From: Michael Procter To: Scott Orton Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: bliss@ietf.org Subject: Re: [BLISS] Comments ondraft-procter-bliss-call-park-extension-04(Privacy Interactions) 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, 15 May 2009 07:34:42 -0000 Scott, I think we may be getting hung up on the 'must support GRUU' part. Let's quickly review the scenario that is causing problems. Alice calls Bob, and Bob tries to park the call at the park server. The problem occurs when Alice provides a Contact URI that is not usable outside the context of the dialog to Bob. This may occur for a number of reasons, including Alice's UA being broken and Alice's UA attempting to remain private. As others have pointed out, this behaviour will cause problems with a number of features, and not just call park. My response, which appears to have been echoed by others on this list, is that a UA attempting to remain private should consider draft-ietf-sip-ua-privacy. This gives guidance on how to achieve a degree of privacy whilst still providing a usable contact, using temp-gruus. This is the 'correct' approach within the context of a 'normal' SIP trapezoid configuration. Not all deployments are like this of course! Many deployments use B2BUAs, in various guises (e.g. App Servers and SBCs). One function that they often perform is to ensure that external traffic does not contain any local IP addresses, by removing, obscuring or changing any occurrences into global IP addresses, typically pointing to themselves. In this way, contact URIs are 'corrected' so that they are globally routable, and so will work in our particular scenario. Ultimately, we need to assume a certain base level of functionality in Alice's UA. I want to assume a valid contact URI, and the ability to handle INVITE/replaces. You indicate you would prefer to assume in-dialog REFER handling, and the ability to round-trip extra information in the corresponding NOTIFYs (specifically the park server's contact, which will contain the orbit). In passing, I note that under your approach, the Park Server must be reachable by external callers, and that the orbit needs to be protected/encrypted to prevent some entertaining 'social engineering' attacks. These are not unresolvable issues, but would need to be addressed. It is my belief that the the requirements on Alice that the draft assumes are more easily achieved, and are in fact already achieved in many situations. In particular, no additional requirements are needed over and above those for (for example) directed pickup. It is also my belief that the requirements of your approach are not currently met anywhere (because we haven't defined what we need to round-trip the orbit securely), and are also specific to call park. Therefore, I suspect that there would be slower take-up of such an approach, which will lead to poorer interoperability. If I have mis-represented your thoughts in the above, please correct me. Best regards, Michael 2009/5/14 Scott Orton : > Michael, > =A0 I think we are making a mistake in relying on the temporary GRUU draf= t to handle privacy. There are way too many clients and Gateways already in= the field that will not be following this draft. I think this is going to = cause issues in deployments where there are older clients already in the fi= eld as we will not be able to park these existing deployments if they have = privacy enabled. > > If the major concern is the concern is making extensions to the Dialog ev= ent package then maybe the solution is to create a Callpark event package. > > I realize that I seem to hold the minority opinion on interacting with cl= ients and privacy, so at a minimum can we add a section on the issues with = private clients and routing and the recommendation that all clients in the = network have to support draft-ietf-sip-gruu-15 or there will be park failur= es. > > I can write up the issues if that would help. > > Scott > > > -----Original Message----- > From: Michael Procter [mailto:michael@voip.co.uk] > Sent: Thursday, May 14, 2009 1:13 AM > To: Orton, Scott (RICH1:B620) > Cc: Audet, Francois (SC100:3055); bliss@ietf.org > Subject: Re: [BLISS] Comments ondraft-procter-bliss-call-park-extension-0= 4(Privacy Interactions) > > Scott, > > Apologies for the delay. > > 2009/5/5 Scott Orton : >> =A0Michael, >> =A0 Can this also be addressed by subscribing to the dialog event? We >> might want to specify in a subscription to the dialog event that we >> want to be informed of any call parked by the subscribing user. This >> is a change from the current draft and would require a new uri parm in >> the Subscription. This way we can send the refer to the party being >> parked instead of using the unsolicited refer. >> >> Scott > > As Dale has just pointed out, it won't work without extensions to the dia= log event package and/or changes to the parked UA. =A0Since all this is to = work around a parked UA that doesn't provide a usable contact, it seems tha= t putting more requirements on it is unlikely to make the problem better! > > On balance, I think we are better off staying with the approach in the dr= aft. =A0I will be updating the draft shortly, in light of the comments rais= ed (I am waiting for one last set of comments offlist). > > Regards, > > Michael >