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

[Mary Barnes <[e-mail]>]

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.

Mary.

On Fri, Nov 19, 2010 at 2:47 PM, Paul Kyzivat <[e-mail]> 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 <[e-mail]
>> <mailto:[e-mail]>> 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
>>        <[e-mail] <mailto:[e-mail]>
>>        <mailto:[e-mail] <mailto:[e-mail]>>> 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: [e-mail]
>>        <mailto:[e-mail]>
>>        <mailto:[e-mail] <mailto:[e-mail]
>> >>
>>
>>                [[e-mail]
>>        <mailto:[e-mail]>
>>        <mailto:[e-mail]
>>        <mailto:[e-mail]>>] On
>>
>>                Behalf Of Hadriel Kaplan [[e-mail]
>>        <mailto:[e-mail]>
>>        <mailto:[e-mail] <mailto:[e-mail]>>]
>>
>>
>>
>>                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
>>        [e-mail] <mailto:[e-mail]>
>>        <mailto:[e-mail] <mailto:[e-mail]>>
>>
>>
>>        https://www.ietf.org/mailman/listinfo/sipcore
>>
>>            _______________________________________________
>>            sipcore mailing list
>>        [e-mail] <mailto:[e-mail]>
>>        <mailto:[e-mail] <mailto:[e-mail]>>
>>
>>
>>        https://www.ietf.org/mailman/listinfo/sipcore
>>
>>
>>