Subject: Re: [martini] Call for Consensus: Support for Public GRUUs

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 1 Sep 2010 13:08:57 +0200

No.

The key question is whether the SSP end supports GRUU (as originally posted), so it is available to a PBX UA if it requires a service that uses it.

While I agree that GRUU is currently optional for registrars to deploy, I suspect that if we started SIP now, an appropriate mechanism would have been a mandatory element for registrars. Optional is possible in the direct UA to registrar case because the UA at least has some direct choice over which registrars it uses.

In the PBX environment, a UA wishing to use GRUUs to implement a service has very little choice over which business trunking arrangements it uses.

So no support of GRUUs at the SSP in business trunking means no service using GRUUs within the private network.

Keith

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Brian Lindsay
> Sent: Monday, August 30, 2010 10:30 PM
> To: Cullen Jennings; [email-masked]
> Subject: Re: [martini] Call for Consensus: Support for Public GRUUs
> 
> Hi,
> 
>   If GIN truly "breaks" SIP, then wouldn't that mean that SIP 
> PBXs, and their UA's, would also need to be mandated to 
> support GRUU (which doesn't seem to be the suggestion).
> 
>   Now perhaps something like an out-of-dialog REFER for Call 
> Transfer to the SIP PBX won't be possible without GRUU. But 
> is that truly a mandatory capability that is required to be 
> supported as part of a basic SIP PBX offering by a service 
> provider? Or would be ubiquitously supported/allowed by SIP PBXs?
> 
>  Thanks
>      Brian
> 
> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Cullen Jennings
> Sent: Monday, August 30, 2010 4:13 PM
> To: [email-masked]
> Subject: Re: [martini] Call for Consensus: Support for Public GRUUs
> 
> 
> GIN breaks significant parts of SIP without GRUUs (or some 
> equivalent functionality) so I think we need GRUUs to be 
> required to be implement on the SSP side of GIN. 
> 
> 
> On Aug 28, 2010, at 1:44 PM, Bernard Aboba wrote:
> 
> > At the IETF 78 MARTINI WG meeting, during the discussion of 
> Ticket 57 (relating to temporary GRUUs), a suggestion was 
> made that public GRUUs be mandatory to implement for SSPs.  
> > 
> > We will now attempt to determine whether consensus exists 
> within the MARTINI WG to make this change to the document. 
> > 
> > Please respond to this email and post your opinion as to 
> whether you agree that SSPs supporting MARTINI MUST implement 
> support for public GRUUs. 
> > 
> > This consensus call will last until September 12, 2010.  
> > _______________________________________________
> > martini mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/martini
> 
> 
> Cullen Jennings
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
> 
> 
> 
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini
>

---

From: Brian Lindsay <[email-masked]>
Date: Wed, 1 Sep 2010 14:28:56 +0000

Hi Keith,

   Agree an individual UA within an enterprise doesn't have any choice about business trunking arrangement used, but the parent enterprise deploying the PBX and UA's does. An enterprise would be free to select a specific service provider that offered a GRUU capability if that was important to the enterprise from a service perspective. (Service providers could hypothetically even charge for GRUU as an incremental capability).

  Also, what precludes usage of GRUU's internally within an enterprise as long as the PBX doesn't send them towards the network?

  Thanks
     Brian

-----Original Message-----
From: DRAGE, Keith (Keith) [mailto:[email-masked]] 
Sent: Wednesday, September 01, 2010 7:09 AM
To: Brian Lindsay; [email-masked]
Subject: RE: [martini] Call for Consensus: Support for Public GRUUs

No.

Keith

---

From: Adam Roach <[email-masked]>
Date: Wed, 01 Sep 2010 09:37:28 -0500

>    Also, what precludes usage of GRUU's internally within an enterprise as long as the PBX doesn't send them towards the network?

That kinda defeats the purpose of using GRUUs.

/a

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 2 Sep 2010 17:56:06 +0200

According to the rough rule of thumb figures I learnt 30 years ago, on average 50% of the traffic is internal to a PBX and 50% outside. While those figures may have changed over the intervening years due to more advance private networking, I'm sure they are not that far out. So you are eliminating the usages of services that may use GRUUs from 50% of the traffic, based on the desire or not of the service provider to implement a capability.

More concerning is that the absence or not of this capability is totally invisible to the end UA, and indeed even to many elements of the PBX itself. So we have no means to find out whether a capability exists before we actually try and use it.

regards

Keith 

> From: Brian Lindsay [mailto:[email-masked]] 
> Sent: Wednesday, September 01, 2010 3:29 PM
> To: DRAGE, Keith (Keith); [email-masked]
>    Agree an individual UA within an enterprise doesn't have 
> any choice about business trunking arrangement used, but the 
> parent enterprise deploying the PBX and UA's does. An 
> enterprise would be free to select a specific service 
> provider that offered a GRUU capability if that was important 
> to the enterprise from a service perspective. (Service 
> providers could hypothetically even charge for GRUU as an 
> incremental capability).
> 
>   Also, what precludes usage of GRUU's internally within an 
> enterprise as long as the PBX doesn't send them towards the network?
> 
>   Thanks
>      Brian
> 
> 
> The key question is whether the SSP end supports GRUU (as 
> originally posted), so it is available to a PBX UA if it 
> requires a service that uses it.
> 
> While I agree that GRUU is currently optional for registrars 
> to deploy, I suspect that if we started SIP now, an 
> appropriate mechanism would have been a mandatory element for 
> registrars. Optional is possible in the direct UA to 
> registrar case because the UA at least has some direct choice 
> over which registrars it uses.
> 
> In the PBX environment, a UA wishing to use GRUUs to 
> implement a service has very little choice over which 
> business trunking arrangements it uses.
> 
> So no support of GRUUs at the SSP in business trunking means 
> no service using GRUUs within the private network.
> 
> Keith
> 
> >   If GIN truly "breaks" SIP, then wouldn't that mean that SIP PBXs, 
> > and their UA's, would also need to be mandated to support 
> GRUU (which 
> > doesn't seem to be the suggestion).
> > 
> >   Now perhaps something like an out-of-dialog REFER for 
> Call Transfer 
> > to the SIP PBX won't be possible without GRUU. But is that truly a 
> > mandatory capability that is required to be supported as part of a 
> > basic SIP PBX offering by a service provider? Or would be 
> ubiquitously 
> > supported/allowed by SIP PBXs?
> > 
> >  Thanks
> >      Brian
> > 
> equivalent 
> > functionality) so I think we need GRUUs to be required to 
> be implement 
> > on the SSP side of GIN.
> > 
> > 
> > Ticket 57 (relating to temporary GRUUs), a suggestion was made that 
> > public GRUUs be mandatory to implement for SSPs.
> > > 
> > whether you agree that SSPs supporting MARTINI MUST 
> implement support 
> > for public GRUUs.
> > >

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 2 Sep 2010 19:03:30 +0200

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.

John

> [mailto:[email-masked]] On Behalf Of Bernard Aboba
> Sent: 27 August 2010 21:56
> To: [email-masked]
> 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. 
>

---

From: "Andrew Allen" <[email-masked]>
Date: Fri, 3 Sep 2010 02:14:16 -0500

John

What is the "too high bar" that supporting public GRUU represents? 

As was discussed during the IETF session public GRUU implementation is straight forward (and everyone seemed to agree that). 

Temporary GRUU is more complex but the proposed wording allows for other mechanisms to be used in place of temporary GRUUs provided they don't break use of public GRUUs.

Can someone outline what the concern with supporting Public GRUU is and why this would prevent SSPs implementing suppirt for GIN?

Andrew

----- Original Message -----
From: Elwell, John [mailto:[email-masked]]
Sent: Thursday, September 02, 2010 01:03 PM
To: [email-masked] <[email-masked]>
Subject: Re: [martini] Consensus call:  Resolution of Ticket #57

John

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.

---

From: "Elwell, John" <[email-masked]>
Date: Fri, 3 Sep 2010 09:20:13 +0200

Andrew,

That is for SSPs and their vendors to say. As a SIP-PBX vendor, I don't want to find that SSPs don't implement gin (and hence don't implement SIPconnect 1.1 registration mode) because we have made it unnecessarily complicated. I agree it is a lot easier to implement public GRUU than temporary GRUU. If SSPs and their vendors are happy, that's fine, but I don't think we have heard from sufficient.

John

> From: Andrew Allen [mailto:[email-masked]] 
> Sent: 03 September 2010 08:14
> To: Elwell, John; [email-masked]
> As was discussed during the IETF session public GRUU 
> implementation is straight forward (and everyone seemed to 
> agree that). 
> 
> Temporary GRUU is more complex but the proposed wording 
> allows for other mechanisms to be used in place of temporary 
> GRUUs provided they don't break use of public GRUUs.
> 
> Can someone outline what the concern with supporting Public 
> GRUU is and why this would prevent SSPs implementing suppirt for GIN?
> 
> Andrew
> 
> 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.
> 
> John
> 
> 
> This transmission (including any attachments) may contain 
> confidential information, privileged material (including 
> material protected by the solicitor-client or other 
> applicable privileges), or constitute non-public information. 
> Any use of this information by anyone other than the intended 
> recipient is prohibited. If you have received this 
> transmission in error, please immediately reply to the sender 
> and delete this information from your system. Use, 
> dissemination, distribution, or reproduction of this 
> transmission by unintended recipients is not authorized and 
> may be unlawful.
>

---

From: <[email-masked]>
Date: Fri, 3 Sep 2010 09:33:39 +0200

I don't think that the support of GRUU will be a key criteria for SSPs to decide whether to implement gin or not. The fact that the gin solution is not compatible with the IMS solution will certainly have more weigth in their decisions, at least for those having rolled out an IMS-based network.
Bruno

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Elwell, John
> Envoyé : vendredi 3 septembre 2010 09:20
> À : Andrew Allen; [email-masked]
> Objet : Re: [martini] Consensus call: Resolution of Ticket #57
> 
> Andrew,
> 
> That is for SSPs and their vendors to say. As a SIP-PBX 
> vendor, I don't want to find that SSPs don't implement gin 
> (and hence don't implement SIPconnect 1.1 registration mode) 
> because we have made it unnecessarily complicated. I agree it 
> is a lot easier to implement public GRUU than temporary GRUU. 
> If SSPs and their vendors are happy, that's fine, but I don't 
> think we have heard from sufficient.
> 
> John
>  
> 
> implementation is 
> > straight forward (and everyone seemed to agree that).
> > 
> > Temporary GRUU is more complex but the proposed wording allows for 
> > other mechanisms to be used in place of temporary GRUUs 
> provided they 
> > don't break use of public GRUUs.
> > 
> > Can someone outline what the concern with supporting Public GRUU is 
> > and why this would prevent SSPs implementing suppirt for GIN?
> > 
> > Andrew
> > 
> > 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.
> > 
> > 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.
> > 
> > John
> > 
> > 
> > > 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.
> > > 
> confidential 
> > information, privileged material (including material 
> protected by the 
> > solicitor-client or other applicable privileges), or constitute 
> > non-public information.
> > recipient is prohibited. If you have received this transmission in 
> > error, please immediately reply to the sender and delete this 
> > information from your system. Use, dissemination, distribution, or 
> > reproduction of this transmission by unintended recipients is not 
> > authorized and may be unlawful.
> >

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 3 Sep 2010 10:23:39 -0400

Maybe ...maybe not. That is for the market to decide.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of [email-masked]
Sent: Friday, September 03, 2010 3:34 AM
To: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [martini] Consensus call: Resolution of Ticket #57

I don't think that the support of GRUU will be a key criteria for SSPs to
decide whether to implement gin or not. The fact that the gin solution is
not compatible with the IMS solution will certainly have more weigth in
their decisions, at least for those having rolled out an IMS-based network.
Bruno

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 3 Sep 2010 10:31:25 -0400

+1  

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.

https://www.sipit.net/SIPit26_Summary

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: [email-masked] [mailto:[email-masked]] On Behalf
Of Elwell, John
Sent: Thursday, September 02, 2010 1:04 PM
To: [email-masked]
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.

John

---

From: Adam Roach <[email-masked]>
Date: Fri, 03 Sep 2010 09:40:43 -0500

> https://www.sipit.net/SIPit26_Summary

Wow. Server implementation is at 31%. That's better than some of the 
IMS-mandated (MUST, not SHOULD) mechanisms like service-route (23%) and 
sigcomp (15%). And it ties with ipsec, which is also MUST-strength in 
IMS networks.

That's quite a bit higher implementation penetration than I expected.

Basically, it means that making GRUU a MUST will hinder GIN deployment 
_LESS_ _THAN_ service-route, sigcomp, and ipsec will for IMS. I think 
that's pretty good.

/a

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 Sep 2010 20:06:23 +0200

Hi,

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

Regards,

Christer

-----Original Message-----

John

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 3 Sep 2010 20:13:46 +0200

Hi,

>sigcomp (15%). And it ties with ipsec, which is also MUST-strength in

I guess that means that the IMS compliant products are not present at SIPit :)

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 7 Sep 2010 14:31:04 +0200

Hi,

>>Also, what precludes usage of GRUU's internally within 
>>an enterprise as long as the PBX doesn't send them towards 
>>the network?
> 

We do have a requirement saying:

 REQ16:  The mechanism MUST allow the SIP-PBX to provide its UAs with
           public or temporary Globally Routable UA URIs (GRUUs)
           [RFC5627].

So, doesn't that mean that unless the GRUUs are provided by the SSP, the PBX has to generate them itself?

Regards,

Christer

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 7 Sep 2010 16:29:59 +0200

Christer,

REQ-16 is satisfied, since the mechanism does allow this. What we are discussing is whether the SP MUST support that mechanism.

John

> [mailto:[email-masked]] On Behalf Of Christer Holmberg
> Sent: 07 September 2010 13:31
> To: Adam Roach; Brian Lindsay
> Cc: DRAGE, Keith (Keith); [email-masked]
> So, doesn't that mean that unless the GRUUs are provided by 
> the SSP, the PBX has to generate them itself?
> 
> Regards,
> 
> Christer
>

---

From: "Richard Shockey" <[email-masked]>
Date: Thu, 9 Sep 2010 09:45:10 -0400

And to restate my position the preferred bar should be "SP SHOULD support"
vs MUST support for Public GRUU's 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Elwell, John
Sent: Tuesday, September 07, 2010 10:30 AM
To: Christer Holmberg; Adam Roach; Brian Lindsay
Cc: DRAGE, Keith (Keith); [email-masked]
Subject: Re: [martini] Call for Consensus: Support for Public GRUUs

Christer,

REQ-16 is satisfied, since the mechanism does allow this. What we are
discussing is whether the SP MUST support that mechanism.

John

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 9 Sep 2010 19:54:10 +0000

+1 (speaking as an individual).  

-----Original Message-----

Christer,

John

---

From: Alan Johnston <[email-masked]>
Date: Thu, 09 Sep 2010 15:23:43 -0500

I agree with SHOULD and not MUST.

- Alan -

---

From: Dean Willis <[email-masked]>
Date: Thu, 9 Sep 2010 18:32:33 -0500

> I guess that means that the IMS compliant products are not present  

Or are totally imaginary.

There's a difference between IMS-oriented and IMS-compliant products.  
To the best of my ability to discern, nobody has an IMS-compliant  
product. They have partially compliant products that are oriented  
towards the IMS market, with vaguely-expressed hopes of becoming more  
compliant if it turns out to be a market requirement, which it never  
will as long as single vendors have locks on monolithic deployments.

--
Dean

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 10 Sep 2010 07:51:22 +0200

Hi, 

>There's a difference between IMS-oriented and IMS-compliant products. To the best of my ability to discern, nobody has an IMS-compliant product. 

There are many optional features in IMS, and some profiling has also been done, so I guess it is difficult to define what "IMS-compliant" really means.

But, they may still not be at SIPit :)

Regards,

Christer