Re: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-02:"Reason"placement
OKUMURA Shinji <shinji.okumura@softfront.jp> Wed, 27 February 2013 08:22 UTC
Return-Path: <shinji.okumura@softfront.jp>
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 E456821F85B2 for <sipcore@ietfa.amsl.com>; Wed, 27 Feb 2013 00:22:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -97.868
X-Spam-Level:
X-Spam-Status: No, score=-97.868 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, 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 o8pAQwcpjDLF for <sipcore@ietfa.amsl.com>; Wed, 27 Feb 2013 00:22:55 -0800 (PST)
Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by ietfa.amsl.com (Postfix) with ESMTP id 7345621F85AC for <sipcore@ietf.org>; Wed, 27 Feb 2013 00:22:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at softfront.co.jp
Received: from softfront.jp (sf-pc-111.softfront.local [172.16.25.90]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 49A38428035; Wed, 27 Feb 2013 17:22:47 +0900 (JST)
From: OKUMURA Shinji <shinji.okumura@softfront.jp>
To: sipcore@ietf.org
Date: Wed, 27 Feb 2013 17:22:45 +0900
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: HidemaruMail 6.01 (WinNT,601)
In-Reply-To: <201302270322.r1R3M1QA2696992@shell01.TheWorld.com>
References: <201302202049.r1KKniGa2212191@shell01.TheWorld.com> <A5CE133F48C4CAshinji.okumura@softfront.jp> <201302270322.r1R3M1QA2696992@shell01.TheWorld.com>
Message-Id: <D9CE14C39E8E16shinji.okumura@softfront.jp>
Cc: "Dale R. Worley" <worley@ariadne.com>
Subject: Re: [sipcore] draft-ietf-sipcore-rfc4244bis-callflows-02:"Reason"placement
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, 27 Feb 2013 08:22:56 -0000
Hi, Dale. Thank you for your response, my comments inline. worley@ariadne.com (Dale R. Worley) Tue, 26 Feb 2013 22:22:01 -0500 (EST) >> From: OKUMURA Shinji <shinji.okumura@softfront.jp> > >[choosing one examle from several:] >> > 3.1. Sequentially Forking (History-Info in Response) >> > >> > 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;rc=1.2 > >> draft-ietf-sipcore-rfc4244bis-11 >> 10.2. Reason in the History-Info Header Field >> >> If the Reason header field is being added due to >> receipt of an explicit SIP response and the response contains any >> Reason header fields (see [RFC3326]), then the SIP entity MUST >> include the Reason header fields in the "headers" component of the >> hi-targeted-to-uri in the last hi-entry added to the cache, unless >> the hi-targeted-to-uri is a Tel-URI. If the SIP response does not >> contain a Reason header field, the SIP entity MUST include a Reason >> header field, containing the SIP Response Code, in the "headers" >> component of the hi-targeted-to-uri in the last hi-entry added to the >> cache, unless the hi-targeted-to-uri is a Tel-URI. >> >> according to this descriptions, SIP entity MUST include a Reason header >> "in the last hi-entry added to the cache". >> IIUC, it means "next hop" index=1.2.1. > >Looking at the matter more closely, it is rather complex: > >The text says "the last hi-entry added to the cache". I believe that >it means "the hi-entry that was most recently added to the cache". > >The processing described is in section 10.2. The only location where >10.2 is referenced is in Step 2 of section 9.3. Section 9.3 begins: > > 9.3. Receiving a Response with History-Info or Request Timeouts > > When a SIP entity receives a non-100 response or a request times out, > the SIP entity performs the following steps: > > Step 1: Add hi-entry to cache > > The SIP entity MUST add the hi-entry that was added to the request > that received the non-100 response or timed out to the cache, if > it was not already cached. The hi-entry MUST be added to the > cache in ascending order as indicated by the values in the hi- > index parameters of the hi-entries (e.g., 1.2.1 comes after 1.2 > but before 1.2.2 or 1.3). > > Step 2: Add Reason header field > > The SIP entity adds one or more Reason header fields to the hi- > targeted-to-uri in the (newly) cached hi-entry reflecting the SIP > response code in the non-100 response, per the procedures of > Section 10.2. > >As you can see, the point where section 10.2 is invoked is in Step 2, >and at that point the hi-entry that was most recently added to the >cache is the hi-entry specified in Step 1, namely, "the hi-entry that >was added to the request that received the ... response". (hi-entries >taken from the response itself are added to the cache later, in Step >3.) At a time when the SIP entity adds one or more Reason header fields, "the index of the last hi-entry added to the cache" is 1.2.1, isn't it? >In this case, I believe there is a problem with the wording: Step 1 >does nothing because the specified hi-entry is already in the cache >due to reception of response F7 (in the callflow 3.1), and so the >specified hi-entry is not "added to the cache", but I believe it is >intended to be the hi-entry upon which Step 2 and section 10.2 >operate. aha! At proxy.example.com, when to the cache ------------------------------------------------- receiving INVITE(F1) add index=1 sending INVITE(F2) add index=1.1 receiving 302(F4) include a Reason in index=1.1(last at the time) sending INVITE(F6) add index=1.2 add index=1.2.1 receiving 180(F7) add nothig. but it is terrible, if 180 has index=1.2.1.x... time out(--) include a Reason in index=1.2.1(last at the time) therefore, the SIP entity MUST include a Reason header field in the last hi-entry "created by itself". >Within that understanding, it seems to me that the Reason value should >be added to hi-entry 1.2.1, because that is the hi-entry that >corresponds to the INVITE that was sent from proxy "example.com" to >Office. I think so too. >There is additional complexity because this is a case of "internal >retargeting": It is as if the proxy sent "INVITE >sip:office@example.com" (index 1.2) to another proxy, which sent >"INVITE sip:office@192.0.2.5" (index 1.2.1). > >Clearly (?), "example.com" should apply "Reason=...408..." to hi-entry >1.2.1, because that corresponds to the request that timed out. > >But it seems to me that "example.com", in its role as the upstream >proxy which internally receives the 408 response from itself in its >role as the downstream proxy, should apply "Reason=...408..." to >hi-entry 1.2 as well. (If the two proxies were separated, that is >what would happen.) it seems fine that both hi-entries(1.2 and 1.2.1) have a Reason header. The last one MUST include it, another one "should" do it. Regards, Shinji.
- [sipcore] draft-ietf-sipcore-rfc4244bis-callflows… Dale R. Worley
- Re: [sipcore] draft-ietf-sipcore-rfc4244bis-callf… OKUMURA Shinji
- Re: [sipcore] draft-ietf-sipcore-rfc4244bis-callf… Dale R. Worley
- Re: [sipcore] draft-ietf-sipcore-rfc4244bis-callf… OKUMURA Shinji