[sipcore] draft-mohali-sipcore-reason-extension-application-00

Paul Kyzivat <pkyzivat@cisco.com> Thu, 04 November 2010 18:00 UTC

Return-Path: <pkyzivat@cisco.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id CD7463A6A1E for <sipcore@core3.amsl.com>; Thu, 4 Nov 2010 11:00:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.449
X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id kx3cdhBbnADV for <sipcore@core3.amsl.com>; Thu, 4 Nov 2010 11:00:21 -0700 (PDT)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com []) by core3.amsl.com (Postfix) with ESMTP id F02AC3A69C2 for <sipcore@ietf.org>; Thu, 4 Nov 2010 11:00:20 -0700 (PDT)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAEOR0kxAZnwM/2dsb2JhbAChfHGiZZtDgnGCVQSKVYMI
X-IronPort-AV: E=Sophos;i="4.58,297,1286150400"; d="scan'208";a="178660706"
Received: from rtp-core-1.cisco.com ([]) by rtp-iport-2.cisco.com with ESMTP; 04 Nov 2010 18:00:31 +0000
Received: from [] (bxb-vpn3-443.cisco.com []) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oA4I0U51012904 for <sipcore@ietf.org>; Thu, 4 Nov 2010 18:00:31 GMT
Message-ID: <4CD2F4BE.6080906@cisco.com>
Date: Thu, 04 Nov 2010 14:00:30 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20101013 Thunderbird/3.1.5
MIME-Version: 1.0
To: SIPCORE <sipcore@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: [sipcore] draft-mohali-sipcore-reason-extension-application-00
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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: Thu, 04 Nov 2010 18:00:21 -0000

[as individual]

I took another look at this draft, and have a few observations/comments:

Its claimed that in cases where retargeting is due to a 3xx response, 
then the reason is 3xx, while in the cases of interest in this draft the 
reason is one of the new application reason codes.

But these are not mutually exclusive cases. All of the "application" 
cases called out could be implemented by sending the request to an 
application server that then returns a 3xx response with the value. If 
so, anything downstream that wishes to identify the reason would 
presumably want the application reason, which would perhaps have been 
lost in this process.

ISTM that to resolve that, the redirect server would affix the reason 
header with the application code to the contact in the 3xx. Then, the 
proxy that recurses on the 3xx would place contact with the embedded 
reason header into the H-I, and would also place the reason header into 
the new outgoing request.

A net effect of this is that the Reason header would be in the *new* URI 
in H-I, not in the *old* URI as is shown. To me that also makes more 
sense - its the reason this URI is present.

Bottom line - this should all make sense even without the use of H-I. 
Then H-I usage can also be folded into the examples to give an even more 
complete picture of what happened.

I also must say that I find the proposed cause text to be at best 
awkward. I'm not a grammarian, but ISTM that these terms are using the 
wrong part of speech - they don't sound like *causes*. And for that 
matter some of them don't sound like they are even related to 
retargeting. E.g. premium rate, vpn. I would expect that "The call was 
retargeted to number <number> because <cause>" would make sense for each 
of these.