IETF Logo Mail Archive

Re: [BLISS] Comments on draft-procter-bliss-call-park-extension-04(Privacy Interactions)

Michael Procter <michael@voip.co.uk> Fri, 01 May 2009 11:42 UTC

Return-Path: <michael@voip.co.uk>
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 <bliss@core3.amsl.com>; 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 <bliss@core3.amsl.com>; 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 <bliss@ietf.org>; 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 <bliss@ietf.org>; 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: <F592E36A5C943E4E91F25880D05AD1140937CB7A@zrc2hxm0.corp.nortel.com> <1241127003.19498.104.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1DC32AC4@zrc2hxm0.corp.nortel.com>
Date: Fri, 01 May 2009 12:43:51 +0100
Message-ID: <a2ef85430905010443i2fb0b9dfq135ec004ef5ab6d4@mail.gmail.com>
From: Michael Procter <michael@voip.co.uk>
To: Francois Audet <audet@nortel.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: bliss@ietf.org, Scott Orton <orton@nortel.com>
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" <bliss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/bliss>, <mailto:bliss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bliss>
List-Post: <mailto:bliss@ietf.org>
List-Help: <mailto:bliss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bliss>, <mailto:bliss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 01 May 2009 11:42:30 -0000

2009/4/30 Francois Audet <audet@nortel.com>:
> 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

v2.23.0 | Report a Bug | By Email