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

Mary Barnes <mary.ietf.barnes@gmail.com> Fri, 19 November 2010 18:40 UTC

Return-Path: <mary.ietf.barnes@gmail.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 7FA2B28C0F8 for <sipcore@core3.amsl.com>; Fri, 19 Nov 2010 10:40:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.563
X-Spam-Level:
X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 PeJjgyGSJbWT for <sipcore@core3.amsl.com>; Fri, 19 Nov 2010 10:39:56 -0800 (PST)
Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 8AB6A28C101 for <sipcore@ietf.org>; Fri, 19 Nov 2010 10:39:55 -0800 (PST)
Received: by gxk27 with SMTP id 27so3134317gxk.31 for <sipcore@ietf.org>; Fri, 19 Nov 2010 10:40:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=BHHSeGUdAIXXYuWaJsQEbthGJCnN+UwGQqMljrvD648=; b=LundKWN5r1JGi0ZELwogMa4gcRPA3uhELvbCl9kMB6YiEzezD4jKyig9LCNPs1dFAx bnqxrarkJuA3HuERPVoe2ujzjOnSKJtITd92+sNRonitpekcInxC7ObMRaPR6Cr2EA6g WzTERS7dWBhf316lDWrynHWkpSyRj8iF7Esto=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CQjw6uYnQzAZsQLtPFH2xT1tE25Jal+V9T9Il4QGlN2mujqzXtZj1VJctKsIZ4jcou OwAwRRNL6v8B5nF7YQ6gAG+jbsGsKepi+Ps4nMBL504f6G9x86eEUW16VbwCDiQXt0tD +kx+2BxAtY383WiJ4fkXeIyip3xX84Z3b3ZrQ=
MIME-Version: 1.0
Received: by 10.151.51.15 with SMTP id d15mr4224539ybk.33.1290192044713; Fri, 19 Nov 2010 10:40:44 -0800 (PST)
Received: by 10.236.95.35 with HTTP; Fri, 19 Nov 2010 10:40:44 -0800 (PST)
In-Reply-To: <4CE6BF03.1030307@cisco.com>
References: <2F27AF47-BD50-45FC-A832-DD845EEAA8FA@acmepacket.com> <CD5674C3CD99574EBA7432465FC13C1B2202288A40@DC-US1MBEX4.global.avaya.com> <4CE6BF03.1030307@cisco.com>
Date: Fri, 19 Nov 2010 12:40:44 -0600
Message-ID: <AANLkTimV-gmSbARFxxAiSeKMKukY=oL4d+2hn-EAZLAN@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: Paul Kyzivat <pkyzivat@cisco.com>
Content-Type: multipart/alternative; boundary=0015174c0e0484688604956c3e03
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 18:40:01 -0000

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.

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> 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 [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
>>
>>  _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>