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

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.

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 <pkyzivat@cisco.com> 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: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of
>> Hadriel Kaplan [HKaplan@acmepacket.com]
>>
>> 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@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>>
>>  _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>