Subject: [sipcore] Comments on draft-mohali-sipcore-reason-call-forwarding-00

From: "James M. Polk" <[email-masked]>
Date: Mon, 18 Oct 2010 14:11:38 -0500

I have several comments about
http://www.ietf.org/id/draft-mohali-sipcore-reason-call-forwarding-00.txt

Initially, I'm wondering why the Reason header protocol "SIP" isn't 
sufficient with a 181 reason code. I don't believe you account for 
that possibility (i.e., what different is supposed to happen when 
this occurs?).

Then I get to the fact that in your example, you don't include a 
Reason header in any of your decoded SIP messages, so I'm wondering 
what your example is really showing us (especially that's different 
that a "Reason: SIP=181" with or without a text string saying 
something like "Call is (or has been) forwarded").

Then I get back to your 3rd para in the 1st section that states this 
as the main possibility for why this extension is proposed:

"
    This
    might help other applications/entities invoked downstream to take
    appropriate decisions to avoid undesired service interactions or to
    take advantage of this information (eg. delivering the appropriate
    voicemail announcement).
"

And I ask myself, how are the 8 Reason codes justified in this sentence?

Then I ask myself about the 8 Reason codes, and see how much actual 
information they reveal:

1      Unknown/not available
2      User Busy
3      No reply
4      Unconditional
5      Deflection during alerting
6      Deflection immediate response
7      Mobile subscriber not reachable
8      Not Logged-in

...and think, that for

#1 - you wouldn't include that in a 302 (as in your example), as an 
unknown is probably not going to get retargeted, but rather a 4XX 
response that doesn't need a reason.
#2 - that's probably telling the caller more that the called party 
wants them to know, and doesn't always play nice with a call-waiting function.
#3 - why would you include this in the 181 or 302?
#4 - again, this seems like more information that the called probably 
wants revealed, or this is just a matter of fact scenario that is 
normal, so why give this additional information.
#5 - this is also probably more than the called wants to tell the callee.
#6 - I can't tell why this is different from an "Unconditional" reason.
#7 - do you really want the callee - every time that number is called 
- to know that this is a mobile phone?
#8 - I don't believe you will want to inform the callee that the 
person they called is no-logged-in,but rather make this a 
Not-available Reason, which is similar to a "Reason: SIP=181", which 
is available now.

James

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 18 Oct 2010 17:12:17 -0400

Here are some more comments on this draft:

The term "call diversion" sounds more inclusive to the naive ear than
"call forwarding".  If the two terms are used identically in the
draft, it seems better to use only the former, especially because the
abbreviation "CDIV" is being used.

Section 3 does not give any BNF for CDIV, though it quotes all of the
established BNF for the Reason header. Clearly, what is intended (but
not stated) is:

    protocol  =/  "CDIV"

In regard to listing the CDIV cause values, it seems to me that there
should be an existing encoding of call diversion reasons somewhere
within the 3GPP specification, and it would be more effective for the
draft to reference that table (which would be maintained by 3GPP)
rather than defining a new IANA registry (which would be used almost
exclusively by 3GPP).

In the example, it appears that the 302 response F3 is informing the
proxy that the call should be sent to Voicemail.  In that case, the
302 would also carry the Reason header explaing why the diversion is
being done, which the proxy would subsequently transcribe into the
History-Info header of the new INVITE F5:

    F3: 302 Bob -> proxy.example.com

    SIP/2.0 302 Moved Temporarily
    Via: SIP/2.0/TCP 192.0.2.4:5060;branch=z9hG4bK-ik80k7g-1
    Via: SIP/2.0/TCP proxy.example.com:5060;branch=z9hG4bK-klj79f
    From: Alice <sip:[email-masked];user=phone>; tag=1234567
    To: sip:[email-masked];user=phone;tag=765432
    Call-ID: c3x842276298220188511
    Contact: <sip:[email-masked]>
    Reason: CDIV;cause=6;text="Deflection immediate response"
    CSeq: 1 INVITE
    Content-Length: 0

In the example, F5 has two "Reason" headers attached to the URI at
index 1.  If you have more than one "header" attached to a URI, only
the first is introduced with "?", the remainder are introduced with
"&":

    History-Info: <sip:[email-masked];user=phone?Reason=SIP
              %3Bcause=302%3Btext="Moved Temporarily"&Reason=CDIV
              %3Bcause=6%3Btext="Deflection immediate response">;index=1,
              <sip:[email-masked]>;index=1.1;mp=1

There are also some difficulties regarding the History-Info headers in
the examle; they don't appear to be consistently applied to all the
INVITEs.

Dale

---

From: <[email-masked]>
Date: Thu, 21 Oct 2010 00:04:47 +0200

Hi James,

My answer inline [MM].

> -----Message d'origine-----
> De : [email-masked] 
> [mailto:[email-masked]] De la part de James M. Polk
> Envoyé : lundi 18 octobre 2010 21:12
> À : [email-masked]
> Objet : [sipcore] Comments on 
> draft-mohali-sipcore-reason-call-forwarding-00
> 
> Initially, I'm wondering why the Reason header protocol "SIP" 
> isn't sufficient with a 181 reason code. I don't believe you 
> account for that possibility (i.e., what different is 
> supposed to happen when this occurs?).
[MM] I'm not sure to get your point but the 181 is ok but not sufficient. It delivers the information that the call is being forwarded but not the reason why it has been forwarded.

> Then I get to the fact that in your example, you don't 
> include a Reason header in any of your decoded SIP messages, 
> so I'm wondering what your example is really showing us 
> (especially that's different that a "Reason: SIP=181" with or 
> without a text string saying something like "Call is (or has 
> been) forwarded").
[MM] You can find the Reason header escaped in the R-URI as parameter of the History-Info header.
My point is not focused on the "classic" Reason header, so that there is no interest to add it.

> Then I get back to your 3rd para in the 1st section that 
> states this as the main possibility for why this extension is 
> proposed:
> 
> "
>     This
> Then I ask myself about the 8 Reason codes, and see how much 
> actual information they reveal:
> 
> 1      Unknown/not available
> 2      User Busy
> 3      No reply
> 4      Unconditional
> #1 - you wouldn't include that in a 302 (as in your example), 
> as an unknown is probably not going to get retargeted, but 
> rather a 4XX response that doesn't need a reason.
[MM] Sorry, I didn't catch your point.

> #2 - that's probably telling the caller more that the called 
> party wants them to know, and doesn't always play nice with a 
> call-waiting function.
[MM] The relevant information is going to the called party (in the INVITE request), not to the caller and if you want transparency for the caller (same for call-waiting), just not send upstream the 181 answer.
 
> #3 - why would you include this in the 181 or 302?
[MM] I propose to include it in the INVITE.

> #4 - again, this seems like more information that the called 
> probably wants revealed, or this is just a matter of fact 
> scenario that is normal, so why give this additional information.
[MM] Either the original called wants to provide this information downstream, or the new destination rely on this information to adapt its behavior before answering the call.

> #5 - this is also probably more than the called wants to tell 
[MM] The calle is not necessarily informed of what is going on.

> #6 - I can't tell why this is different from an 
[MM] What is different?

> - to know that this is a mobile phone?
[MM] non, I DO NOT want the callee to be informed that it is not calling me at my office but at my home.

> #8 - I don't believe you will want to inform the callee that 
> the person they called is no-logged-in,but rather make this a 
> Not-available Reason, which is similar to a "Reason: 
> SIP=181", which is available now.
[MM]idem
> James

Best Regards,
Marianne
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: <[email-masked]>
Date: Thu, 21 Oct 2010 00:36:43 +0200

Hi Dale,

Thanks for your positive review.

See my answer in your mail [MM] 

Best Regards,
Marianne

> [mailto:[email-masked]] De la part de Worley, Dale R (Dale)
> Envoyé : lundi 18 octobre 2010 23:12
> À : [email-masked]
> Objet : Re: [sipcore] Comments on 
> The term "call diversion" sounds more inclusive to the naive 
> ear than "call forwarding".  If the two terms are used 
> identically in the draft, it seems better to use only the 
> former, especially because the abbreviation "CDIV" is being used.
[MM] I agree with your statement, with call diversion no ambiguity is possible. I thought that "call forwarding" was the original term and I didn't wanted to change the habits but searching a simple acronym for the protocol value, 'CDIV' sounds good to me. 

> Section 3 does not give any BNF for CDIV, though it quotes 
> all of the established BNF for the Reason header. Clearly, 
> what is intended (but not stated) is:
> 
>     protocol  =/  "CDIV"
[MM] What is just after the established BNF is not good? I've used RFC4411 as a model.

> In regard to listing the CDIV cause values, it seems to me 
> that there should be an existing encoding of call diversion 
> reasons somewhere within the 3GPP specification, and it would 
> be more effective for the draft to reference that table 
> (which would be maintained by 3GPP) rather than defining a 
> new IANA registry (which would be used almost exclusively by 3GPP).
[MM] Right, but the existing CDIV cause values (described in 3GPP) are a corruption of SIP response codes and brings confusion. It is the initial reason of this draft. Your idea of mixing both sound good to me: register a new protocol value "CDIV" but keep the reasons values as in 3GPP. The problem I see is that reason values are described in RFC4458 not for the Reason header but for an URI parameter and I'me not sure it is possible to re-use it. An other way could be to registering cause values but with the same values as today instead of (1 to 8). Let's think about it...
 
> 
> In the example, it appears that the 302 response F3 is 
> informing the proxy that the call should be sent to 
> Voicemail.  In that case, the
> 302 would also carry the Reason header explaing why the 
> diversion is being done, which the proxy would subsequently 
> transcribe into the History-Info header of the new INVITE F5:
> 

[MM] Right, I will add it in the next version. 
> 
> In the example, F5 has two "Reason" headers attached to the 
> URI at index 1.  If you have more than one "header" attached 
> to a URI, only the first is introduced with "?", the 
> remainder are introduced with
> "&":
> 
[MM]Exact, I noted this mistake just after I submitted the draft :-/ Thanks.
> 
> There are also some difficulties regarding the History-Info 
> headers in the examle; they don't appear to be consistently 
> applied to all the INVITEs.
[MM] ok, I will review it in detail.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Oct 2010 19:09:58 -0400

[as participant]

I think I'm replying to an earlier message, not this one, but the point 
is the same:

IIUC the intent of this work is to define new values for the Reason 
header, that can be used in a Reason header inserted into a URI in 
History-Info. And there is *no* expectation that these values would be 
used in a Reason header in a message that is actually sent. Is that right?

If so, it at least sounds like an abuse - that some other mechanism 
should be used.

OTOH, if there is some plausible reason to use this in an actual request 
then I find it much less troubling.

	Thanks,
	Paul

On 10/20/2010 6:36 PM, [email-masked] wrote:
>>      From: Alice<sip:[email-masked];user=phone>; tag=1234567
>>      Contact:<sip:[email-masked]>
>>      History-Info:<sip:[email-masked];user=phone?Reason=SIP

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Thu, 21 Oct 2010 15:47:26 -0400

>> From: Dale Worley

> From: Marianne Mohali

> [MM] What is just after the established BNF is not good? I've used

It is good to describe the change in words, but it is better to
describe the change in both words and in BNF -- some people find one
method easier to understand than the other method.  And since the two
methods are vulnerable to different kinds of errors, using both makes
it easier to discover errors in the definition.

As far as I can tell, RFC 4411 contains no BNF at all, so it is not a
good model of how to update BNF.

> [MM] Right, but the existing CDIV cause values (described in 3GPP)
> are a corruption of SIP response codes and brings confusion. It is
> the initial reason of this draft. Your idea of mixing both sound
> good to me: register a new protocol value "CDIV" but keep the
> reasons values as in 3GPP. The problem I see is that reason values
> are described in RFC4458 not for the Reason header but for an URI
> parameter and I'me not sure it is possible to re-use it. An other
> way could be to registering cause values but with the same values
> as today instead of (1 to 8). Let's think about it...

The ideal situation would be if 3GPP had a clear taxonomy of diversion
situations, and the CDIV cause values were an encoding of those
categories.  In particular, we expect CDIV to be generated by a 3GPP
system, and so 3GPP would clearly specify the diversion situations
which are described by the cause values.

It is not ideal if Sipcore defines these cause values, because
our understanding of call diversion services probably differs from
the understanding of 3GPP.

Dale

---

From: <[email-masked]>
Date: Thu, 21 Oct 2010 23:05:57 +0200

Hi Paul,

My answer in your text [MM]

Thanks,
Marianne
> [mailto:[email-masked]] De la part de Paul Kyzivat
> Envoyé : jeudi 21 octobre 2010 01:10
> À : [email-masked]
> Objet : Re: [sipcore] Commentson 
> I think I'm replying to an earlier message, not this one, but 
> the point is the same:
> 
> IIUC the intent of this work is to define new values for the 
> Reason header, that can be used in a Reason header inserted 
> into a URI in History-Info. And there is *no* expectation 
> that these values would be used in a Reason header in a 
> message that is actually sent. Is that right?
[MM] It is right for the draft in subject (reason for call diversion) but not for the other draft (if it is what you mean by "an earlier message") you seem to refer (Reason for applications) where new values could be added "everywhere".
> 
> If so, it at least sounds like an abuse - that some other 
> mechanism should be used.  
> 
> OTOH, if there is some plausible reason to use this in an 
> actual request then I find it much less troubling.
[MM]  Answering only for the draft in subject; it's true that it has a narrow scope but, at the end, the new values could be present everywhere the History-Info header is. At this time, I described our need but I could think about a larger use of those new values (eg. directly in a SIP error response due to a UA retargeting).
> >> Envoyé : lundi 18 octobre 2010 23:12 À : [email-masked] 
> Objet : Re: 
> >> [sipcore] Comments on 
> > [MM] I agree with your statement, with call diversion no 
> ambiguity is possible. I thought that "call forwarding" was 
> the original term and I didn't wanted to change the habits 
> but searching a simple acronym for the protocol value, 'CDIV' 
> sounds good to me.
> >
> all of the 
> that there 
> > [MM] Right, but the existing CDIV cause values (described 
> in 3GPP) are a corruption of SIP response codes and brings 
> confusion. It is the initial reason of this draft. Your idea 
> of mixing both sound good to me: register a new protocol 
> value "CDIV" but keep the reasons values as in 3GPP. The 
> problem I see is that reason values are described in RFC4458 
> not for the Reason header but for an URI parameter and I'me 
> not sure it is possible to re-use it. An other way could be 
> to registering cause values but with the same values as today 
> instead of (1 to 8). Let's think about it...
> >
> >>
> informing the 
> diversion is 
> >> There are also some difficulties regarding the 
> History-Info headers 
> >> in the examle; they don't appear to be consistently applied to all 
> >> the INVITEs.

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 21 Oct 2010 19:46:28 -0400

[as individual]

I think maybe you misunderstood me.

IMO its already somewhat of an abuse to include a header in URI in the 
H-I header, in the URI that was captured for inclusion in the H-I. If a 
UA received a URI in a 3xx response, and it contained a Reason header, 
then it would make perfect sense to put that into the H-I. But taking an 
R-URI and grafting on a Reason header before putting it into H-I seems 
at best a hack. But maybe that is water over the dam.

The hack is compounded if the reason in the Reason header is never 
intended to be used in a Reason header in a request that is sent - 
rather that it is only intended to be used in H-I in an already abusive way.

BUT, I expect in fact that these reason values *could* actually be 
useful in requests. If so, you would do yourself a favor to point that 
out in the draft. In your example 4, as Dale already pointed out, the 
Reason header doesn't appear in INVITE F5. But it *could*, and it would 
make sense that it should. That tells the voicemail system *directly* 
the reason why it was contacted. It wouldn't necessarily need to consult 
the H-I in an attempt to figure that out.

If that is *not* useful - if such values should be ignored in favor of 
analyzing the H-I entries - then I assert that Reason should not be used 
for this. Rather H-I should use its own header parameters to convey this 
sort of information.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Fri, 22 Oct 2010 17:44:56 +0200

Ok, maybe I should show a *normal* case where the Reason header is included in the UA response and then copied in the H-I. And also a situation where thoses values can be used directly in request (I don't know how).
However, the voicemail case you mention is possible only for the last retargeting reason (the call could have been diverted several times). It could be usefull to store the previous reasons in the H-I for the case where a unified voicemail wants to join the firt diverting user box. 
You said also that it wouldn't need to consult the H-I but I think it would be necessary to know the diverting user identity to find he's mailbox (in H-I).

Indeed, a dedicated H-I parameter could match the need but I already done this proposal unsucessfully and this solution would be quite different from the present.

Marianne

> De : Paul Kyzivat [mailto:[email-masked]] 
> Envoyé : vendredi 22 octobre 2010 01:46
> À : MOHALI Marianne RD-CORE-ISS
> Cc : [email-masked]
> IMO its already somewhat of an abuse to include a header in 
> URI in the H-I header, in the URI that was captured for 
> inclusion in the H-I. If a UA received a URI in a 3xx 
> response, and it contained a Reason header, then it would 
> make perfect sense to put that into the H-I. But taking an 
> R-URI and grafting on a Reason header before putting it into 
> H-I seems at best a hack. But maybe that is water over the dam.
> 
> The hack is compounded if the reason in the Reason header is 
> never intended to be used in a Reason header in a request 
> that is sent - rather that it is only intended to be used in 
> H-I in an already abusive way.
> 
> BUT, I expect in fact that these reason values *could* 
> actually be useful in requests. If so, you would do yourself 
> a favor to point that out in the draft. In your example 4, as 
> Dale already pointed out, the Reason header doesn't appear in 
> INVITE F5. But it *could*, and it would make sense that it 
> should. That tells the voicemail system *directly* the reason 
> why it was contacted. It wouldn't necessarily need to consult 
> If that is *not* useful - if such values should be ignored in 
> favor of analyzing the H-I entries - then I assert that 
> Reason should not be used for this. Rather H-I should use its 
> own header parameters to convey this sort of information.
> 
> 	Thanks,
> 	Paul
> 
> 
> >> [mailto:[email-masked]] De la part de Paul 
> Kyzivat Envoyé : 
> >> jeudi 21 octobre 2010 01:10 À : [email-masked] Objet : Re: 
> >> [sipcore] Commentson draft-mohali-sipcore-reason-call-forwarding-00
> >>
> >> [as participant]
> >>
> >> I think I'm replying to an earlier message, not this one, but the 
> >> point is the same:
> >>
> >> History-Info. And there is *no* expectation that these 
> values would 
> >> be used in a Reason header in a message that is actually sent. Is 
> >> that right?
> > [MM] It is right for the draft in subject (reason for call 
> diversion) but not for the other draft (if it is what you 
> mean by "an earlier message") you seem to refer (Reason for 
> applications) where new values could be added "everywhere".
> >>
> mechanism 
> >> OTOH, if there is some plausible reason to use this in an actual 
> >> request then I find it much less troubling.
> > [MM]  Answering only for the draft in subject; it's true 
> that it has a narrow scope but, at the end, the new values 
> could be present everywhere the History-Info header is. At 
> this time, I described our need but I could think about a 
> larger use of those new values (eg. directly in a SIP error 
> response due to a UA retargeting).
> >>
> >> 	Thanks,
> >> 	Paul
> >>
> >> ambiguity is possible. I thought that "call forwarding" was the 
> >> original term and I didn't wanted to change the habits but 
> searching 
> >> a simple acronym for the protocol value, 'CDIV'
> >> sounds good to me.
> >>>
> confusion. 
> >> It is the initial reason of this draft. Your idea of mixing both 
> >> sound good to me: register a new protocol value "CDIV" but 
> keep the 
> >> parameter and I'me not sure it is possible to re-use it. 
> An other way 
> >> could be to registering cause values but with the same values as 
> >> today instead of (1 to 8). Let's think about it...
> >>>
> >>>>
> >>>>       Via: SIP/2.0/TCP 
> proxy.example.com:5060;branch=z9hG4bK-klj79f

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 25 Oct 2010 18:34:55 -0400

Marianne,

Will you be attending the Beijing meeting?
Given the email activity on this, I think it could use a bit of 
discussion there.

	Thanks,
	Paul