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

Hi James,

My answer inline [MM].

> -----Message d'origine-----
> De : sipcore-bounces@ietf.org 
> [mailto:sipcore-bounces@ietf.org] De la part de James M. Polk
> Envoyé : lundi 18 octobre 2010 21:12
> À : sipcore@ietf.org
> Objet : [sipcore] Comments on 
> draft-mohali-sipcore-reason-call-forwarding-00
> 
> 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?).
[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
>     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.
[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 
> the callee.
[MM] The calle is not necessarily informed of what is going on.

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

> #7 - do you really want the callee - every time that number is called
> - 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
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
> 