Sorry I haven't responded to this. More inline.
Francois Audet wrote:
>
>
>> -----Original Message-----
>> From:
bliss-bounces@... [mailto:
bliss-bounces@...]
>> On Behalf Of Paul Kyzivat
>> Sent: Saturday, May 24, 2008 12:23
>> To:
bliss@...
>> Subject: Re: [BLISS] I-D Action:draft-ietf-bliss-ach-analysis-02.txt
>>
>> This looks pretty good to me. I wish I had had time to
>> participate in the work. I have just a few comments:
>>
>> - I have difficulty figuring out how to selectively deal with
>> call waiting. If a UA could answer a call, even though it
>> already has a call in progress, and would be willing to do so
>> if needful, how can it defer to the proxy? Once it has
>> rejected the call, it can't later answer it.
>> And if the proxy, based on policy, later decides to present
>> the call again, I don't see how the UA would know to answer
>> it this time.
>
> I'm not sure I get your point.
> I don't believe we intended this proxy stuff to apply to call waiting.
Well, there seem to be places in the text that mention possible
conflicts between the UAS and the proxy in handling of call waiting. For
example:
- section 3.1:
For example, if a phone determines it is busy
and returns a 302 response code to forward the call elsewhere or
performs "call waiting" action, this might prevent the proxy taking
whatever action it would have taken on receipt of a 486 response.
- section 5.1:
For a UA to defer to a proxy, it should report any
conditions back to the proxy (e.g., by means of a suitable response
to the INVITE request) rather than taking unilateral action such as
redirecting or placing the call in a waiting state. In other words,
it should be possible to turn off ACH at a UA.
Consider a case where there are multiple UAs (extensions) to which an
incoming call is parallel forked. And assume that each of them is
capable of unilateral handling of multiple calls via a mechanism that is
like call-waiting. If one extension has a call active and another is
idle then it may be preferable to ring the idle one first, rather than
have the first one pick up the second call. But to do so will require
that the proxy have some control over this. How would the UA defer to
the proxy, indicate that it is busy, and yet still indicate that it
*could* take another call if need be? And if it could so indicate, how
could the proxy later deliver the call to it again and indicate that it
should this time take the call?
>> - What does it mean to be busy? (This is related to prior
>> point.) Being on one call does not necessarily mean inability
>> to take another. Nor does *not* being on a call mean you are
>> not busy. In some cases it is literally possible to manage
>> two calls simultaneously. (E.g. when they are IM sessions.)
>> In other cases it is a matter of time division multiplexing
>> between two sessions, so that the callers will realize they
>> don't have full attention of the callee. Sorting this all out
>> wold seem to be a complex policy problem, requiring a lot of
>> data that won't easily be available to a proxy.
>
> The point of the draft is not for the proxy to decide that you
> are busy.
>
> It's for the UAS to indicate to the proxy that it's busy.
>
> Then it describes the subtleties of what busy means (600 vs
> 486, one branch vs all branches, can it go to voicemail, etc.).
>
> Basically, it means the user declares to be busy.
My question was intended to apply in the scenario I just spelled out
above. The point being that "busy" isn't necessarily a binary attribute.
Rather there can be degrees of busy-ness. 486 isn't currently capable of
expressing the nuances.
>> - rejection scope: It seems that there could be useful to
>> have two different degrees of local rejection. As currently
>> described in the draft it is proxy policy that determines if
>> local rejection cancels delivery to other local UAs or not.
>> But that could be something that might be desired as a per
>> call option to the user on the UA. (The distinction between
>> stopping only this extension from ringing, or stopping all
>> extensions from ringing.)
>
> I think doing this on a per call basis could be quite error-prone
> and complicated.
>
> And it would require new protocol.
>
> The reason the "degrees" are set on the proxy side in this draft
> is exactly to avoid those problems.
Whatever. I don't feel strongly about this.
Paul
_______________________________________________
BLISS mailing list
BLISS@...
https://www.ietf.org/mailman/listinfo/bliss
draft-ietf-bliss-ach-analysis-02.txt (73 bytes) 
