Re: [martini] New text for gin section 7.1.1 first paragraph

Adam Roach <adam@nostrum.com> Tue, 28 September 2010 19:15 UTC

Return-Path: <adam@nostrum.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 702813A6E15 for <martini@core3.amsl.com>; Tue, 28 Sep 2010 12:15:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 GJsZDfsijJj8 for <martini@core3.amsl.com>; Tue, 28 Sep 2010 12:15:12 -0700 (PDT)
Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id A10D63A6D29 for <martini@ietf.org>; Tue, 28 Sep 2010 12:15:10 -0700 (PDT)
Received: from [192.168.2.2] (m070e36d0.tmodns.net [208.54.14.7]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o8SJEmRd098418 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Sep 2010 14:14:58 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <4CA23EA2.40608@nostrum.com>
Date: Tue, 28 Sep 2010 14:14:42 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.9) Gecko/20100920 Thunderbird/3.1.4
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
References: <A444A0F8084434499206E78C106220CA01C81C2B32@MCHP058A.global-ad.net> <B1771F0F1F97A8478E2F449EA19CC7C5DA1A7EB3@ESESSCMS0365.eemea.ericsson.se> <A444A0F8084434499206E78C106220CA01C81C2D93@MCHP058A.global-ad.net> <F1A0ED6425368141998E077AC43334E425B8D6F6@gbplmail02.genband.com> <4CA21DF2.5080709@cisco.com> <DD8DA2BD-997C-420F-965F-98D9EEC7C6E9@acmepacket.com> <4CA23086.8010404@cisco.com>
In-Reply-To: <4CA23086.8010404@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "martini@ietf.org" <martini@ietf.org>, Hadriel Kaplan <HKaplan@acmepacket.com>
Subject: Re: [martini] New text for gin section 7.1.1 first paragraph
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: Tue, 28 Sep 2010 19:15:15 -0000

  I don't disagree with what Paul is saying, but I don't think it's the 
most compelling argument in this case.

The main issue is the same as it was for temp-gruu: support of GRUU in a 
MARTINI architecture requires support for GRUU at both registrars (the 
SSP and the PBX). This imposes a much, much higher barrier to deployment 
over the general case. The only way we can return this barrier to where 
is was before MARTINI got involved is by ensuring GRUU (or something 
similar) is available at the SSP.

/a

On 09/28/2010 01:14 PM, Paul Kyzivat wrote:
>
>
> On 9/28/2010 1:32 PM, Hadriel Kaplan wrote:
>>
>> You can look at it that way, or you can look at it a different way: 
>> all GIN is (supposed) to be doing is specifying a means to use 
>> REGISTER for bulk contacts - a compressed form of sending unique 
>> REGISTER requests per UA.  GRUU is not mandatory for REGISTER of a 
>> single AoR->contact, ergo it shouldn't be necessary for REGISTER of 
>> multiple AoR->contacts.  We're specifying a protocol, not a service 
>> profile.  The latter is more the SIP Forum's role, for example.
>
> Yeah. But if we were starting over I'm pretty certain we'd recognize 
> that UAs often don't have globally routable addresses of their own, 
> and would make GRUU mandatory for registrars. Its only historical 
> precedent that we don't have that. Here we have to opportunity not 
> make that mistake again.
>
>     Thanks,
>     Paul