Re: [martini] Consensus call: Resolution of Ticket #57

"Richard Shockey" <> Fri, 03 September 2010 14:30 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D03B63A68DF for <>; Fri, 3 Sep 2010 07:30:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.39
X-Spam-Status: No, score=-102.39 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id O53-HWZ4B0f4 for <>; Fri, 3 Sep 2010 07:30:58 -0700 (PDT)
Received: from ( []) by (Postfix) with SMTP id 85C073A68D8 for <>; Fri, 3 Sep 2010 07:30:58 -0700 (PDT)
Received: (qmail 9554 invoked by uid 0); 3 Sep 2010 14:31:28 -0000
Received: from unknown (HELO ( by with SMTP; 3 Sep 2010 14:31:28 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default;; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=Co8t5ouynjyJL26KziQlR6dv3FnOeNFg4nuDgJCsyNL40+cLthO6RJ2py91OGg34fXmC3ANZYHpk2gNNj9eC7rpcrspVfGVGpT3qXSo9fnfXx+vbJ7QFu+VgtA9vNmB2;
Received: from ([] helo=RSHOCKEYPC) by with esmtpa (Exim 4.69) (envelope-from <>) id 1OrXId-0004A4-PN; Fri, 03 Sep 2010 08:31:28 -0600
From: Richard Shockey <>
To: "'Elwell, John'" <>,
References: <BLU137-W878D9ABB4B6A396E0682493860@phx.gbl> <>
In-Reply-To: <>
Date: Fri, 03 Sep 2010 10:31:25 -0400
Message-ID: <006e01cb4b74$b0cb15a0$126140e0$@us>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: ActGKlJngWbYSdI3SPmaz/craiFnNwElTtTgAC0D0DA=
Content-Language: en-us
X-Identified-User: {} {sentby:smtp auth authed with}
Subject: Re: [martini] Consensus call: Resolution of Ticket #57
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: Fri, 03 Sep 2010 14:30:59 -0000


I'm in complete agreement with John here. Adding the MUST requirement for
GRUU's on the SSP is in my judgment setting the bar too high.  The evidence
is here.

Its not clear to me what are the percentages of client vs server in the
SIPit results but I'm aware that many of the vendors of proxy's in current
SSP deployment do not currently support GRUU's.

I prefer the use of SHOULD here.

-----Original Message-----
From: [] On Behalf
Of Elwell, John
Sent: Thursday, September 02, 2010 1:04 PM
Subject: Re: [martini] Consensus call: Resolution of Ticket #57

I think what is paramount here is the ability for gin to gain traction in
the market place. Although in Maastricht I agreed to this resolution, along
with the other people in the room at the time, I had earlier in the meeting
expressed a concern about raising the bar too high for SSPs to adopt gin. If
SSPs are happy to keep support for public GRUU as a MUST, that is fine with
me. But if SSPs say this raises the bar too high and they will not be able
to implement gin within a reasonable timescale, I am concerned.

I know GRUU is needed to support attended transfer using REFER/Replaces. It
is also required to support transfer using REFER on a new dialog. However,
transfer between domains is generally done by 3PCC means (re-INVITE),
because of security / charging concerns about acting on a REFER request from
another domain. In my opinion public GRUU is not a necessary component of a
basic, entry level SIP interface between SIP-PBX and SSP.


> -----Original Message-----
> From: 
> [] On Behalf Of Bernard Aboba
> Sent: 27 August 2010 21:56
> To:
> Subject: [martini] Consensus call: Resolution of Ticket #57
> In the MARTINI WG second session at IETF 78, the participants 
> in the room came to consensus (12-0) on the following text to 
> resolve Issue 57:
> In order to provide support for privacy, the SSP
> SHOULD implement the temporary GRUU
> mechanism described in this section. Reasons for
> not doing so would include systems with an
> alternative privacy mechanism which maintains
> the integrity of public GRUUs (i.e., if public
> GRUUs are anonymized then the anonymizer
> function would need to be capable of providing as
> the anonymized URI a globally routable URI
> that routes back only to the target identified by
> the original public GRUU).
> We are now bringing this resolution to the mailing list to 
> verify that consensus. 
> If you did not express your opinion during the IETF 78 
> MARTINI WG meeting, and would like to do so now, please 
> respond to this email and post your opinion as to whether you 
> agree with the text above as a resolution to Issue 57. 
> This consensus call will last until September 12, 2010.  
martini mailing list