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

Hadriel Kaplan <> Tue, 28 September 2010 21:23 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2B1F53A6CF3 for <>; Tue, 28 Sep 2010 14:23:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.477
X-Spam-Status: No, score=-2.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xqdsEo+zuJrE for <>; Tue, 28 Sep 2010 14:23:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 993853A6CAD for <>; Tue, 28 Sep 2010 14:23:30 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Tue, 28 Sep 2010 17:24:12 -0400
Received: from ([]) by mail ([]) with mapi; Tue, 28 Sep 2010 17:23:50 -0400
From: Hadriel Kaplan <>
To: "Elwell, John" <>
Date: Tue, 28 Sep 2010 17:23:49 -0400
Thread-Topic: [martini] New text for gin section 7.1.1 first paragraph
Thread-Index: ActfU3Fu9EFmw6Q5Qci29X6lkyy4+Q==
Message-ID: <>
References: <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [martini] New text for gin section 7.1.1 first paragraph
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discussion of en-mass SIP PBX registration mechanisms <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 28 Sep 2010 21:23:32 -0000

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.

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