Ditto
> -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Wednesday, May 07, 2008 05:34 > To: Elwell, John > Cc: Audet, Francois (SC100:3055); [email protected] > Subject: Re: [BLISS] Rejection conditions for ACH > > Sounds good to me. > > Thanks, > Paul > > Elwell, John wrote: > > 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 > > > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > >> Sent: 06 May 2008 17:18 > >> To: Elwell, John > >> Cc: Francois Audet; [email protected] > >> Subject: Re: [BLISS] Rejection conditions for ACH > >> > >> 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 > >> > >> Elwell, John wrote: > >>> 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
