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

Paul Kyzivat <pkyzivat@cisco.com> Fri, 19 November 2010 18:15 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 775623A6876 for <sipcore@core3.amsl.com>; Fri, 19 Nov 2010 10:15:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.454
X-Spam-Level:
X-Spam-Status: No, score=-110.454 tagged_above=-999 required=5 tests=[AWL=0.145, 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 sOr7gFGLcwk0 for <sipcore@core3.amsl.com>; Fri, 19 Nov 2010 10:15:46 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 69D1B3A6850 for <sipcore@ietf.org>; Fri, 19 Nov 2010 10:15:46 -0800 (PST)
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: Au4FAK9N5kxAZnwM/2dsb2JhbACUX44CcaImmz+FSwSEWoYBgw4
X-IronPort-AV: E=Sophos;i="4.59,224,1288569600"; d="scan'208";a="184134376"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 19 Nov 2010 18:16:36 +0000
Received: from [161.44.174.105] (dhcp-161-44-174-105.cisco.com [161.44.174.105]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oAJIGaZW008941 for <sipcore@ietf.org>; Fri, 19 Nov 2010 18:16:36 GMT
Message-ID: <4CE6BF03.1030307@cisco.com>
Date: Fri, 19 Nov 2010 13:16:35 -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: sipcore@ietf.org
References: <2F27AF47-BD50-45FC-A832-DD845EEAA8FA@acmepacket.com> <CD5674C3CD99574EBA7432465FC13C1B2202288A40@DC-US1MBEX4.global.avaya.com>
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B2202288A40@DC-US1MBEX4.global.avaya.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case?
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: Fri, 19 Nov 2010 18:15:47 -0000

I'm inclined to agree that this draft 
(draft-mohali-sipcore-reason-extension-application, not 
draft-mohali-diversion-history-info) *ought* to be orthogonal to 
4244bis, and "just work" with it.

BUT, in reality I'm not convinced that this is so. The following is from 
4244bis:

    For retargets that are the result of an explicit SIP response, a
    Reason MUST be associated with the hi-targeted-to-uri.  If the SIP
    response does not include a Reason header (see [RFC3326]), the SIP
    Response Code that triggered the retargeting MUST be included as the
    Reason associated with the hi-targeted-to-uri that has been
    retargeted.  If the response contains a Reason header for a protocol
    that is not SIP (e.g., Q.850), it MUST be captured as an additional
    Reason associated with the hi-targeted-to-uri that has been
    retargeted, along with the SIP Response Code.  If the Reason header
    is a SIP reason, then it MUST be used as the Reason associated with
    the hi-targeted-to-uri rather than the SIP response code.

Note that the above is limited to "retargets that are the result of an 
explicit SIP response". But when I look at the call flows in the draft, 
none of the retargets are the result of a sip response. Rather, they are 
spontaneous retargets due to server logic. 4244bis does not cover using 
the Reason header in H-I entries for this purpose.

	Thanks,
	Paul

On 11/19/2010 11:42 AM, Worley, Dale R (Dale) wrote:
> ________________________________________
> From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Hadriel Kaplan [HKaplan@acmepacket.com]
>
> It was unfortunate that we ran out of time in sipcore to talk about Marianne's draft, because I think it's a kind of litmus test of rfc4244bis.  Or else I think I must be missing something very basic. (easily the case)
> _______________________________________________
>
> As others have said in other terms,  draft-mohali-diversion-history-info is orthogonal to 4244bis.  draft-mohali provides additional Reason values that provide more detailed information on why a call was routed as it was.  Those Reason values will be recorded in H-I according to 4244bis.  In a sense, draft-mohali *is* a litmus test of 4244bis, because without H-I, the value of the new Reason values would be dramatically reduced.  But since the two are orthogonal, draft-mohali needs to be specified, but it can be specified separately.
>
> Dale
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>