Re: [BLISS] I-D Action:draft-ietf-bliss-ach-analysis-02.txt

 

> -----Original Message-----
> From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] 
> On Behalf Of Francois Audet
> Sent: 31 May 2008 01:39
> To: Paul Kyzivat; bliss@ietf.org
> Subject: Re: [BLISS] I-D Action:draft-ietf-bliss-ach-analysis-02.txt
> 
> 
>  
> 
> > -----Original Message-----
> > From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] 
> > On Behalf Of Paul Kyzivat
> > Sent: Saturday, May 24, 2008 12:23
> > To: bliss@ietf.org
> > 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.
[JRE] Agreed. When it receives an INVITE request when the user is
"busy", it can either perform call waiting locally or simply reject as
busy (486). Knowledge that ACH is performed at the proxy may influence
which of these options to take, but it is a UAS decision.

> 
> > - 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.
[JRE] Agreed.

> 
> > - 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.
[JRE] We already have two degrees - local and global. Introducing a
third degree would seem to make it too complicated.

John
_______________________________________________
BLISS mailing list
BLISS@ietf.org
https://www.ietf.org/mailman/listinfo/bliss