Subject: Re: [BLISS] Rejection conditions for ACH

From: "Francois Audet" <[email-masked]>
Date: Fri, 2 May 2008 11:25:47 -0500

I like that. Perfect. 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Elwell, John
> Sent: Tuesday, April 15, 2008 13:55
> To: [email-masked]
> Subject: [BLISS] Rejection conditions for ACH
> 
> During BLISS ACH (automatic call handling) design team 
> discussions at the last conference call a provisional set of 
> rejection conditions was identified for which appropriate SIP 
> response codes need to be identified. Only conditions 
> typically expected to influence ACH at a proxy are included. 
> The conditions need to be agreed before attempting to select 
> response codes. The following conditions have been identified:
> 
>           <t>Busy. UA resources are busy as a result of 
> another call and further calls cannot be accepted until 
> resources become free. The condition may also be visible via 
> a presence system.</t>
>           <t>Do not disturb. The user has indicated in 
> advance an unwillingness to receive calls and therefore calls 
> cannot be accepted until the user indicates that the 
> condition has been lifted. A user may impose such a condition 
> during a meeting or while working on a critical task. The 
> user may indicate in advance a time at which she expects the 
> condition to be lifted. The condition may also be visible via 
> a presence system.</t>
>           <t>Local rejection. The user has responded to this 
> call by rejecting it. Whether this impacts other branches 
> (e.g., other UAs registered for that AoR), forwarding to 
> voicemail, forwarding to an assistant, etc. depends on the 
> proxy configuration. A user would use this facility when not 
> in a position to answer a particular call or when she feels 
> that it would be better handled elsewhere (e.g., by 
> voicemail, by an assistant). The fate of the call will depend 
> on proxy ACH settings.</t>
>           <t>Global rejection. The user has responded to this 
> call by rejecting it with the preference that all other 
> branches should be cancelled and forwarding to voicemail, 
> forwarding to an assistant, etc.
> should not take place. A user would use this facility when 
> she is unwilling to handle a particular call and does not 
> wish it to be handled elsewhere. A user would typically use 
> this facility for unwanted traffic. The fate of the call will 
> depend on proxy ACH settings, but typically it will result in 
> outright rejection.</t>
> 
> Please comment on this set of conditions.
> 
> John
> _______________________________________________
> BLISS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bliss
> 
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 02 May 2008 13:22:52 -0400

I think this is good, with the proviso that the UA, following explicit 
realtime inputs from the user, or prespecified policies, may "lie" and 
generate one of these responses even when the presumed conditions around 
it do not apply.

For example, the UA might be configured to signal Busy, rather than DND, 
to some or all incoming calls even though there is no actual call in 
progress. IMO this is *legal*, though probably not *default* behavior.

So, while these look a lot like state or condition of the UA, they are 
in fact statements of policy by the UA of how it would like the upstream 
elements to handle this call.

	Thanks,
	Paul

---

From: "Spencer Dawkins" <[email-masked]>
Date: Sun, 4 May 2008 18:25:27 -0500

Hi, John,

The suggested text worked for me until I got down to "Global Rejection".

>> should not take place.

I am almost sure I agree, but I was getting lost between present and past 
tense language (correct as written, just not easy to parse in the same 
sentence). If you're saying

"The user has responded to the call by globally rejecting it with the 
preference that all other branches should be cancelled. Forwarding to voice 
mail, to an assistant, etc. should not take place."

I agree, and I'd appreciate it if you considered the suggested text. At a 
minimum, s/and forwarding/and that forwarding/ to be parallel with 
"cancelled" would help.

Thanks,

Spencer

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 06 May 2008 07:13:47 +0100

Spencer, 

> On Behalf Of Spencer Dawkins
> Sent: 05 May 2008 00:25
> To: [email-masked]
> Subject: Re: [BLISS] Rejection conditions for ACH
> 
> Hi, John,
> 
[JRE] I prefer this change, which makes it clear that the PREFERENCE is
that forwarding to voicemail etc. should not take place. Thanks.

John

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 06 May 2008 07:23:40 +0100

Paul,

In principle the UA can lie. The response code reflects the meaning the
UA wishes to convey, not necessarily the true state of affairs.

Another possibility is that the UA could be truthful and rely on the
proxy to lie to the caller. This would help the proxy choose the most
appropriate ACH. However, it would only work in environments where the
UA is sure the proxy will do this. It might be feasible in enterprise
environments, for example. However, I don't think we want to go in the
direction of specifying too much in this latter direction.

John

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 02 May 2008 18:23
> To: Francois Audet
> Cc: Elwell, John; [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 06 May 2008 12:18:08 -0400

I think it would be good to mention this. It may however require coming 
up with a politically correct euphemism for "lie". :-)

Its all about conveying the end user's policy decision.

	Thanks,
	Paul

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 07 May 2008 08:20:52 +0100

I have drafted the following:
"<t>Note that in general the called UA will indicate the condition that
it is prepared to disclose to the proxy and to the calling UA. This
condition may not reflect the true condition at the called UA. For
example, the UA may prefer to indicate "busy" instead of "local
rejection", so that the caller is led to believe that a busy condition
exists. This has the disadvantage that any ACH action taken by the proxy
will be on the basis of the indicated condition, rather than the true
condition. On the other hand, it avoids having to rely on the proxy to
hide the true condition from the calling UA.</t>"

John 

> Sent: 06 May 2008 17:18
> To: Elwell, John
> Cc: Francois Audet; [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 07 May 2008 08:34:12 -0400

Sounds good to me.

	Thanks,
	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 7 May 2008 14:23:37 -0500

Ditto 

> Sent: Wednesday, May 07, 2008 05:34
> To: Elwell, John
> Cc: Audet, Francois (SC100:3055); [email-masked]
> > "<t>Note that in general the called UA will indicate the condition 
> > that it is prepared to disclose to the proxy and to the calling UA. 
> > This condition may not reflect the true condition at the called UA. 
> > For example, the UA may prefer to indicate "busy" instead of "local 
> > exists. This has the disadvantage that any ACH action taken by the 
> > proxy will be on the basis of the indicated condition, 
> rather than the 
> > true condition. On the other hand, it avoids having to rely on the 
> > proxy to hide the true condition from the calling UA.</t>"
> > 
> > John
> > 
> >> I think it would be good to mention this. It may however require 
> >> coming up with a politically correct euphemism for "lie". :-)
> >>
> >>>> I think this is good, with the proviso that the UA, following 
> >>>> explicit realtime inputs from the user, or prespecified 
> policies, 
> >>>> may "lie" and generate one of these responses even when the 
> >>>> presumed conditions around it do not apply.
> >>>>
> >>>> For example, the UA might be configured to signal Busy, 
> rather than 
> >>>> DND, to some or all incoming calls even though there is no
> >> actual call in
> >>>> So, while these look a lot like state or condition of 
> the UA, they 
> >>>> are in fact statements of policy by the UA of how it 
> would like the 
> >>>> upstream elements to handle this call.
> >>>>
> >>>> 	Thanks,
> >>>> 	Paul
> >>>>
> >>>> Francois Audet wrote:
> >>>>> I like that. Perfect. 
> >>>>>
> >>>>>> From: [email-masked] 
> [mailto:[email-masked]] On 
> >>>>>> Behalf Of Elwell, John
> typically 
> >>>>>> expected to influence ACH at a proxy are included.
> >>>>>>           <t>Busy. UA resources are busy as a result 
> of another 
> >>>>>> call and further calls cannot be accepted until 
> resources become 
> >>>>>> free. The condition may also be visible via a presence 
> >>>>>> system.</t>
> advance an 
> >>>>>> unwillingness to receive calls and therefore calls cannot be 
> >>>>>> accepted until the user indicates that the condition has been 
> >>>>>> lifted. A user may impose such a condition during a meeting or 
> >>>>>> while working on a critical task. The user may indicate in 
> >>>>>> advance a time at which she expects the condition to 
> be lifted. 
> >>>>>> The condition may also be visible via a presence system.</t>
> >>>>>>           <t>Local rejection. The user has responded 
> to this call 
> >>>>>> by rejecting it. Whether this impacts other branches 
> (e.g., other 
> >>>>>> UAs registered for that AoR), forwarding to voicemail, 
> forwarding 
> >>>>>> to an assistant, etc. depends on the proxy 
> configuration. A user 
> >>>>>> would use this facility when not in a position to answer a 
> >>>>>> particular call or when she feels that it would be 
> better handled 
> >>>>>> elsewhere (e.g., by voicemail, by an assistant). The 
> fate of the 
> >>>>>> call will depend on proxy ACH settings.</t>
> >>>>>> call by rejecting it with the preference that all 
> other branches 
> >>>>>> should be cancelled and forwarding to voicemail, 
> forwarding to an 
> >>>>>> assistant, etc.
> >>>>>> should not take place. A user would use this facility 
> when she is 
> >>>>>> unwilling to handle a particular call and does not 
> wish it to be 
> >>>>>> handled elsewhere. A user would typically use this 
> facility for 
> >>>>>> unwanted traffic. The fate of the call will depend on 
> proxy ACH 
> >>>>>> settings, but typically it will result in outright 
> rejection.</t>
> >>>>>>