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

Paul Kyzivat <pkyzivat@cisco.com> Fri, 19 November 2010 21:33 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 75B523A680A for <sipcore@core3.amsl.com>; Fri, 19 Nov 2010 13:33:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.492
X-Spam-Level:
X-Spam-Status: No, score=-110.492 tagged_above=-999 required=5 tests=[AWL=0.107, 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 LBR4z8TVe45O for <sipcore@core3.amsl.com>; Fri, 19 Nov 2010 13:33:45 -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 557ED3A68D4 for <sipcore@ietf.org>; Fri, 19 Nov 2010 13:33:45 -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: AvsEAI985kxAZnwN/2dsb2JhbACiYXGiPptBhUsEhFqGAYMO
X-IronPort-AV: E=Sophos;i="4.59,226,1288569600"; d="scan'208";a="184198528"
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 19 Nov 2010 21:34:35 +0000
Received: from [161.44.174.105] (dhcp-161-44-174-105.cisco.com [161.44.174.105]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oAJLYZZI015682; Fri, 19 Nov 2010 21:34:35 GMT
Message-ID: <4CE6ED6B.4060802@cisco.com>
Date: Fri, 19 Nov 2010 16:34: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: 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> <4CE6CC6D.30103@cisco.com> <AANLkTinQLFGJn_DKY8FSmBqG4dNBRjWUtGHa41qGyfwO@mail.gmail.com> <4CE6E252.5070701@cisco.com> <AANLkTin9gtksQRmHGfv4gg_5ULGmV7HpEPzovTtgzJYJ@mail.gmail.com>
In-Reply-To: <AANLkTin9gtksQRmHGfv4gg_5ULGmV7HpEPzovTtgzJYJ@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 21:33:47 -0000

On 11/19/2010 4:00 PM, Mary Barnes wrote:
> Perhaps there's something about Marianne's proposal that I don't
> understand, but I thought that there was some sort of retargeting that
> occurred for which the application reason was applicable rather than it
> just being fabricated.  We have text that we add hi-entries for
> "internal" retargeting of a request and I would think that includes any
> "virtual" retargeting, although I would consider that still be be
> "internal " retargetting (i.e, it's a retarget that does not result in a
> new SIP request to another SIP entity.

I just went looking for the language you refer to. I find some about 
internal retargeting and the creation of multiple H-I entries. But the 
language for inclusion of Reason based on responses didn't directly 
relate to this in my mind. Maybe its just me.

In any case, when I look at B.1, there always is a *real* response that 
drives the insertion of a Reason. (With the exception of the timeout, 
which is treated as a 480 - entirely legit according to 3261.)

> I would agree that you wouldn't
> just fabricate an hi-entry to include an application specific reason,
> but again, I didn't understand Marianne's document to be proposing that.

I certainly read it that way, at least from the example. (Take a careful 
look at the example in the document.)

IIUC that is the entire intent of the draft. It is certainly legitimate 
for a server responsible for the R-URI to spontaneously decide to 
retarget, without first having received a response to provoke that 
behavior. If we then grant it the right to assign a Reason for that 
retargeting, I think we must allow to select *any* valid Reason, whether 
that reason is application-specific or not.

	Thanks,
	Paul

BTW, while looking at this I noticed an error in F1 in B.1. The INVITE 
in F1 has sip:alice@example.com as the R-URI, when it should (AFAIK) 
have sip:bob@example.com. Has that already been noted?

>
> Mary.
>
> On Fri, Nov 19, 2010 at 2:47 PM, Paul Kyzivat <pkyzivat@cisco.com
> <mailto:pkyzivat@cisco.com>> wrote:
>
>     Mary,
>
>     I don't think anyone is suggesting that 4244bis have anything to say
>     about application-specific reason codes.
>
>     The question is whether its permissible for a server to include a
>     Reason in an H-I entry when that Reason was not received in an
>     actual response. The trouble with arguing that the current language
>     covers "internal" retargeting is that if we assume some sort of
>     virtual server that returned a redirect and Reason, then that
>     presumably ought to have its own H-I entry. I expect we all agree
>     that having such an extra H-I entry is undesirable.
>
>     So, the question is whether the current language is sufficient to
>     allow a server to "fabricate" a Reason code and include it, or if we
>     need some explicit language to allow that.
>
>     There is a partial analogy here to sip servers that use multiple
>     to-tags to pretend a request was forked, in order to provide
>     alternative o/a outcomes. The validity of this is based on
>     presumption of "internal forking". In general I think people have
>     been ok with that without any explicit text permitting it. But of
>     course in the absence of H-I there is really no way to know if the
>     forking was virtual or real. Recently I've had someone question the
>     legitimacy of this argument. Ideally it would be better if it were
>     more strongly supported by text.
>
>     I think the argument re Reason in H-I is a bit weaker because H-I is
>     at the root of it, and explaining that there was (virtual)
>     redirection without a corresponding H-I entry may be hard for some
>     to swallow. (I guess we would have to argue that it was virtual
>     redirection to a server that didn't support H-I and so didn't
>     include the H-I entry. But then we would expect to see 3xx as a
>     Reason in addition to whatever other Reason is included.)
>
>     But I am still open to a convincing argument that the existing words
>     allow this behavior.
>
>     (The use of "cause=xxx" that I hear IMS includes is another story.
>     Its going to take a much stronger argument to convince me that is
>     permitted by 4244 or 4244bis.)
>
>             Thanks,
>             Paul
>
>
>     On 11/19/2010 3:12 PM, Mary Barnes wrote:
>
>         My intent was that if the response to the request (based both on
>         external and internal retargeting) contains any Reason header field
>         values, then those are all included in the Reason header field value
>         included in the hi-entry.  So, I was presupposing that even in
>         the case
>         of internal retargeting the reason could be captured - including
>         these
>         new application specific ones - i.e., the "values" for the
>         Reason header
>         field are set independent (and prior) to its addition to the
>         History-Info.  So, what I had in mind is essentially your 2nd
>         option below.
>
>         I really, really do not want to bog down 4244bis to make this
>         addition
>         of application reasons explicit.  Anytime we've gotten into any
>         application specific discussions or proposals, it is very
>         difficult to
>         reach consensus and move work forward.  And, the definition of these
>         application specific reasons is significant in that it requires
>         agreement on the values since it's not just reusing values already
>         defined in other specifications as are the current Reason header
>         field
>         types and values.  I don't see this as something that will
>         happen very
>         quickly (unfortunately), in particular given that the semantics
>         of  the
>         applications noted are not yet defined (or if there is a definitive
>         reference from another SDO), it needs to be included.
>
>         Regards,
>         Mary.
>
>         On Fri, Nov 19, 2010 at 1:13 PM, Paul Kyzivat
>         <pkyzivat@cisco.com <mailto:pkyzivat@cisco.com>
>         <mailto:pkyzivat@cisco.com <mailto:pkyzivat@cisco.com>>> wrote:
>
>
>
>             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>
>         <mailto:pkyzivat@cisco.com <mailto:pkyzivat@cisco.com>>
>         <mailto:pkyzivat@cisco.com <mailto:pkyzivat@cisco.com>
>         <mailto: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>
>         <mailto:sipcore-bounces@ietf.org <mailto:sipcore-bounces@ietf.org>>
>         <mailto:sipcore-bounces@ietf.org
>         <mailto:sipcore-bounces@ietf.org>
>         <mailto:sipcore-bounces@ietf.org <mailto:sipcore-bounces@ietf.org>>>
>
>                         [sipcore-bounces@ietf.org
>         <mailto:sipcore-bounces@ietf.org>
>         <mailto:sipcore-bounces@ietf.org <mailto:sipcore-bounces@ietf.org>>
>         <mailto:sipcore-bounces@ietf.org <mailto:sipcore-bounces@ietf.org>
>         <mailto:sipcore-bounces@ietf.org
>         <mailto:sipcore-bounces@ietf.org>>>] On
>
>                         Behalf Of Hadriel Kaplan [HKaplan@acmepacket.com
>         <mailto:HKaplan@acmepacket.com>
>         <mailto:HKaplan@acmepacket.com <mailto:HKaplan@acmepacket.com>>
>         <mailto:HKaplan@acmepacket.com <mailto:HKaplan@acmepacket.com>
>         <mailto: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>
>         <mailto:sipcore@ietf.org <mailto:sipcore@ietf.org>>
>         <mailto:sipcore@ietf.org <mailto:sipcore@ietf.org>
>         <mailto:sipcore@ietf.org <mailto:sipcore@ietf.org>>>
>
>
>         https://www.ietf.org/mailman/listinfo/sipcore
>
>                     _______________________________________________
>                     sipcore mailing list
>         sipcore@ietf.org <mailto:sipcore@ietf.org>
>         <mailto:sipcore@ietf.org <mailto:sipcore@ietf.org>>
>         <mailto:sipcore@ietf.org <mailto:sipcore@ietf.org>
>         <mailto:sipcore@ietf.org <mailto:sipcore@ietf.org>>>
>
>
>         https://www.ietf.org/mailman/listinfo/sipcore
>
>
>