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
