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

Christer Holmberg <> Fri, 03 September 2010 18:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 562313A6969 for <>; Fri, 3 Sep 2010 11:11:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.44
X-Spam-Status: No, score=-5.44 tagged_above=-999 required=5 tests=[AWL=1.159, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VSG1pl4+WozY for <>; Fri, 3 Sep 2010 11:11:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id B676B3A695F for <>; Fri, 3 Sep 2010 11:11:53 -0700 (PDT)
X-AuditID: c1b4fb3d-b7b90ae00000278d-78-4c813a86ae7f
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id D2.B6.10125.68A318C4; Fri, 3 Sep 2010 20:12:22 +0200 (CEST)
Received: from ([]) by ([]) with mapi; Fri, 3 Sep 2010 20:10:05 +0200
From: Christer Holmberg <>
To: Richard Shockey <>, "'Elwell, John'" <>, "" <>
Date: Fri, 3 Sep 2010 20:06:23 +0200
Thread-Topic: [martini] Consensus call: Resolution of Ticket #57
Thread-Index: ActGKlJngWbYSdI3SPmaz/craiFnNwElTtTgAC0D0DAAB8al9Q==
Message-ID: <>
References: <BLU137-W878D9ABB4B6A396E0682493860@phx.gbl> <>, <006e01cb4b74$b0cb15a0$126140e0$@us>
In-Reply-To: <006e01cb4b74$b0cb15a0$126140e0$@us>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAA==
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 18:11:56 -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 assume the support for GIN was more or less zero.

So, rather at looking at the current support of GRUU, I think the question is: IF you are going to implement support for GIN, are you also willing to implement support for GRUU?

>I prefer the use of SHOULD here.

As part of the War On Shoulds: if you are going to use a SHOULD, you need to describe when it doesn't apply.



-----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

martini mailing list