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

Hadriel Kaplan <HKaplan@acmepacket.com> Wed, 15 June 2011 19:52 UTC

Return-Path: <HKaplan@acmepacket.com>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0229211E8146 for <sipcore@ietfa.amsl.com>; Wed, 15 Jun 2011 12:52:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.531
X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id nNKMrbpWouX1 for <sipcore@ietfa.amsl.com>; Wed, 15 Jun 2011 12:52:23 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com []) by ietfa.amsl.com (Postfix) with ESMTP id 6C80011E810D for <sipcore@ietf.org>; Wed, 15 Jun 2011 12:52:23 -0700 (PDT)
Received: from mail.acmepacket.com ( by etmail.acmepacket.com ( with Microsoft SMTP Server (TLS) id; Wed, 15 Jun 2011 15:52:22 -0400
Received: from mailbox1.acmepacket.com ([]) by mail ([]) with mapi; Wed, 15 Jun 2011 15:52:22 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: "sipcore@ietf.org WG" <sipcore@ietf.org>
Date: Wed, 15 Jun 2011 15:52:21 -0400
Thread-Topic: 4244bis-05: the infamous "rc" param
Thread-Index: Acwrlb3AJW9ERtTMRXGy37W4MVjcRg==
Message-ID: <7A463F33-4115-4E9D-8D1C-C8F49BA9CFDD@acmepacket.com>
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
X-Brightmail-Tracker: AAAAAgAAAUAAAAFV
Cc: "draft-ietf-sipcore-rfc4244bis@tools.ietf.org" <draft-ietf-sipcore-rfc4244bis@tools.ietf.org>
Subject: [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: Wed, 15 Jun 2011 19:52:24 -0000

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?