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

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 11 Nov 2010 21:06:16 -0500

Hi,
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)

When I read Marianne's draft, it sounds like the use-case she's trying to cover is call-forwarding, for things like voicemail systems to be able to detect/process.  So what really confuses me is I thought one of the basic applications 4244bis was trying to enable was exactly that one.  Right?  If it's not sufficient to achieve that, I think we've screwed up somewhere... or at least need to make sure it's not something we can fix in 4244bis, because now would be a really good time to fix it.  :)
My 2 cents.

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Fri, 12 Nov 2010 10:53:35 +0800

[as chair]

> When I read Marianne's draft, it sounds like the use-case she's trying to cover is call-forwarding, for things like voicemail systems to be able to detect/process.  So what really confuses me is I…

At IETF 75, when we were discussing the applicability of 4244bis to the 
SIPCORE charter (as opposed to simply developing a new document that was 
limited to describing how to use 4244 to deliver URI parameters), one of 
the rather important points that was made was that we would "limit bis 
changes to [those necessary to] satisfy target uri requirements."

If the RAI community at large wants to expand this to include a general 
tune-up and/or kitchen-sinking of 4244, then we need to figure out a way 
to put the SIPCORE milestone to rest and then send the rest of the 
changes to DISPATCH. I have no interest in letting this milestone drag 
on as people come up with new things they'd like to see added or changed.

/a

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 11 Nov 2010 22:32:03 -0500

I'd like a clarification. 
You said:
> "limit bis 

If by that you mean literally just to enable GRUU delivery, we've already exceeded that.  You don't need an "mp" tag for that, for example, afaict.

But I'm also not sure it's fair to be that restrictive in your interpretation of what the bis can change.  Obviously we have to constrain the scope, to actually get anywhere.
But there's no point in publishing a document if it doesn't solve a problem people actually have, just for the sake of publishing a document. 

[soapbox]
An RFC is not an end goal in itself - it's a means to an end, namely for enabling interoperable protocols people will *actually use*.
[/soapbox]
(I know we all agree on this, I'm just venting)

BTW, I'm not sure Marianne's use-case requires *ANY* normative changes to rfc4244bis.  I was just commenting that it would have been nice to really understand if rfc4244bis did not cover it.  This is similar to Cullen's concern about use-cases/application-examples.  We need to make sure the changes we're making are actually useful. (I think they *are*, or are as close as we can get, but that doesn't mean we shouldn't go through the exercise... using H-I just isn't that simple/obvious)

-hadriel

---

From: <[email-masked]>
Date: Fri, 19 Nov 2010 16:32:19 +0100

Hi,

The objective of draft-mohali-sipcore-reason-extension-application is to know why and, more exactly, which application has influenced the session.
4244bis do not cover the need but is necessary to meet the need.

3 Use-cases for application-specific Reason:
1. in accordance with RFC3326, in a BYE or CANCEL to explain why a session has been released/canceled (general use-case) 
2. in accordance with 4244bis, escaped in the History-Info header (2 sub-cases)
    2.1. When the call is retargeted (R-URI changed), explaining that it is because of an application-specific internal decision.
    2.2. When there is no retargeting (R-URI unchanged), just to mark in the session history that this application has been invocated.

Work on RFC4244bis has to be concluded and this draft has a different scope. I don't see any interaction issues.

Why not finish RFC4244bis and use this draft both to enrich Reason header in general and to meet the needs using History-Info (already covering the use of Reason)?

Hadriel, you said "When I read Marianne's draft, it sounds like the use-case she's trying to cover is call-forwarding" 
but the presented draft has really NO link with Call Forwarding (it is an other draft ;-).

Marianne

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de Hadriel Kaplan
> Envoyé : vendredi 12 novembre 2010 04:32
> À : Adam Roach
> Cc : [email-masked] WG
> Objet : Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case?
> 
> 
> If by that you mean literally just to enable GRUU delivery, 
> we've already exceeded that.  You don't need an "mp" tag for 
> that, for example, afaict.
> 
> But I'm also not sure it's fair to be that restrictive in 
> your interpretation of what the bis can change.  Obviously we 
> have to constrain the scope, to actually get anywhere.
> But there's no point in publishing a document if it doesn't 
> solve a problem people actually have, just for the sake of 
> publishing a document. 
> 
> [soapbox]
> An RFC is not an end goal in itself - it's a means to an end, 
> namely for enabling interoperable protocols people will 
> *actually use*.
> [/soapbox]
> BTW, I'm not sure Marianne's use-case requires *ANY* 
> normative changes to rfc4244bis.  I was just commenting that 
> it would have been nice to really understand if rfc4244bis 
> did not cover it.  This is similar to Cullen's concern about 
> use-cases/application-examples.  We need to make sure the 
> changes we're making are actually useful. (I think they 
> *are*, or are as close as we can get, but that doesn't mean 
> we shouldn't go through the exercise... using H-I just isn't 
> that simple/obvious)
> 
> -hadriel
> 
> >> When I read Marianne's draft, it sounds like the use-case 
> she's trying to cover is call-forwarding, for things like 
> voicemail systems to be able to detect/process.  So what 
> really confuses me is I thought one of the basic applications 
> 4244bis was trying to enable was exactly that one.  Right?  
> If it's not sufficient to achieve that, I think we've screwed 
> up somewhere... or at least need to make sure it's not 
> something we can fix in 4244bis, because now would be a 
> really good time to fix it.  :)
> > 
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Mary Barnes <[email-masked]>
Date: Fri, 19 Nov 2010 10:03:00 -0600

Response inline below [MB].

Mary.

On Thu, Nov 11, 2010 at 9:32 PM, Hadriel Kaplan <[email-masked]>wrote:

> If by that you mean literally just to enable GRUU delivery, we've already
> exceeded that.  You don't need an "mp" tag for that, for example, afaict.
>
> But I'm also not sure it's fair to be that restrictive in your
> interpretation of what the bis can change.  Obviously we have to constrain
> the scope, to actually get anywhere.
> But there's no point in publishing a document if it doesn't solve a problem
> people actually have, just for the sake of publishing a document.
>
> [soapbox]
> An RFC is not an end goal in itself - it's a means to an end, namely for
> enabling interoperable protocols people will *actually use*.
> [/soapbox]
> BTW, I'm not sure Marianne's use-case requires *ANY* normative changes to
> rfc4244bis.  I was just commenting that it would have been nice to really
> understand if rfc4244bis did not cover it.  This is similar to Cullen's
> concern about use-cases/application-examples.  We need to make sure the
> changes we're making are actually useful. (I think they *are*, or are as
> close as we can get, but that doesn't mean we shouldn't go through the
> exercise... using H-I just isn't that simple/obvious)
>

[MB] Correct, I also do not believe that Marianne's use cases require
normative changes to RFC 4244bis, which is really agnostic in terms of the
Reason header value.  I can certainly see that History-Info header provides
necessary functionality for the use case, however, the use cases also
require extensions to Reason header values that are normative.  For this
same reason, we are removing the sub-addressing use case since it requires
new functionality beyond what is provided by 4244bis.  [/MB]

> >> When I read Marianne's draft, it sounds like the use-case she's trying
> to cover is call-forwarding, for things like voicemail systems to be able to
> detect/process.  So what really confuses me is I thought one of the basic
> applications 4244bis was trying to enable was exactly that one.  Right?  If
> it's not sufficient to achieve that, I think we've screwed up somewhere...
> or at least need to make sure it's not something we can fix in 4244bis,
> because now would be a really good time to fix it.  :)
> >

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 19 Nov 2010 11:42:57 -0500

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Hadriel Kaplan [[email-masked]]

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Nov 2010 13:16:35 -0500

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

---

From: Mary Barnes <[email-masked]>
Date: Fri, 19 Nov 2010 12:40:44 -0600

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 <[email-masked]> wrote:

> draft-mohali-diversion-history-info) *ought* to be orthogonal to 4244bis,
> and "just work" with it.
>
> 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
>
>
>> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Nov 2010 14:13:49 -0500

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

(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.
>
> 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 <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     BUT, in reality I'm not convinced that this is so. The following is
>     from 4244bis:
>
>     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
>
>
>         From: [email-masked] <mailto:[email-masked]>
>         [[email-masked] <mailto:[email-masked]>] On
>         Behalf Of Hadriel Kaplan [[email-masked]
>         <mailto:[email-masked]>]
>
>         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
>         [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: Mary Barnes <[email-masked]>
Date: Fri, 19 Nov 2010 14:12:18 -0600

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 <[email-masked]> wrote:

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

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 19 Nov 2010 15:11:20 -0500

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]

[...]

Certainly in this situation, we'd better be legalistic, because there are so many ways that it could turn into a mess.

I prefer adding a suitable clause to 4244bis to allow the proxy to insert a Reason header for a URI that is redirected, as this is the clean way to handle the situation.  (The alternative is to synthesize an entry showing that the request was sent to a virtual redirection server, but that would make the H-I even longer.)  This is another aspect of the problem of documenting what the rules are for a consistent H-I header.

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Nov 2010 15:47:14 -0500

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 <[email-masked]
>     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:
>
>         On Fri, Nov 19, 2010 at 12:16 PM, Paul Kyzivat
>         <[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>                 [[email-masked]
>         <mailto:[email-masked]>
>         <mailto:[email-masked]
>         <mailto:[email-masked]>>] On
>
>         <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>]
>
>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>

---

From: Mary Barnes <[email-masked]>
Date: Fri, 19 Nov 2010 15:00:44 -0600

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 <[email-masked]> 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
> 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.
>
> going to take a much stronger argument to convince me that is permitted by
> 4244 or 4244bis.)
>
>        Thanks,
>        Paul
>
>
>>        <mailto:[email-masked] <mailto:[email-masked]
>> >>
>>

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 19 Nov 2010 16:34:35 -0500

On 11/19/2010 4:00 PM, Mary Barnes wrote:
> 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 just went looking for the language you refer to. I find some about 
internal retargeting and the creation of multiple H-I entries. But the 
language for inclusion of Reason based on responses didn't directly 
relate to this in my mind. Maybe its just me.

In any case, when I look at B.1, there always is a *real* response that 
drives the insertion of a Reason. (With the exception of the timeout, 
which is treated as a 480 - entirely legit according to 3261.)

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

I certainly read it that way, at least from the example. (Take a careful 
look at the example in the document.)

IIUC that is the entire intent of the draft. It is certainly legitimate 
for a server responsible for the R-URI to spontaneously decide to 
retarget, without first having received a response to provoke that 
behavior. If we then grant it the right to assign a Reason for that 
retargeting, I think we must allow to select *any* valid Reason, whether 
that reason is application-specific or not.

	Thanks,
	Paul

BTW, while looking at this I noticed an error in F1 in B.1. The INVITE 
in F1 has sip:[email-masked] as the R-URI, when it should (AFAIK) 
have sip:[email-masked]. Has that already been noted?

>
> Mary.
>
> On Fri, Nov 19, 2010 at 2:47 PM, Paul Kyzivat <[email-masked]
>     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.)
>
>     (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 Fri, Nov 19, 2010 at 1:13 PM, Paul Kyzivat
>                 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):
>
>                    Response Code that triggered the retargeting MUST be
>         included
>                 as the
>                 And, that would allow for any future extensions to the
>         Reason
>                 header to
>                 However, without having the new values defined for the
>         Reason
>                 header we
>                 that we can have explicit text. Per the suggested text
>         above, I
>                 think
>         <mailto:[email-masked] <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>> wrote:
>
>                        Reason MUST be associated with the
>         hi-targeted-to-uri.
>                   If the SIP
>                        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
>                     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
>                     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
>
>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>
>         <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked]>>>] On
>
>         <mailto:[email-masked] <mailto:[email-masked]>>
>         <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>]
>
>
>
>                         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
>                           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.
>                         orthogonal, draft-mohali needs to be specified,
>         but it
>                 can be
>                         specified separately.
>
>                         Dale
>         <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>
>
>         <mailto:[email-masked] <mailto:[email-masked]>
>         <mailto:[email-masked] <mailto:[email-masked]>>>
>
>

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 20 Nov 2010 09:33:15 -0500

> but the presented draft has really NO link with Call Forwarding (it is an other draft ;-).

Sorry for the confusion - I meant draft-mohali-sipcore-reason-call-forwarding-00 specifically.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Sat, 20 Nov 2010 09:44:00 -0500

The two aren't orthogonal - although perhaps we're talking about a different "draft-mohali".
I'm talking about draft-mohali-sipcore-reason-call-forwarding-00.

If you ignore the reason cause code stuff in it, the main functional difference I can discern in that draft is that the call-forwarding action occurs internally in a system, rather than externally with a SIP redirect/response.  If that's true, then what I was trying to say at the mic during the WG meeting was that we've already said H-I would record H-I entries for internal processing - essentially as if the SIP request had gone to a next-hop and the next-hop had redirected the call using 3xx, or rejected the call with a 4xx.

What we haven't settled on is, for entries created due to internal processing, whether the embedded Reason header cause code can still be used or not, and specifically whether we can use *SIP* response codes in that embedded Reason header for internally generated H-I entries.  Personally I think it makes sense to do so, because what matters in this whole thing is how the receiver of H-I processes H-I entries to invoke specific application logic.  It doesn't actually matter whether there was a physical on-the-wire SIP 486 response which caused a proxy to recurse or retarget - what matters is that the proxy retargeted due to the user being busy.

If you believe that, then the new cause codes in draft-mohali-sipcore-reason-call-forwarding-00 suddenly start to look a heck of lot like SIP reason codes.  For example, a "User Busy" is the same as a SIP 486; a "No Reply" is a SIP 408; a "deflection immediate response" is a 302; "Not Logged-in" is a 480.

-hadriel