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

Shida Schubert <shida@ntt-at.com> Thu, 16 June 2011 07:41 UTC

Return-Path: <shida@ntt-at.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 6614A11E80B5 for <sipcore@ietfa.amsl.com>; Thu, 16 Jun 2011 00:41:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.265
X-Spam-Level:
X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, USER_IN_WHITELIST=-100]
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 Wc8wPXediZtt for <sipcore@ietfa.amsl.com>; Thu, 16 Jun 2011 00:41:37 -0700 (PDT)
Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id D9D2111E8078 for <sipcore@ietf.org>; Thu, 16 Jun 2011 00:41:37 -0700 (PDT)
Received: from [125.192.75.244] (port=54174 helo=[192.168.1.3]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <shida@ntt-at.com>) id 1QX7Co-0004HP-6p; Thu, 16 Jun 2011 02:41:34 -0500
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Shida Schubert <shida@ntt-at.com>
In-Reply-To: <7A463F33-4115-4E9D-8D1C-C8F49BA9CFDD@acmepacket.com>
Date: Thu, 16 Jun 2011 16:41:31 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <7E5B50A1-81D0-433A-BAEF-F7B9037F4691@ntt-at.com>
References: <7A463F33-4115-4E9D-8D1C-C8F49BA9CFDD@acmepacket.com>
To: Hadriel Kaplan <HKaplan@acmepacket.com>
X-Mailer: Apple Mail (2.1084)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator465.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ntt-at.com
X-BWhitelist: no
X-Source:
X-Source-Args:
X-Source-Dir:
X-Source-Sender: flh1agj244.tky.mesh.ad.jp ([192.168.1.3]) [125.192.75.244]:54174
X-Source-Auth: shida@agnada.com
X-Email-Count: 1
X-Source-Cap: c3NoaWRhO3NzaGlkYTtnYXRvcjQ2NS5ob3N0Z2F0b3IuY29t
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: Thu, 16 Jun 2011 07:41:38 -0000

 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