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

Shida Schubert <shida@ntt-at.com> Fri, 24 June 2011 12:40 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 66F2311E809B for <sipcore@ietfa.amsl.com>; Fri, 24 Jun 2011 05:40:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.134
X-Spam-Level:
X-Spam-Status: No, score=-102.134 tagged_above=-999 required=5 tests=[AWL=0.131, 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 CW6GBqnwkGNa for <sipcore@ietfa.amsl.com>; Fri, 24 Jun 2011 05:40:12 -0700 (PDT)
Received: from gator465.hostgator.com (gator465.hostgator.com [69.56.174.130]) by ietfa.amsl.com (Postfix) with ESMTP id DBAA111E80BB for <sipcore@ietf.org>; Fri, 24 Jun 2011 05:40:12 -0700 (PDT)
Received: from flh1agj244.tky.mesh.ad.jp ([125.192.75.244]:49761 helo=[192.168.11.3]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <shida@ntt-at.com>) id 1Qa5Ji-00015b-DP; Fri, 24 Jun 2011 07:16:58 -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: <CD5674C3CD99574EBA7432465FC13C1B222907EA00@DC-US1MBEX4.global.avaya.com>
Date: Fri, 24 Jun 2011 21:16:58 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <1F3F1D50-C925-424D-B505-64515173A976@ntt-at.com>
References: <7A463F33-4115-4E9D-8D1C-C8F49BA9CFDD@acmepacket.com> <7E5B50A1-81D0-433A-BAEF-F7B9037F4691@ntt-at.com>, <88801004-2367-4BE3-8564-3228A279B9E1@acmepacket.com> <CD5674C3CD99574EBA7432465FC13C1B222907EA00@DC-US1MBEX4.global.avaya.com>
To: "Worley, Dale R (Dale)" <dworley@avaya.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.11.3]) [125.192.75.244]:49761
X-Source-Auth: shida@agnada.com
X-Email-Count: 33
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: Fri, 24 Jun 2011 12:40:13 -0000

 I believe Hadriel's suggestion of adding the "rc" tag 
whenever R-URI is changed. 

 I think it might have been overlooking the message as 
I think the 2 former entries you pointed out obviously is a 
contact address, which should have had the "rc" parameters. 

 But again as it currently limits the use only when the address 
is registered via REGISTER, this could easily happen in 
the deployment. 

 Regards
  Shida

On Jun 18, 2011, at 5:02 AM, Worley, Dale R (Dale) wrote:

>> From: Hadriel Kaplan [HKaplan@acmepacket.com]
>> 
>> 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 example.com -> office
> 
>   INVITE sip:office@192.0.2.3.com SIP/2.0
> 
>   History-Info: <sip:bob@example.com>;index=1
>   History-Info: <sip:bob@192.0.2.4?Reason=SIP%3Bcause%3D302>;\
>                 index=1.1;rc=1
>   History-Info: <sip:office@example.com>;index=1.2;mp=1
>   History-Info: <sip:office@192.0.2.5>;index=1.2.1 <------------------
> 
> 
> 
>   F9 INVITE example.com -> home
> 
>   INVITE sip:home@192.0.2.6 SIP/2.0
> 
>   History-Info: <sip:bob@example.com>;index=1
>   History-Info: <sip:bob@192.0.2.4?Reason=SIP%3Bcause%3D302>;\
>                 index=1.1;rc=1
>   History-Info: <sip:office@example.com>;index=1.2;mp=1
>   History-Info: <sip:office@192.0.2.5?Reason=SIP%3Bcause%3D408>;\
>                 index=1.2.1>;index=1.2.1
>   History-Info: <sip:home@example.com>;index=1.3;mp=1
>   History-Info: <sip:home@192.0.2.6>;index=1.3.1 <----------------------
> 
> 
>  |                |   INVITE sip:bob@biloxi.example.com;p=x
>  |                |--------------->|                |
>  | History-Info: <sip:anonymous@anonymous.invalid>;index=1
>  | History-Info: <sip:bob@biloxi.example.com;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.
> 
> Dale
>