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

[Paul Kyzivat <[e-mail]>]

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