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

Paul Kyzivat <pkyzivat@cisco.com> Fri, 19 November 2010 19:13 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 DFA0D3A6876 for <sipcore@core3.amsl.com>; Fri, 19 Nov 2010 11:13:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.476
X-Spam-Level:
X-Spam-Status: No, score=-110.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 jiqiudxo3FpA for <sipcore@core3.amsl.com>; Fri, 19 Nov 2010 11:13:05 -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 879D13A67FF for <sipcore@ietf.org>; Fri, 19 Nov 2010 11:13:05 -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: AvsEAJZa5kxAZnwM/2dsb2JhbACiYXGiIZs7hUsEhFqGAYMO
X-IronPort-AV: E=Sophos;i="4.59,224,1288569600"; d="scan'208";a="184151322"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 19 Nov 2010 19:13:50 +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 oAJJDnCT024247; Fri, 19 Nov 2010 19:13:49 GMT
Message-ID: <4CE6CC6D.30103@cisco.com>
Date: Fri, 19 Nov 2010 14:13:49 -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: Mary Barnes <mary.ietf.barnes@gmail.com>
References: <2F27AF47-BD50-45FC-A832-DD845EEAA8FA@acmepacket.com> <CD5674C3CD99574EBA7432465FC13C1B2202288A40@DC-US1MBEX4.global.avaya.com> <4CE6BF03.1030307@cisco.com> <AANLkTimV-gmSbARFxxAiSeKMKukY=oL4d+2hn-EAZLAN@mail.gmail.com>
In-Reply-To: <AANLkTimV-gmSbARFxxAiSeKMKukY=oL4d+2hn-EAZLAN@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: sipcore@ietf.org
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 19:13:07 -0000

On 11/19/2010 1:40 PM, Mary Barnes wrote:
> I don't disagree that strictly speaking adding the response codes based
> on applications is beyond what is currently specified in 4244bis.   We
> could add text change the text to something like the following (and I'm
> thinking either way that text should be updated since this is much more
> concise):
>
>    If the response contains any Reason header fields, then
>    the Reason header fields MUST be captured as Reasons
>    associated with the hi-targeted-to-uri that has been
>    retargeted.  If the SIP
>    response does not include a Reason header field (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.

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

The above still only covers cases where the retargeting is the result of 
a response, which doesn't cover Marianne's case. There are several ways 
to deal with this:

- leave as it is. Marianne's cases won't be covered. But she can
   rewrite her draft to show a proxy forwarding to an app server
   that returns a 3xx with reason code. (But not so useful if that is
   not the actual intended use.)

- assume that Marianne's cases are morally equivalent to
   forwarding to a "virtual server" that behaves as above, and so
   the H-I can be updated as if that were the case. (But the H-I
   entries aren't the same, because there are none for the visit to
   the "virtual server".

- 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.)

- leave 4244bis alone, but change draft-mohali-sipcore-reason-extension-
   application to be a revision to 4244bis. (Avoids the scope issue,
   but results in two back-to-back revisions to the same document.
   Developers will not be pleased with that.)

What do you think?

	Thanks,
	Paul

> And, that would allow for any future extensions to the Reason header to
> be plopped into an hi-entry.   If the Reason header were mandatory, then
> it would be easy in that HI just uses whatever value for the Reason
> header(s)  that are there.
>
> However, without having the new values defined for the Reason header we
> can't reference them and I would rather not hold up 4244bis, just so
> that we can have explicit text. Per the suggested text above, I think
> it's better anyways that we aren't referencing the specific Reason
> header field values, but rather just capture what's there.
>
> Regards,
> Mary.
>
> On Fri, Nov 19, 2010 at 12:16 PM, Paul Kyzivat <pkyzivat@cisco.com
> <mailto:pkyzivat@cisco.com>> wrote:
>
>     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 <mailto:sipcore-bounces@ietf.org>
>         [sipcore-bounces@ietf.org <mailto:sipcore-bounces@ietf.org>] On
>         Behalf Of Hadriel Kaplan [HKaplan@acmepacket.com
>         <mailto: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 <mailto:sipcore@ietf.org>
>         https://www.ietf.org/mailman/listinfo/sipcore
>
>     _______________________________________________
>     sipcore mailing list
>     sipcore@ietf.org <mailto:sipcore@ietf.org>
>     https://www.ietf.org/mailman/listinfo/sipcore
>
>