Re: [sipcore] 4244bis-05: the infamous "rc" param

Hadriel Kaplan <HKaplan@acmepacket.com> Fri, 17 June 2011 16:07 UTC

Return-Path: <HKaplan@acmepacket.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94A1111E813B for <sipcore@ietfa.amsl.com>; Fri, 17 Jun 2011 09:07:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.541
X-Spam-Level:
X-Spam-Status: No, score=-2.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JLkOGHWooMim for <sipcore@ietfa.amsl.com>; Fri, 17 Jun 2011 09:07:25 -0700 (PDT)
Received: from ETMail2.acmepacket.com (etmail2.acmepacket.com [216.41.24.9]) by ietfa.amsl.com (Postfix) with ESMTP id 66A7911E80DB for <sipcore@ietf.org>; Fri, 17 Jun 2011 09:07:25 -0700 (PDT)
Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Fri, 17 Jun 2011 12:07:23 -0400
Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Fri, 17 Jun 2011 12:07:23 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Shida Schubert <shida@ntt-at.com>
Date: Fri, 17 Jun 2011 12:07:22 -0400
Thread-Topic: [sipcore] 4244bis-05: the infamous "rc" param
Thread-Index: AcwtCKR5V/loV58AR7+qFsLYCHw+MQ==
Message-ID: <88801004-2367-4BE3-8564-3228A279B9E1@acmepacket.com>
References: <7A463F33-4115-4E9D-8D1C-C8F49BA9CFDD@acmepacket.com> <7E5B50A1-81D0-433A-BAEF-F7B9037F4691@ntt-at.com>
In-Reply-To: <7E5B50A1-81D0-433A-BAEF-F7B9037F4691@ntt-at.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAgAAAUAAAAFS
Cc: "sipcore@ietf.org WG" <sipcore@ietf.org>
Subject: Re: [sipcore] 4244bis-05: the infamous "rc" param
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jun 2011 16:07:26 -0000

I was one of the ones arguing for reducing/removing the other tags as "fluff", but that included removing the "rc" tag.  That was because, at the time there was an "aor" tag - the "aor" and "mp" tags were the only ones actually used by receiving UAS applications, so the other tags just add confusion.  

Now there is no "aor" tag, because it's incredibly difficult for a system to know when a URI is an "Address of Record".  But having the "rc" tag doesn't solve the problem - it just moves it around. Now you're just *implying* the entry before the "rc" tagged one is an AoR, which is just as error prone as before.

It's error-prone because:
1) It will have false-positives - cases where the entry prior to the "rc" tagged one is not the one the application actually wants.
2) It will have false-negatives - cases where there is no "rc" tag because the UAS did not use Registration model to receive a request, or the intermediate proxy/ies did not know that it was due to a registration.

My point is that the real purpose of using History-Info and having these tags is to enable applications on the UAS.  Some of those applications need to find target URIs that were changed along the way.  *Why* they were changed matters, but not *how* they were changed.  Whether it was due to a SIP-Registration database, ENUM database, LDAP lookup, or reading tea leaves doesn't matter.

What "rc" should actually stand for is "Request-uri Changed".  It should be populated in ALL cases where the request-URI is changed, but where the new target is still the same identity (ie, it's not an "mp" tag instead), and it should still use an index to point to the previous H-I entry it changed from as it does now.

-hadriel


On Jun 16, 2011, at 3:41 AM, Shida Schubert wrote:

> I don't recall exactly why we decided to limit the scope of "rc". 
> 
> I vaguely remember the debate on allowing "rc" to be used for resolution 
> beside the current intended context, resulting in convoluting the 
> tag and overloading it making it indeterministic. I think it was about non-REGISTER 
> could raise the question of "How do you know that it was for AoR-to-Contact resolution?". 
> 
> For example when barnes-sipcore-rfc4244bis-02 has 4 tags of which 
> "cc" covers the cases you expressed the concerns for, but I can't recall 
> the exact reason why we limited the scope. 
> 
> 	"rc": The entry is a contact that is bound to an AOR in an
>         abstract location service.  The AOR-to-contact binding has been
>         placed into the location service by a SIP Registrar that
>         received a SIP REGISTER request.
> 
>      *  "cc": The entry is a contact that is bound to an AOR in an
>         abstract location service.  The AOR-to-contact binding has been
>         placed into the location service implicitly through a means
>         other than a SIP Registrar acting on a REGISTER request, e.g.,
>         the user may be currently logged into a Web Portal that
>         implements a Presence and IM service, or it could be manually
>         configured.
> 
>      *  "mp": The entry is a URI that represents another user.  This
>         occurs in cases where a request is statically or dynamically
>         retargeted to another user.
> 
>      *  "rt": The entry is "routed", i.e., it is either a no-op like a
>         proxy forwarding, predetermined by a maddr in the Request-URI,
>         or the Request-URI is changed to a new URI that represents the
>         same user, and is not a contact in a SIP Registrar.
> 
> By the time it was revised to 03 the tag was reduced to the two we 
> currently have. So there was a conclusion made sometime between the 
> 02 and 03. 
> 
>  I personally don't have a strong opinions on this and would be happy to change 
> the definition of the "rc" tag but I wasn't the one who raised the concerns, so I think 
> we need to find those that lead us to the current status on this issue.. 
> 
> Regards
>  Shida
> 
> On Jun 16, 2011, at 4:52 AM, Hadriel Kaplan wrote:
> 
>> Howdy,
>> I still have concerns regarding the "rc" param in this draft.  Right now, the "rc" is only added for request-uri retargeting due to AoR-to-contact resolution, populated by a SIP Registrar from a REGISTER.  That's it.  So "rc" is not added due to static/provisioned Aor-to-contact mappings, for example.  Nor is it added due to ENUM resolution.  Nor, apparently, if the Proxy doing the routing doesn't know how the database's entry was populated.
>> 
>> So... why does it matter how the abstract location database got populated?   Example applications in this draft, as well as in rfc4244bis-callflows, apparently rely on the existence of an "rc" param to perform their logic.  Afaict, however, it's NOT the case that they actually care whether it was due to a REGISTER or not.  They only care about finding the first or last relevant URI they understand.
>> 
>> For example: in a sip trunking context, a la Martini-GIN, request routing to GIN-PBX bulk-registered contacts would get the "rc".  But request routing to PBX's UAs using 3263 or static provisioning would not.  Should the application service logic or behavior be different for these different ways of deploying SIP trunks?
>> 
>> -hadriel
>> 
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>