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 > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: 02 May 2008 18:23 > To: Francois Audet > Cc: Elwell, John; [email protected] > Subject: Re: [BLISS] Rejection conditions for ACH > > 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 > > Francois Audet wrote: > > I like that. Perfect. > > > >> -----Original Message----- > >> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > >> On Behalf Of Elwell, John > >> Sent: Tuesday, April 15, 2008 13:55 > >> To: [email protected] > >> 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 protected] > >> https://www.ietf.org/mailman/listinfo/bliss > >> > > _______________________________________________ > > BLISS mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/bliss > > > _______________________________________________ BLISS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bliss
