Elwell, John wrote:
> Paul,
>
> Yes, that's an interesting one. In fact, we could have a condition
> "ignore" or "silent reject", which basically means don't send an
> immediate response to the caller (let him think it is alerting). Then it
> will depend on ACH at the proxy whether that later gets forwarded to
> voicemail or simply times out.
Now you know what happened all those times you tried to call me. :-)
To me the key issue here is the nature of the communication from the
UAS. Is the UAS simply signaling some literal representation of its
state? Or is it in fact attempting to explicitly signal a request for a
feature to be carried out by a middlebox upstream of it? If the latter,
what if there is no middlebox upstream that is prepared to act on that
request? Do we just view the UAC as the feature server of last resort?
For my particular case, perhaps the button on the phone doesn't signal
anything at all. Instead, perhaps it simply stops ringing the phone
while simply allowing the transaction to time out. That is the local
implementation of the feature that doesn't require any special feature
support in the network. (If the proxy wants to cancel the leg after so
many rings and send the call to VM it can still do that.)
A harder case is where there are several extensions registered for the
same AOR, and all within hearing distance of one another. The call is
parallel forked to them all, and so they all ring. My solution above
will silence my phone, but not the others. Silencing them all without
answering any is a bit harder. I guess it could be achieved if the
button on my phone sent a 3xx response with a private address on the
phone. (Its contact URL or a gruu.) Then when the call came in on that,
it would suppress the ringing. But that would only work if the proxy
recursed on the 3xx and canceled the prior legs. I don't know if that is
a likely expectation.
Paul
> John
>
>> -----Original Message-----
>> From: Paul Kyzivat [mailto:[EMAIL PROTECTED]
>> Sent: 15 April 2008 22:22
>> To: Elwell, John
>> Cc: [email protected]
>> Subject: Re: [BLISS] Rejection conditions for ACH
>>
>> this seems fine to me. I am wondering about the case where the callee
>> wants to hide the true reason from the caller. Does that have to be
>> encoded as well? Or is that policy decide upstream?
>>
>> E.g. John calls me. I don't want to talk to him right now,
>> but I don't
>> want him to know that. I would really like him to get the same user
>> experience as if I was not present - typically ring a few
>> times and then
>> fail over to voicemail - which is different than if I bounce
>> him to VM
>> immediately.
>>
>> Paul
>>
>> Elwell, John wrote:
>>> 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
