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

Brian Lindsay <> Wed, 29 September 2010 19:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 41EF23A6D4F for <>; Wed, 29 Sep 2010 12:07:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.475
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 0TGnDYxB18eH for <>; Wed, 29 Sep 2010 12:07:03 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 431213A6D32 for <>; Wed, 29 Sep 2010 12:07:00 -0700 (PDT)
Received: from source ([]) (using TLSv1) by ([]) with SMTP ID; Wed, 29 Sep 2010 12:07:47 PDT
Received: from ([]) by over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 29 Sep 2010 14:00:19 -0500
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Wed, 29 Sep 2010 14:00:14 -0500
Received: from ([fe80::9455:4039:582f:aee8]) by ([fe80::d970:2fee:a0c2:9f26%15]) with mapi id 14.01.0218.012; Wed, 29 Sep 2010 14:00:14 -0500
From: Brian Lindsay <>
To: Paul Kyzivat <>
Thread-Topic: [martini] New text for gin section 7.1.1 first paragraph
Thread-Index: AQHLXzj+QEqRNqg7RASa/wirvRety5MnuZsAgAASk6CAAHATgIAATHSAgACfCjCAAGZKgP//rH+ggABl5wD//69I8A==
Date: Wed, 29 Sep 2010 19:00:14 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 29 Sep 2010 19:00:19.0059 (UTC) FILETIME=[8F502430:01CB6008]
X-TM-AS-Product-Ver: SMEX-
X-TM-AS-Result: No--19.847000-5.000000-31
X-TM-AS-User-Approved-Sender: No
X-TM-AS-User-Blocked-Sender: No
Cc: "" <>, Hadriel Kaplan <>
Subject: Re: [martini] New text for gin section 7.1.1 first paragraph
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of en-mass SIP PBX registration mechanisms <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 29 Sep 2010 19:07:04 -0000

Hi Paul,

  Shouldn't the GIN MUST's be primarily around interoperability of the GIN registration mechanism itself?

  I don't think GRUU falls into that category. GRUU isn't required to make use of the GIN Registration mechanism. It isn't required in all deployments. Yes, GRUU's can be very useful but that doesn't mean that it's in the scope of GIN to mandate them.


-----Original Message-----
From: Paul Kyzivat [] 
Sent: Wednesday, September 29, 2010 2:39 PM
To: Brian Lindsay
Cc: Hadriel Kaplan; Elwell, John;
Subject: Re: [martini] New text for gin section 7.1.1 first paragraph

Then why don't we just change all the MUSTs and SHOULDs in gin to MAYs 
??? The users can negotiate with their SSP over which ones are supported.


On 9/29/2010 2:00 PM, Brian Lindsay wrote:
> Hi Hadriel,
>     My preference, rather than having a MUST with an unless clause, is to not use MUST in the 1st place. I think your comments below reflect the fact that the unless clause is really something that should be out of scope of the draft - and that there should not be a need for an associated MUST on requirements for GRUU.
>     Thanks
>        Brian
> -----Original Message-----
> From: Hadriel Kaplan []
> Sent: Wednesday, September 29, 2010 1:33 PM
> To: Brian Lindsay
> Cc: Paul Kyzivat; Elwell, John;
> Subject: Re: [martini] New text for gin section 7.1.1 first paragraph
> 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