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

From: "Elwell, John" <[email-masked]>
Date: Mon, 27 Sep 2010 21:30:02 +0200

As actioned on this evening's call, here is my proposed text:

"An SSP needs to provide a means of assigning globally routable contact URIs to UAs that have been registered using the bulk registration mechanism specified in this document, thereby allowing other entities to address out-of-dialog requests to those UAs. 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)."

John

---

From: Adam Roach <[email-masked]>
Date: Mon, 27 Sep 2010 15:18:19 -0500

I support this proposed text. I believe it strikes a good balance 
between mandating GRUUs and providing networks with alternative 
architectures the ability to implement routing as they see fit.

/a

On 9/27/10 2:30 PM, Elwell, John wrote:
> _______________________________________________
> martini mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/martini

---

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 27 Sep 2010 15:29:48 -0500

Speaking as an individual here, I agree that the tradeoff Adam names is the 
right tradeoff, and I agree that the text John provided makes that tradeoff.

John, Thanks for the quick turn-around (as always).

Spencer

>  I support this proposed text. I believe it strikes a good balance between 
> mandating GRUUs and providing networks with alternative architectures the 
> ability to implement routing as they see fit.
>
> /a
>
>> "An SSP needs to provide a means of assigning globally routable contact 
>> URIs to UAs that have been registered using the bulk registration 
>> mechanism specified in this document, thereby allowing other entities to 
>> address out-of-dialog requests to those UAs. 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)."
>>
>> John

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 27 Sep 2010 16:40:00 -0400

I'm also happy with this text.

Now we get to confront the language police: is "... MUST ... unless P 
..." acceptable? (I'm pretty sure the logically equivalent "... if !P 
then MUST ..." has to be ok.)

	Thanks,
	Paul

On 9/27/2010 4:18 PM, Adam Roach wrote:
>> "An SSP needs to provide a means of assigning globally routable
>> contact URIs to UAs that have been registered using the bulk
>> registration mechanism specified in this document, thereby allowing
>> other entities to address out-of-dialog requests to those UAs. 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)."
>>
>> John

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 27 Sep 2010 18:29:34 -0400

Sounds good to me.
-hadriel

---

From: "Andrew Allen" <[email-masked]>
Date: Mon, 27 Sep 2010 18:26:33 -0500

I'm OK with this

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Elwell, John
Sent: Monday, September 27, 2010 2:30 PM
To: [email-masked]
Subject: [martini] New text for gin section 7.1.1 first paragraph

"An SSP needs to provide a means of assigning globally routable contact
URIs to UAs that have been registered using the bulk registration
mechanism specified in this document, thereby allowing other entities to
address out-of-dialog requests to those UAs. 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)."

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: Tue, 28 Sep 2010 08:12:40 +0200

Paul,

One could rephrase it in terms of "Unless .... MUST", but I tend to prefer a style of stating the normal case first, and any exceptions afterwards. As others who have responded seem to be in agreement with the text as it stands, let's leave it as is.

John 

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 27 September 2010 21:40
> To: Adam Roach
> Cc: Elwell, John; [email-masked]
> Subject: Re: [martini] New text for gin section 7.1.1 first paragraph
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 28 Sep 2010 11:52:08 +0200

Martien has privately indicated to me a certain lack of clarity in the proposed text. In thinking about this again, I haven't got the wording quite right. The bulk registration mechanism doesn't register UAs behind the PBX - it registers contacts for each of the AORs assigned to the PBX. What we are concerned about here is contact URIs for UAs behind the PBX. Those UAs register with the PBX, they do not register using the bulk registration mechanism. So my revised words would be as follows (only the first sentence has changed):

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

John

> From: Elwell, John 
> Sent: 28 September 2010 08:44
> To: 'Martien Huysmans'
> Subject: RE: New text for gin section 7.1.1 first paragraph
> 
> Martien,
> 
> Yes, in thinking about this again, I haven't got the wording 
> quite right. The bulk registration mechanism doesn't register 
> UAs behind the PBX - it registers contacts for each of the 
> AORs assigned to the PBX. What we are concerned about here is 
> contact URIs for UAs behind the PBX. Those UAs register with 
> the PBX, they do not register using the bulk registration 
> mechanism. So my revised words would be as follows (only the 
> first sentence has changed):
> 
> "An SSP needs to provide a means of assigning globally 
> routable contact URIs to UAs behind a SIP-PBX, thereby 
> allowing other entities to address out-of-dialog requests to 
> those UAs. 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 
> SIP-PBX-provided local contact URIs and SSP-provided globally 
> routable contact URIs)."
> 
> John
> 
> > From: Martien Huysmans [mailto:[email-masked]] 
> > Sent: 28 September 2010 08:13
> > To: Elwell, John
> > Subject: RE: New text for gin section 7.1.1 first paragraph
> > 
> > I find this a difficult sentence to understand. Is UA the 
> > SIP-PBX or the UA behind the SIP-PBX. So I propose to add 
> > "behind a SIP-PBX".
> > 
> > An SSP needs to provide a means of assigning globally 
> > routable contact URIs to UAs behind a SIP-PBX ...
> > 
> > Regards Martien
> > 
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Elwell, John
> > Sent: Monday, September 27, 2010 9:30 PM
> > To: [email-masked]
> > "An SSP needs to provide a means of assigning globally 
> > routable contact URIs to UAs that have been registered using 
> > the bulk registration mechanism specified in this document, 
> > thereby allowing other entities to address out-of-dialog 
> > requests to those UAs. 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)."
> > 
> > John

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Sep 2010 08:39:21 -0400

> One could rephrase it in terms of "Unless .... MUST", but I tend to prefer a style of stating the normal case first, and any exceptions afterwards. As others who have responded seem to be in agreem…

Yeah, me too. I was really just pointing out the idiocy of reputed 
objections to such language. But hopefully they are just urban legends.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Tue, 28 Sep 2010 08:25:29 -0500

This text is fine too.

/a

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 28 Sep 2010 10:59:40 -0400

+1 though I would have preferred SHOULD. 

My principal concern has been deployment. I would roughly guess it will take
2 years or more for this to make the rounds.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adam Roach
Sent: Tuesday, September 28, 2010 9:25 AM
To: Elwell, John
Cc: [email-masked]
Subject: Re: [martini] New text for gin section 7.1.1 first paragraph

  This text is fine too.

/a

On 9/28/10 04:52, Sep 28, Elwell, John wrote:
> Martien has privately indicated to me a certain lack of clarity in the
proposed text. In thinking about this again, I haven't got the wording quite
right. The bulk registration mechanism doesn't register UAs behind the PBX -
it registers contacts for each of the AORs assigned to the PBX. What we are
concerned about here is contact URIs for UAs behind the PBX. Those UAs
register with the PBX, they do not register using the bulk registration
mechanism. So my revised words would be as follows (only the first sentence
has changed):
>
> "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)."

---

From: Brian Lindsay <[email-masked]>
Date: Tue, 28 Sep 2010 16:34:31 +0000

Hi John/all,

   Whether support for routing of out-of-dialog requests to a contact is required should depend on the service offering of the SSP. For example, SSP support for an out-of-dialog REFER to a contact URI shouldn't be considered mandatory as discussed previously. As such, I think the text proposed should be conditional based on whether such services are supported by the SSP across it's interfaces.

   Here is some alternate proposed text:

"Some services may require that entities, outside the SIP PBX, be able to send out-of-dialog requests to a UA behind a SIP-PBX, using a globally routable contact URI. If an SSP supports such services across the SSP interfaces, the 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. In such a case the lifetime of the mapping may depend on the services supported by the SSP)." 

   Regards
       Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Elwell, John
Sent: Tuesday, September 28, 2010 5:52 AM
To: [email-masked]
Subject: Re: [martini] New text for gin section 7.1.1 first paragraph

John

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Sep 2010 12:55:14 -0400

>     Whether support for routing of out-of-dialog requests to a contact is required should depend on the service offering of the SSP. For example, SSP support for an out-of-dialog REFER to a contact…

This implies that the SSP knows and controls all the services that may 
be used with its customers.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Tue, 28 Sep 2010 12:11:02 -0500

On 9/28/10 11:55, Sep 28, Paul Kyzivat wrote:
>>     Whether support for routing of out-of-dialog requests to a 
>> contact is required should depend on the service offering of the SSP. 
>> For example, SSP support for an out-of-dialog REFER to a contact URI 
>> shouldn't be considered mandatory as discussed previously. As such, I 
>> think the text proposed should be conditional based on whether such 
>> services are supported by the SSP across it's interfaces.
>

Paul is 100% correct -- many services in the SIP network are handled 
exclusively by the UAs, with no need for intermediaries to perform any 
special processing at all. The SSP cannot possibly know all the services 
that the UAs are capable of.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 28 Sep 2010 13:32:41 -0400

You can look at it that way, or you can look at it a different way: all GIN is (supposed) to be doing is specifying a means to use REGISTER for bulk contacts - a compressed form of sending unique REGISTER requests per UA.  GRUU is not mandatory for REGISTER of a single AoR->contact, ergo it shouldn't be necessary for REGISTER of multiple AoR->contacts.  We're specifying a protocol, not a service profile.  The latter is more the SIP Forum's role, for example.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 28 Sep 2010 13:40:06 -0400

Brian,
does it really matter?  I mean John's current proposed text is basically a get-out-of-jail card.  The "unless..." clause is an untestable, abstract condition; and anyone who doesn't want to handle GRUUs doesn't have to.  As a vendor you don't have to, and as an SSP you don't have to.  So what's there to argue about?

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Sep 2010 14:14:30 -0400

> You can look at it that way, or you can look at it a different way: all GIN is (supposed) to be doing is specifying a means to use REGISTER for bulk contacts - a compressed form of sending unique R…

Yeah. But if we were starting over I'm pretty certain we'd recognize 
that UAs often don't have globally routable addresses of their own, and 
would make GRUU mandatory for registrars. Its only historical precedent 
that we don't have that. Here we have to opportunity not make that 
mistake again.

	Thanks,
	Paul

---

From: Brian Lindsay <[email-masked]>
Date: Tue, 28 Sep 2010 18:46:08 +0000

Hi,

  I agree with Hadriel. It seems to be over-stepping the original focus of Martini to mandate GRUU's in some form (even to the extent of the proposed language), given that the services to be supported between the SIP PBX and the SSP (and the interaction between the SSP and other entities) are out of scope. 

  Thanks
     Brian 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Tuesday, September 28, 2010 2:15 PM
To: Hadriel Kaplan
Cc: [email-masked]
Subject: Re: [martini] New text for gin section 7.1.1 first paragraph

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Tue, 28 Sep 2010 14:14:42 -0500

I don't disagree with what Paul is saying, but I don't think it's the 
most compelling argument in this case.

The main issue is the same as it was for temp-gruu: support of GRUU in a 
MARTINI architecture requires support for GRUU at both registrars (the 
SSP and the PBX). This imposes a much, much higher barrier to deployment 
over the general case. The only way we can return this barrier to where 
is was before MARTINI got involved is by ensuring GRUU (or something 
similar) is available at the SSP.

/a

On 09/28/2010 01:14 PM, Paul Kyzivat wrote:
>> You can look at it that way, or you can look at it a different way: 
>> all GIN is (supposed) to be doing is specifying a means to use 
>> REGISTER for bulk contacts - a compressed form of sending unique 
>> REGISTER requests per UA.  GRUU is not mandatory for REGISTER of a 
>> single AoR->contact, ergo it shouldn't be necessary for REGISTER of 
>> multiple AoR->contacts.  We're specifying a protocol, not a service 
>> profile.  The latter is more the SIP Forum's role, for example.
>
> that UAs often don't have globally routable addresses of their own, 
> and would make GRUU mandatory for registrars. Its only historical 
> precedent that we don't have that. Here we have to opportunity not 
> make that mistake again.
>
>     Thanks,
>     Paul

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 28 Sep 2010 21:51:28 +0200

Brian,

The proposed text does have an opt-out provision, i.e., if you provide some other means of assigning a globally routable URI on behalf of a UA behind the PBX. I think an SP that doesn't support GRUU will need to do this anyway. 

Suppose some third party wants to do attended transfer, and the transfer target is a UA behind the PBX. The third party will issue a REFER request with Refer-to that results in an INVITE request targeted at the UA behind the SIP-PBX. So a URI targeting that UA is required. One solution to that is for the SIP-PBX to have provided the UA with a GRUU, based on a template from the SP. Another solution is for the UA to use a local contact URI, which the SP B2BUA maps to a globally routable UA (which is basically pre-GRUU normal practice). Either way, the third party receives a globally routable URI that it can place in Refer-To. In other words, I think the SP will need to do one of the two things the proposed text allows.

John 

> [mailto:[email-masked]] On Behalf Of Brian Lindsay
> Sent: 28 September 2010 19:46
> To: Paul Kyzivat; Hadriel Kaplan
> Cc: [email-masked]
>   I agree with Hadriel. It seems to be over-stepping the 
> original focus of Martini to mandate GRUU's in some form 
> (even to the extent of the proposed language), given that the 
> services to be supported between the SIP PBX and the SSP (and 
> the interaction between the SSP and other entities) are out of scope. 
> 
>   Thanks
>      Brian 
> 
> 
> [mailto:[email-masked]] On Behalf Of Paul Kyzivat
> > You can look at it that way, or you can look at it a 
> different way: all GIN is (supposed) to be doing is 
> specifying a means to use REGISTER for bulk contacts - a 
> compressed form of sending unique REGISTER requests per UA.  
> GRUU is not mandatory for REGISTER of a single AoR->contact, 
> ergo it shouldn't be necessary for REGISTER of multiple 
> AoR->contacts.  We're specifying a protocol, not a service 
> >>>     Whether support for routing of out-of-dialog requests 
> to a contact is required should depend on the service 
> offering of the SSP. For example, SSP support for an 
> out-of-dialog REFER to a contact URI shouldn't be considered 
> mandatory as discussed previously. As such, I think the text 
> proposed should be conditional based on whether such services 
> are supported by the SSP across it's interfaces.
> >>
> >>> "Some services may require that entities, outside the SIP 
> PBX, be able to send out-of-dialog requests to a UA behind a 
> SIP-PBX, using a globally routable contact URI. If an SSP 
> supports such services across the SSP interfaces, the 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. In such 
> a case the lifetime of the mapping may depend on the services 
> supported by the SSP)."
> >>>
> >>>
> >>>
> >>>     Regards
> >>>         Brian
> >>>
> >>> Martien has privately indicated to me a certain lack of 
> clarity in the proposed text. In thinking about this again, I 
> haven't got the wording quite right. The bulk registration 
> mechanism doesn't register UAs behind the PBX - it registers 
> contacts for each of the AORs assigned to the PBX. What we 
> are concerned about here is contact URIs for UAs behind the 
> PBX. Those UAs register with the PBX, they do not register 
> using the bulk registration mechanism. So my revised words 
> would be as follows (only the first sentence has changed):
> >>>
> >>> "An SSP needs to provide a means of assigning a globally 
> routable contact URI to a UA behind a SIP-PBX, thereby 
> 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

---

From: Brian Lindsay <[email-masked]>
Date: Tue, 28 Sep 2010 21:07:33 +0000

Hi John,

   For the attended transfer example you point out, depending on how the SSP chooses to implement transfer, you might never see an actual out-of-dialog INVITE targeted to the SIP PBX UA contact (e.g. the baseline SIP Connect 1.1 mechanism for example would use 3PCC). How the SSP implements services and interacts with 3rd party entities shouldn't be of concern to the GIN draft.

   It seems like the attempt is to mandate broader behavior on the SSP than is required to support the actual GIN mechanism.  

   Thanks
       Brian   

-----Original Message-----
From: Elwell, John [mailto:[email-masked]] 
Sent: Tuesday, September 28, 2010 3:51 PM
To: Brian Lindsay; Paul Kyzivat; Hadriel Kaplan
Cc: [email-masked]
Subject: RE: [martini] New text for gin section 7.1.1 first paragraph

Brian,

John

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 28 Sep 2010 17:23:49 -0400

I agree that's the theory, but in practice it rarely happens that way afaict.  The cases of REFER and INVITE w/Replaces that I see in the wild cross right back through the same B2BUAs, and those B2BUAs gave contact URIs they could "undo" or "fix" - even if they weren't "global" URIs in the sense that they couldn't be used from anywhere on the Internet.  SBC's have had the ability to create real "global contacts" for years, but it's still the exception vs. the norm.

For example, suppose your Enterprise has a VPN to its SSP; a call coming in to you will have a contact URI of an SBC or whatever in that VPN - the address of that URI is useless outside the VPN.  You can refer any party to that URI, so long as that party sends its INVITE through that VPN.  One would think that would be pretty limiting, but it's not in practice.  In practice, you're either referring another phone in your enterprise, which will use the VPN (through your PBX), or in some cases you'll send the REFER to a party outside your Enterprise, but even then you'd frequently send it through your service provider and thus through the same SBC and it will fix it to be the original.  Or more likely your PBX will "process" the REFER and bridge the two calls itself to begin with, without anyone being the wiser.  No one needed a "globally routable URI" to make it work, generally.  There are exceptions, of course, but it's not the rule.

-hadriel
p.s. I'm really not sure there's anything to argue about - ISTM the language you currently have is completely flexible.  There is no protocol police to verify the contact URI generated by the SSP somewhere else is a globally routable URI.  If some service needs such a thing, and customers want it, the SSP will provide it.  We've provided the tools, but we can't make them use 'em.

---

From: Adam Roach <[email-masked]>
Date: Tue, 28 Sep 2010 16:59:59 -0500

On 9/28/10 12:32, Sep 28, Hadriel Kaplan wrote:
> You can look at it that way, or you can look at it a different way: all GIN is (supposed) to be doing is specifying a means to use REGISTER for bulk contacts

I don't think that's a complete description.

What MARTINI is chartered to do is "standardize a multiple-AoR 
registration mechanism for SIP", *and* (here's the important part) 
"accommodate existing SIP extensions relating to registration by 
ensuring that they are not precluded from use
in the context of multiple AoR registrations".

In other words, we need to specify a means to use REGISTER for bulk 
contacts *and* to fix anything that breaks.

I maintain that John's proposed text is important to fix something that 
has broken. The MARTINI architecture has multiplicatively increased the 
barrier to GRUU deployment.

That's broken. And we need to fix it. John's proposed text does so.

/a

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 28 Sep 2010 21:57:27 -0400

The problem I have with what Hadriel and Brian are saying is that it 
presupposes everyone is in the same walled garden.

Transfers initiated by the PBX's UAs may indeed be converted into 3pcc 
transfers. But Adam was talking about a case where a UA that is *not* on 
that PBX, and maybe not on the same SP, is initiating the transfer using 
REFER. You just broke *that* UA's transfer.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 29 Sep 2010 06:33:57 +0200

>>You can look at it that way, or you can look at it a different way: all GIN is (supposed) to be doing is >>specifying a means to use REGISTER for bulk contacts
>

Shouldn't we then also mandate the support of Outbound, to make sure it works if the PBX is behind a NAT?

Regards,

Christer

---

From: Adam Roach <[email-masked]>
Date: Tue, 28 Sep 2010 23:36:49 -0500

On 09/28/2010 11:33 PM, Christer Holmberg wrote:
>>> You can look at it that way, or you can look at it a different way: all GIN is (supposed) to be doing is>>specifying a means to use REGISTER for bulk contacts

No. Because, although that is a problem, it is not a problem that 
MARTINI has made worse.

/a

---

From: "Richard Shockey" <[email-masked]>
Date: Wed, 29 Sep 2010 10:24:08 -0400

Thank you for that .. NO mandate OUTBOUND.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Adam Roach
Sent: Wednesday, September 29, 2010 12:37 AM
To: Christer Holmberg
Cc: [email-masked]; Hadriel Kaplan
Subject: Re: [martini] New text for gin section 7.1.1 first paragraph

  On 09/28/2010 11:33 PM, Christer Holmberg wrote:
>>> You can look at it that way, or you can look at it a different way: all
GIN is (supposed) to be doing is>>specifying a means to use REGISTER for
bulk contacts

/a

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 29 Sep 2010 16:27:45 +0200

I disagree.

In my view MARTINI is not defining a real registrar behaviour. The real registrar for the URI is in the PBX. What MARTINI is defining is some substitute behaviour (that happens to use a registrar in the SSP) for normal SIP routeing in order to reach the real registrar, WITH ALL THE INFORMATION the real registrar needs to do its job. Normal SIP routing does this. MARTINI should not provide a mechanism where suddenly you have a means of opting out of doing this.

regards

Keith 

> [mailto:[email-masked]] On Behalf Of Hadriel Kaplan
> Sent: Tuesday, September 28, 2010 6:33 PM
> To: Paul Kyzivat
> Cc: [email-masked]
> >>> Yes, in thinking about this again, I haven't got the 
> wording quite 
> >>> right. The bulk registration mechanism doesn't register 
> UAs behind 
> >>> the PBX - it registers contacts for each of the AORs 
> assigned to the 
> >>> PBX. What we are concerned about here is contact URIs for 
> UAs behind 
> >>> the PBX. Those UAs register with the PBX, they do not 
> register using 
> >>> the bulk registration mechanism. So my revised words would be as 
> >>> follows (only the first sentence has changed):
> >>> 
> >>> contact URIs to UAs behind a SIP-PBX, thereby allowing other 
> >>> entities to address out-of-dialog requests to those UAs. 
> To achieve 
> >>> this, an SSP MUST support the public GRUU mechanism described in 
> >>> this section, unless the SSP has other means of providing 
> globally 
> >>>> I find this a difficult sentence to understand. Is UA 
> the SIP-PBX 
> >>>> or the UA behind the SIP-PBX. So I propose to add "behind a 
> >>>> SIP-PBX".
> >>>> 
> >>>> An SSP needs to provide a means of assigning globally routable 
> >>>> contact URIs to UAs behind a SIP-PBX ...
> >>>> 
> >>>> Regards Martien
> >>>> 
> >>>> 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)."
> >>>> 
> >>>> John

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 29 Sep 2010 16:32:58 +0200

Well I can turn the sentence round if you really wanted to: 

"An SSP needs to provide a means of assigning globally routable contact URIs to UAs that have been registered using the bulk registration mechanism specified in this document, thereby allowing other entities to address out-of-dialog requests to those UAs. If the SSP provides no 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), then an SSP MUST support the public GRUU mechanism described in this section."

means exactly the same thing, and specified as IF condition THEN xxx MUST requirement, and which is perfectly correct RFC 2119 usage.

I'm suggesting we do so, as I think the existing format is perfectly clear, apart from the people who will insist on treating it as optional no matter what it says.

Keith

> Sent: Monday, September 27, 2010 9:40 PM
> To: Adam Roach
> Cc: [email-masked]
> Now we get to confront the language police: is "... MUST ... 
> unless P ..." acceptable? (I'm pretty sure the logically 
> equivalent "... if !P then MUST ..." has to be ok.)
> 
> 	Thanks,
> 	Paul
>

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 29 Sep 2010 16:35:41 +0200

Hi,

I wasn't suggesting to mandate Outbound. It was more of a question of clarification, and I think I got an answer from Adam.

Regards,

Christer

________________________________________
From: Richard Shockey [[email-masked]]
Sent: Wednesday, September 29, 2010 5:24 PM
To: 'Adam Roach'; Christer Holmberg
Cc: [email-masked]; 'Hadriel Kaplan'
Subject: RE: [martini] New text for gin section 7.1.1 first paragraph

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

/a

---

From: Brian Lindsay <[email-masked]>
Date: Wed, 29 Sep 2010 16:52:15 +0000

Hi Paul,

  If you talking about a different Service Provider, then again perhaps 3PCC would be used between the service providers rather than out-of-dialog REFER for example.

 For a case where the UA on the same SP as the SIP PBX, then assuming transfer is a supported service, the SP may just support an in-dialog REFER as opposed to an out-of-dialog REFER. But in any case, the SP would have provided contact info in the requests/responses such that the service would work based on the service offering. That doesn't necessarily mean these contacts would have full indefinite-lifetime GRUU properties for example that are valid in any out-of-dialog request in any context.

  But again, I'm not sure how anything in this area is in scope for the GIN draft to mandate? 

  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

-----Original Message-----
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, September 28, 2010 9:57 PM
To: Hadriel Kaplan
Cc: Elwell, John; Brian Lindsay; [email-masked]
Subject: Re: [martini] New text for gin section 7.1.1 first paragraph

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 29 Sep 2010 13:32:47 -0400

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

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 29 Sep 2010 13:47:20 -0400

Nothing prevents an Enterprise from getting their own Domain name, putting it in DNS, and using rfc3263.

What Martini is doing is letting an Enterprise take responsibility for a subset of an SSP's AoRs.  It's a contractual matter between the Enterprise and SSP what the terms of that responsibility-shifting is, and what features are available.  We (the IETF) need to provide the tools to let scenarios which need GRUU-type URIs to work in this context.  We have done that.  Mandating those tools be *implemented* by the SSP is another matter entirely.  

It's like mandating the SSP support TLS at every hop if they support GIN, so that the Enterprise has the opportunity to use SIPS URIs - after all, how can the Enterprise use SIPS without the SSP doing so?  Or mandating Hist-Info be implemented by the SSP if they do GIN, because otherwise the Enterprise may not be able to support something they need Hist-Info for.

-hadriel

---

From: Brian Lindsay <[email-masked]>
Date: Wed, 29 Sep 2010 18:00:49 +0000

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 [mailto:[email-masked]] 
Sent: Wednesday, September 29, 2010 1:33 PM
To: Brian Lindsay
Cc: Paul Kyzivat; Elwell, John; [email-masked]
Subject: Re: [martini] New text for gin section 7.1.1 first paragraph

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Sep 2010 14:38:38 -0400

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.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 29 Sep 2010 20:42:09 +0200

Hi,

I DO think we MUST challenge all the SHOULDs - especially if there is no associated "unless" part.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]
Sent: Wednesday, September 29, 2010 9:38 PM
To: Brian Lindsay
Cc: [email-masked]; Hadriel Kaplan
Subject: Re: [martini] New text for gin section 7.1.1 first paragraph

        Thanks,
        Paul

---

From: Brian Lindsay <[email-masked]>
Date: Wed, 29 Sep 2010 19:00:14 +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.

  Thanks
     Brian

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

	Thanks,
	Paul

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 29 Sep 2010 15:30:01 -0400

> ??? The users can negotiate with their SSP over which ones are supported.

Because most of them impact interoperability for GIN itself? 

We can think getting a GRUU is a basic capability, but existence proof says otherwise.  Unless wireshark is hiding all the GRUU parameters. ;)

Unless I misunderstand the intention, to me a "globally routable URI" means the URI is generally resolvable/usable from anywhere on the Internet.  How many SSPs do you know accept requests from everything on the Internet, or route them using domain names and public DNS?  Not many, in the grand scheme of things.

If an enterprise like Acme uses GIN with SSP-X and Cisco uses GIN with SSP-Y, do you think Cisco can use a URI like "sip:[email-masked];gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;sg=00:05:03:5e:70:a6" if it got one from Acme somehow?  SSP-X won't accept any requests from Cisco, and SSP-Y won't be able to route that URI.  Does that mean SSP-X and SSP-Y can't do GIN??

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Wed, 29 Sep 2010 14:48:32 -0500

On 09/29/2010 02:30 PM, Hadriel Kaplan wrote:
> If an enterprise like Acme uses GIN with SSP-X and Cisco uses GIN with 
> SSP-Y, do you think Cisco can use a URI like 
> "sip:[email-masked];gr=urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6;sg=00:05:03:5e:70:a6" 
> if it got one from Acme somehow? [...]SSP-Y won't be able to route 
> that URI.

Why not?

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Wed, 29 Sep 2010 16:52:44 -0400

>> if it got one from Acme somehow? [...]SSP-Y won't be able to route 

Because (1) SSP-Y would have to be willing to route sip requests across the Internet, (2) SSP-Y's sip systems would have to use the public DNS, (3) SSP-X's systems would have to be in the public DNS, (4) SSP-X would have to be willing to accept requests from SSP-Y, (5) SSP-Y would have to not replace the request-uri as it does the routing to SSP-X.  Odds of all of those things being the case: very low.

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Wed, 29 Sep 2010 19:02:51 -0500

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

Primarily around the interoperability of the GIN registration 
mechanisms, *and* any problems that the MARTINI architecture has caused 
or exacerbated.

The second class of things is as important as the first.

>    I don't think GRUU falls into that category.

You're right that it doesn't fall into the first category. It *does*, 
however, fall into the second category.

/a

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 30 Sep 2010 14:20:09 +0200

NO.

There is no point in GIN if it cannot support a real registrar in the PBX. It may be perfectly interoperable across the interface, but if information gets removed as a result of the process that normal operation of the registrar in the PBX needs, then there is no point in the interface existing either.

Keith

> Sent: Wednesday, September 29, 2010 8:00 PM
> To: Paul Kyzivat
>   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.
> 
>   Thanks
>      Brian
> 
> 
> 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.
> 
> 	Thanks,
> 	Paul
> 
> >     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
> >
> >
> > 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
> >
> >>   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
> >
> >