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

Mary Barnes <> Fri, 19 November 2010 20:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 15A463A68DC for <>; Fri, 19 Nov 2010 12:59:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.567
X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id W3nHVYWDFeU6 for <>; Fri, 19 Nov 2010 12:59:56 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B1C173A6862 for <>; Fri, 19 Nov 2010 12:59:55 -0800 (PST)
Received: by iwn40 with SMTP id 40so5508423iwn.31 for <>; Fri, 19 Nov 2010 13:00:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=D6dF02BrHliNhQ24uMn6o/pL19DZ5GotVmHJpfvuE0k=; b=mSAEK+8cCfYhfGJc/x87xq8ikP7GHLM6WtG2r/5i1I6D6StS6V06Z8Mbdw3AnRPtbn vY5aXNSaWB6Sr7dW+Rl/ld2fV1kxdJxHu9LxDtTVmbLsd7CF8I/KX0Dv8DJXHdu2SiyK 8MmIelrO8o9nRljA1UV9Dj9KIIJw4JlTV3XXw=
DomainKey-Signature: a=rsa-sha1; c=nofws;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=n//ReIucayk3K8ToNPCDf6BaZJuhnQn5S5wVBGYfiP6KxMIPIL329vDvy9cj/3XWGV p/QI8B0sogH53iQKF1lehMZtWf8SpVled0n5SV5uGPNwZyOGP9pwLtgJqRXGolb1jg9F 2TS+Y1NjwqRlZu6VnveRenc5OtIGOmbjRyJME=
MIME-Version: 1.0
Received: by with SMTP id e4mr371152ibb.146.1290200444639; Fri, 19 Nov 2010 13:00:44 -0800 (PST)
Received: by with HTTP; Fri, 19 Nov 2010 13:00:44 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
Date: Fri, 19 Nov 2010 15:00:44 -0600
Message-ID: <>
From: Mary Barnes <>
To: Paul Kyzivat <>
Content-Type: multipart/alternative; boundary=000325574bc2311c1c04956e3361
Subject: Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case?
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 19 Nov 2010 20:59:58 -0000

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


On Fri, Nov 19, 2010 at 2:47 PM, Paul Kyzivat <> 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 <
>> <>> 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
>>        < <>
>>        < <>>> 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:
>>        <>
>>        < <
>> >>
>>                [
>>        <>
>>        <
>>        <>>] On
>>                Behalf Of Hadriel Kaplan [
>>        <>
>>        < <>>]
>>                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 mailing list
>> <>
>>        < <>>