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

Hadriel Kaplan <HKaplan@acmepacket.com> Wed, 29 September 2010 17:32 UTC

Return-Path: <HKaplan@acmepacket.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 0845C3A6D14 for <martini@core3.amsl.com>; Wed, 29 Sep 2010 10:32:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.478
X-Spam-Level:
X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.121, 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 lVOXkXUh23y3 for <martini@core3.amsl.com>; Wed, 29 Sep 2010 10:32:27 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A15413A6B4C for <martini@ietf.org>; Wed, 29 Sep 2010 10:32:26 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 29 Sep 2010 13:33:10 -0400
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 29 Sep 2010 13:32:48 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Brian Lindsay <brian.lindsay@genband.com>
Date: Wed, 29 Sep 2010 13:32:47 -0400
Thread-Topic: [martini] New text for gin section 7.1.1 first paragraph
Thread-Index: Actf/FVjeKlrVZwVRRujvQ7W+vvJJQ==
Message-ID: <E928D7D5-31E8-44DA-BF0D-939CBED6355D@acmepacket.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> <F1A0ED6425368141998E077AC43334E425B8D7D5@gbplmail02.genband.com> <A444A0F8084434499206E78C106220CA01C829452C@MCHP058A.global-ad.net> <D32EE33B-4599-4DA0-96D4-A7054325C20C@acmepacket.com> <4CA29D07.3020203@cisco.com> <F1A0ED6425368141998E077AC43334E425B8DADA@gbplmail02.genband.com>
In-Reply-To: <F1A0ED6425368141998E077AC43334E425B8DADA@gbplmail02.genband.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "martini@ietf.org" <martini@ietf.org>
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: Wed, 29 Sep 2010 17:32:29 -0000

But it doesn't mandate GRUU be used with GIN.  John's proposed text is:
"An SSP needs to provide a means of assigning a globally routable contact URI to a UA behind a SIP-PBX, thereby allowing other entities to address out-of-dialog requests to that UA. To achieve this, an SSP MUST support the public GRUU mechanism described in this section, unless the SSP has other means of providing globally routable contact URIs (e.g., by acting as a B2BUA and performing mapping between SIP-PBX-provided local contact URIs and SSP-provided globally routable contact URIs)."

The "unless..." exemption means you don't have to do GRUU, which means the REGISTER response does not have to provide one, which means the PBX can't expect there to be one in it.  So the registration succeeds, sans GRUU.  At that point an SSP can do whatever it likes, since the rest of the "unless..." statement is unenforceable and undetectable on-the-wire.  You'd only "detect" it's not complied with if a particular service like transfer doesn't work in some scenario; and whether to support that scenario is a decision between the SSP and its Enterprise customer at that point.  It's really just hubris on the IETF's part, but who cares?

-hadriel

On Sep 29, 2010, at 12:52 PM, Brian Lindsay wrote:

>  GIN has defined a how GRUU's can be used with the GIN mechanism, but I don't think it's necessary to mandate when they are used. It's technically possible to use the basic GIN registration mechanism independent of GRUU, so I think the coupling isn't necessary.
> 
> 
> Thanks,
> Brian