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
