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

[Brian Lindsay <[e-mail]>]

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:[e-mail]] 
Sent: Tuesday, September 28, 2010 9:57 PM
To: Hadriel Kaplan
Cc: Elwell, John; Brian Lindsay; [e-mail]
Subject: Re: [martini] New text for gin section 7.1.1 first paragraph

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

On 9/28/2010 5:23 PM, Hadriel Kaplan wrote:
>
> 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
>>
>
>