Re: [sipcore] Reason as a parameter rather than an escaped header

Paul Kyzivat <pkyzivat@cisco.com> Mon, 29 November 2010 02:19 UTC

Return-Path: <pkyzivat@cisco.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D4FEB3A6BE0 for <sipcore@core3.amsl.com>; Sun, 28 Nov 2010 18:19:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.487
X-Spam-Level:
X-Spam-Status: No, score=-110.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dPcALmRIW05W for <sipcore@core3.amsl.com>; Sun, 28 Nov 2010 18:19:23 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C11EE3A6BA3 for <sipcore@ietf.org>; Sun, 28 Nov 2010 18:19:23 -0800 (PST)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEANuc8kxAZnwM/2dsb2JhbACifHGmQpothUcEhFyGBYMP
X-IronPort-AV: E=Sophos;i="4.59,274,1288569600"; d="scan'208";a="186686192"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 29 Nov 2010 02:20:29 +0000
Received: from [10.86.250.233] (bxb-vpn3-745.cisco.com [10.86.250.233]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oAT2KSYl016170; Mon, 29 Nov 2010 02:20:28 GMT
Message-ID: <4CF30DEC.1010204@cisco.com>
Date: Sun, 28 Nov 2010 21:20:28 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: marianne.mohali@orange-ftgroup.com
References: <CD5674C3CD99574EBA7432465FC13C1B2202288A06@DC-US1MBEX4.global.avaya.com><4CDC04F2.3010701@cisco.com><AANLkTi=utzFcqg_QTfurdB0WKK8MRAny8Pb8CEE=s60L@mail.gmail.com><4CEC570D.8080700@cisco.com> <3A8FC9BC-3112-492A-87C2-3B5290A2D36D@acmepacket.com> <B11765B89737A7498AF63EA84EC9F5772378AA@ftrdmel1>
In-Reply-To: <B11765B89737A7498AF63EA84EC9F5772378AA@ftrdmel1>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 8bit
Cc: dworley@avaya.com, sipcore@ietf.org, HKaplan@acmepacket.com
Subject: Re: [sipcore] Reason as a parameter rather than an escaped header
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: Mon, 29 Nov 2010 02:19:24 -0000

I'm not especially particular about which of the various patterns of H-I 
entries are permitted - could be one or more of them, with discretion 
about what to include. (Though there could be merit in permitting 
omission of extra "virtual" entries that add no value.)

But whatever it is, the draft should say *something* that is sufficient 
to determine if the usage chosen is valid or not.

	Thanks,
	Paul

On 11/25/2010 5:48 PM, marianne.mohali@orange-ftgroup.com wrote:
>
>   Hi,
>
> My adding [MM]
>
> Marianne
>
>> -----Message d'origine-----
>> De : sipcore-bounces@ietf.org
>> [mailto:sipcore-bounces@ietf.org] De la part de Hadriel Kaplan
>> Envoyé : jeudi 25 novembre 2010 12:57
>> À : Paul Kyzivat
>> Cc : Worley, Dale R (Dale); sipcore@ietf.org
>> Objet : Re: [sipcore] Reason as a parameter rather than an
>> escaped header
>>
>>
>> On Nov 23, 2010, at 7:06 PM, Paul Kyzivat wrote:
>>
>>> But my remaining concern is about the rules in 4244bis
>> regarding how
>>> and when Reason headers are included in the H-I entries. It still
>>> seems to me that the text only talks about including them due to a
>>> response having been received. Where is the language that discusses
>>> adding a reason when retargeting is performed for some reason
>>> unrelated to a response?
>>>
>>> While I think one can argue that a server doing such
>> retargeting can
>>> imagine having sent the request to a virtual redirect
>> server and then
>>> processing the response from it, ISTM that would then call
>> for adding
>>> H-I entries for those steps.
>>
>> Right, that's the main piece to figure out first.  We already
>> agreed that 4244bis tells proxies to create H-I entries for
>> internal retargeting decisions.  What's not clear is what
>> internal H-I entries have to be created, and whether the
>> embedded Reason header value of the *SIP* type can be used
>> for such cases.
>>
>> For example, suppose Alice called Bob, and proxy-1 internally
>> diverts it to Charlie because it knows Bob is busy, *without*
>> having to send the INVITE to Bob and getting a 486 response.
>>
>> Is it legit for the H-I look like this:
>> History-Info:<sip:bob@example.com?Reason=SIP%3Bcause%3D486>;index=1
>> History-Info:<sip:charlie@example.com>;index=1.1;mp=1
>> History-Info:<sip:charlie@192.1.2.3>;index=1.1.1;rc=1.1
>>
>> Or does it have to look like this:
>> History-Info:<sip:bob@example.com>;index=1
>> History-Info:<sip:bob@127.0.0.1?Reason=SIP%3Bcause%3D486>;index=1.1
>> History-Info:<sip:charlie@example.com>;index=1.2;mp=1
>> History-Info:<sip:charlie@192.1.2.3>;index=1.2.1;rc=1.2
>>
>> Or does it have to do something like this:
>> History-Info:
>> <sip:bob@example.com?Reason=Internal%3Bcause%3D486>;index=1
>> History-Info:<sip:charlie@example.com>;index=1.1;mp=1
>> History-Info:<sip:charlie@192.1.2.3>;index=1.1.1;rc=1.1
>>
> [MM] Or (as per 3GPP CDIV 24.604 for call forwarding busy)
> History-Info:<sip:bob@example.com>;index=1
> History-Info:<sip:charlie@example.com;cause=486>;index=1.1;mp=1
> History-Info:<sip:charlie@192.1.2.3>;index=1.1.1;rc=1.1
>
>> -hadriel
>>
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
>