Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case?

"Worley, Dale R (Dale)" <> Fri, 19 November 2010 20:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C4C0F3A68D0 for <>; Fri, 19 Nov 2010 12:13:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.476
X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id RSBLiaOL9meP for <>; Fri, 19 Nov 2010 12:13:20 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C16623A689C for <>; Fri, 19 Nov 2010 12:13:19 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAN5o5kzGmAcF/2dsb2JhbACiYXGkQgKZJYVLBIRaiSk
X-IronPort-AV: E=Sophos;i="4.59,224,1288584000"; d="scan'208";a="219434483"
Received: from unknown (HELO ([]) by with ESMTP; 19 Nov 2010 15:14:08 -0500
X-IronPort-AV: E=Sophos;i="4.59,225,1288584000"; d="scan'208";a="542835654"
Received: from unknown (HELO ([]) by with ESMTP; 19 Nov 2010 15:14:08 -0500
Received: from ([]) by ([]) with mapi; Fri, 19 Nov 2010 15:14:07 -0500
From: "Worley, Dale R (Dale)" <>
To: Paul Kyzivat <>, Mary Barnes <>
Date: Fri, 19 Nov 2010 15:11:20 -0500
Thread-Topic: [sipcore] Why doesn't 4244bis cover Marianne's use-case?
Thread-Index: AcuIHew+0kS/7W8vTce6TZxPUZQ7IQACAIl4
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: "" <>
Subject: Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 Nov 2010 20:13:20 -0000

From: [] On Behalf Of Paul Kyzivat []

(I know I'm being legalistic here, but sometimes its necessary.)


- reword 4244bis so that a Reason header MAY be included (with suitable
   conditions - TBD) even if not received in a response, to cover
   Marianne's cases. (But this takes 4244bis beyond the scope it was
   intended to cover.)

Certainly in this situation, we'd better be legalistic, because there are so many ways that it could turn into a mess.

I prefer adding a suitable clause to 4244bis to allow the proxy to insert a Reason header for a URI that is redirected, as this is the clean way to handle the situation.  (The alternative is to synthesize an entry showing that the request was sent to a virtual redirection server, but that would make the H-I even longer.)  This is another aspect of the problem of documenting what the rules are for a consistent H-I header.