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 > > >
- Re: [sipcore] Why doesn't 4244bis cover Marianne'… Adam Roach
- [sipcore] Why doesn't 4244bis cover Marianne's us… Hadriel Kaplan
- Re: [sipcore] Why doesn't 4244bis cover Marianne'… Hadriel Kaplan
- Re: [sipcore] Why doesn't 4244bis cover Marianne'… marianne.mohali
- Re: [sipcore] Why doesn't 4244bis cover Marianne'… Mary Barnes
- Re: [sipcore] Why doesn't 4244bis cover Marianne'… Worley, Dale R (Dale)
- Re: [sipcore] Why doesn't 4244bis cover Marianne'… Paul Kyzivat
- Re: [sipcore] Why doesn't 4244bis cover Marianne'… Mary Barnes
- Re: [sipcore] Why doesn't 4244bis cover Marianne'… Paul Kyzivat
- Re: [sipcore] Why doesn't 4244bis cover Marianne'… Mary Barnes
- Re: [sipcore] Why doesn't 4244bis cover Marianne'… Worley, Dale R (Dale)
- Re: [sipcore] Why doesn't 4244bis cover Marianne'… Paul Kyzivat
- Re: [sipcore] Why doesn't 4244bis cover Marianne'… Mary Barnes
- Re: [sipcore] Why doesn't 4244bis cover Marianne'… Paul Kyzivat
- Re: [sipcore] Why doesn't 4244bis cover Marianne'… Hadriel Kaplan
- Re: [sipcore] Why doesn't 4244bis cover Marianne'… Hadriel Kaplan