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

"Worley, Dale R (Dale)" <> Fri, 17 June 2011 20:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 96CEB9E8030 for <>; Fri, 17 Jun 2011 13:02:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -103.405
X-Spam-Status: No, score=-103.405 tagged_above=-999 required=5 tests=[AWL=0.194, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wmT+EelDu0SG for <>; Fri, 17 Jun 2011 13:02:57 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A5D4E9E8035 for <>; Fri, 17 Jun 2011 13:02:57 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EADWx+02HCzI1/2dsb2JhbABFDaZSd4hzpAUCmyMCgxmDDASWWosd
X-IronPort-AV: E=Sophos;i="4.65,382,1304308800"; d="scan'208";a="285653717"
Received: from unknown (HELO ([]) by with ESMTP; 17 Jun 2011 16:02:56 -0400
X-IronPort-AV: E=Sophos;i="4.65,382,1304308800"; d="scan'208";a="667611029"
Received: from (HELO ([]) by with ESMTP; 17 Jun 2011 16:02:56 -0400
Received: from ([]) by ([::1]) with mapi; Fri, 17 Jun 2011 16:02:55 -0400
From: "Worley, Dale R (Dale)" <>
To: Hadriel Kaplan <>, Shida Schubert <>
Date: Fri, 17 Jun 2011 16:02:56 -0400
Thread-Topic: [sipcore] 4244bis-05: the infamous "rc" param
Thread-Index: AcwtCKR5V/loV58AR7+qFsLYCHw+MQAH0Kgv
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: " WG" <>
Subject: Re: [sipcore] 4244bis-05: the infamous "rc" param
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 17 Jun 2011 20:02:58 -0000

> From: Hadriel Kaplan []
> 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.

I'm not so concerned about the different categories of redirection and how we record them,
but that there will be some redirections to which neither "rc" nor "mp" will apply.
In those cases, there is no way to record which URI this URI is derived from, because the
back-pointer is the value of rc/mp.

And it doesn't look like the draft thinks about that case much.  There three examples that
I can find where a URI is not the same as its parent but does not have an rc/mp parameter:

Messages F6 and F9 in B.1 and one message in B.2:

   F6 INVITE -> office


   History-Info: <>;index=1
   History-Info: <sip:bob@>;\
   History-Info: <>;index=1.2;mp=1
   History-Info: <sip:office@>;index=1.2.1 <------------------

   F9 INVITE -> home

   INVITE sip:home@ SIP/2.0

   History-Info: <>;index=1
   History-Info: <sip:bob@>;\
   History-Info: <>;index=1.2;mp=1
   History-Info: <sip:office@>;\
   History-Info: <>;index=1.3;mp=1
   History-Info: <sip:home@>;index=1.3.1 <----------------------

  |                |   INVITE;p=x
  |                |--------------->|                |
  | History-Info: <sip:anonymous@anonymous.invalid>;index=1
  | History-Info: <;p=x>;index=1.1

[Though the last one was due to anonymization.]

I think we need to adjust the parameters to put the back-pointer into a separate
parameter from the "type of redirection" information.