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

[Hadriel Kaplan <[e-mail]>]

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.



On Sep 28, 2010, at 3:51 PM, Elwell, John wrote:

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