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

[Mary Barnes <[e-mail]>]

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