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
