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

From: [email-masked]
Date: Sat, 24 May 2008 10:45:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Basic Level of Interoperability for SIP Services Working Group of the IETF.

	Title           : An Analysis of Automatic Call Handling Implementation Issues in the Session Initiation Protocol (SIP)
	Author(s)       : J. Elwell
	Filename        : draft-ietf-bliss-ach-analysis-02.txt
	Pages           : 18
	Date            : 2008-05-24

This discusses problems associated with automatic call handling (ACH)
when using the Session Initiation Protocol (SIP).

This work is being discussed on the [email-masked] mailing list.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-bliss-ach-analysis-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 24 May 2008 15:23:25 -0400

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.

- 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.

- 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.)

	Thanks,
	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 30 May 2008 19:38:36 -0500

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Paul Kyzivat
> Sent: Saturday, May 24, 2008 12:23
> To: [email-masked]
> 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.

> - 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.

> - 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.
_______________________________________________
BLISS mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/bliss