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

Paul Kyzivat <pkyzivat@cisco.com> Wed, 29 September 2010 01:56 UTC

Return-Path: <pkyzivat@cisco.com>
X-Original-To: martini@core3.amsl.com
Delivered-To: martini@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9E7983A6BBD for <martini@core3.amsl.com>; Tue, 28 Sep 2010 18:56:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.491
X-Spam-Level:
X-Spam-Status: No, score=-110.491 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BWNvgkj15CcI for <martini@core3.amsl.com>; Tue, 28 Sep 2010 18:56:46 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B958B3A6BCC for <martini@ietf.org>; Tue, 28 Sep 2010 18:56:46 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAF05okxAZnwN/2dsb2JhbACiHHGwdpx8hUQEijqCfw
X-IronPort-AV: E=Sophos;i="4.57,250,1283731200"; d="scan'208";a="164803506"
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 29 Sep 2010 01:57:28 +0000
Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o8T1vSij020016; Wed, 29 Sep 2010 01:57:28 GMT
Message-ID: <4CA29D07.3020203@cisco.com>
Date: Tue, 28 Sep 2010 21:57:27 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.9) Gecko/20100825 Thunderbird/3.1.3
MIME-Version: 1.0
To: Hadriel Kaplan <HKaplan@acmepacket.com>
References: <A444A0F8084434499206E78C106220CA01C81C2B32@MCHP058A.global-ad.net> <B1771F0F1F97A8478E2F449EA19CC7C5DA1A7EB3@ESESSCMS0365.eemea.ericsson.se> <A444A0F8084434499206E78C106220CA01C81C2D93@MCHP058A.global-ad.net> <F1A0ED6425368141998E077AC43334E425B8D6F6@gbplmail02.genband.com> <4CA21DF2.5080709@cisco.com> <DD8DA2BD-997C-420F-965F-98D9EEC7C6E9@acmepacket.com> <4CA23086.8010404@cisco.com> <F1A0ED6425368141998E077AC43334E425B8D7D5@gbplmail02.genband.com> <A444A0F8084434499206E78C106220CA01C829452C@MCHP058A.global-ad.net> <D32EE33B-4599-4DA0-96D4-A7054325C20C@acmepacket.com>
In-Reply-To: <D32EE33B-4599-4DA0-96D4-A7054325C20C@acmepacket.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "martini@ietf.org" <martini@ietf.org>
Subject: Re: [martini] New text for gin section 7.1.1 first paragraph
X-BeenThere: martini@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of en-mass SIP PBX registration mechanisms <martini.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/martini>
List-Post: <mailto:martini@ietf.org>
List-Help: <mailto:martini-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/martini>, <mailto:martini-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 29 Sep 2010 01:56:49 -0000

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