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

[Paul Kyzivat <[e-mail]>]

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]>> 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]>
>         [[e-mail] <mailto:[e-mail]>] On
>         Behalf Of Hadriel Kaplan [[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]>
>         https://www.ietf.org/mailman/listinfo/sipcore
>
>     _______________________________________________
>     sipcore mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/sipcore
>
>