Re: [martini] GIN temp GRUU

Paul Kyzivat <pkyzivat@cisco.com> Thu, 01 July 2010 14:45 UTC

Return-Path: <pkyzivat@cisco.com>
X-Original-To: martini@core3.amsl.com
Delivered-To: martini@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A91483A68DE for <martini@core3.amsl.com>; Thu, 1 Jul 2010 07:45:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.273
X-Spam-Level:
X-Spam-Status: No, score=-10.273 tagged_above=-999 required=5 tests=[AWL=0.326, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
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 CCbNQRAVQmjP for <martini@core3.amsl.com>; Thu, 1 Jul 2010 07:45:29 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 9C7FD3A6907 for <martini@ietf.org>; Thu, 1 Jul 2010 07:45:29 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-AV: E=Sophos;i="4.53,520,1272844800"; d="scan'208";a="127750383"
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 01 Jul 2010 14:45:41 +0000
Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o61EjetD001407; Thu, 1 Jul 2010 14:45:41 GMT
Message-ID: <4C2CAA1F.7020809@cisco.com>
Date: Thu, 01 Jul 2010 10:45:51 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: Martien Huysmans <martien.huysmans@ericsson.com>
References: <0A5BADFA-AF90-454A-BB5F-6DA6259120C6@cisco.com> <B5CE2B521539624E8364D395B6F76B5C23D426043A@ESESSCMS0356.eemea.ericsson.se> <4C2BE02D.4080703@cisco.com> <B5CE2B521539624E8364D395B6F76B5C23D42607EA@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <B5CE2B521539624E8364D395B6F76B5C23D42607EA@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "martini@ietf.org" <martini@ietf.org>
Subject: Re: [martini] GIN temp GRUU
X-BeenThere: martini@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/martini>
List-Post: <mailto:martini@ietf.org>
List-Help: <mailto:martini-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 01 Jul 2010 14:45:30 -0000

Martien Huysmans wrote:
> The mail was called: GIN and anonymous GRUUS
> 
> I was not considering "out of dialog requests". 
> Is that a requirement for anonymous calls?

Its required for certain features to work, such as:

- transfers using REFER
- use of KPML

> With a B2BUA in place, perhaps gruu would not be needed at all.

Well, a contact is required that is globally routable, and that uniquely 
identifies the UA. In my book that is a GRUU, regardless of how it is 
constructed.

	Thanks,
	Paul

> /Regards Martien 
> 
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] 
> Sent: Thursday, July 01, 2010 2:24 AM
> To: Martien Huysmans
> Cc: Cullen Jennings; martini@ietf.org
> Subject: Re: [martini] GIN temp GRUU
> 
> 
> 
> Martien Huysmans wrote:
>> Hi
>>
>> In the mailing list also the option of a privacy service provided by 
>> the SSP was suggested, which when acting as B2BUA, would ensure that a party remains anonymous.
>> No comments were posted on this suggestion.
>> Can this be a viable alternative?
> 
> I didn't see that mail - can you provide a reference?
> 
> What privacy service spec/features does this imply?
> 
> To provide full functionality, for every dialog it would have to insert a B2BUA, create a temp gruu to replace the supplied contact, and then route out-of-dialog requests for that temp-gruu to the calling UA. And it would have to inactivate that temp-gruu at some suitable time.
> 
> The real gruu mechanism seems less trouble.
> 
> 	Thanks,
> 	Paul
> 
>> Regards Martien
>>
>> -----Original Message-----
>> From: martini-bounces@ietf.org [mailto:martini-bounces@ietf.org] On 
>> Behalf Of Cullen Jennings
>> Sent: Wednesday, June 16, 2010 7:01 PM
>> To: martini@ietf.org
>> Subject: [martini] GIN temp GRUU
>>
>>
>> I'm not OK with requiring out of band provisioning for K_e2. This would be a nightmare in practice. Could it be passed in the register response?
>>
>> Having this as optional does not really work for me because most the US based customers doing PSTN replacement believe they are required to provide anonymous call. 
>>
>> Overall, looks workable yet complicated - I wish there was a simpler way but I could live with this. 
>>
>>
>>
>> _______________________________________________
>> martini mailing list
>> martini@ietf.org
>> https://www.ietf.org/mailman/listinfo/martini
>> _______________________________________________
>> martini mailing list
>> martini@ietf.org
>> https://www.ietf.org/mailman/listinfo/martini
>>
>