Subject: [BLISS] Call completion

From: [email-masked]
Date: Fri, 26 Oct 2007 15:45:47 -0400

draft-poetzl-bliss-call-completion-00 discusses implementing Call
Completion services within SIP.  Largely, it defines an event package
which is used by the caller's agent and the callee's agent to
implement orderly Call Completion services.

I was invited to add a section to the I-D to describe in more detail
the procedures that are involved in Call Completion, which form the
context within which the call completion event package is used.

Nobody will be surprised that describing call completion exactly took
a lot more text than I was expecting, 4 pages, and revealed a number
of open questions.

So instead of going to the work of integrating my draft text into the
rather finished text of draft-poetzl-bliss-call-completion-00, only to
have to later make a lot of technical corrections, I decided to float
the draft text on its own and get it technically correct before I do
the integration work.

I've submitted the description of the call-completion mechanism as a
separate draft, draft-worley-call-completion-00.  You can get it from
http://www.ietf.org/internet-drafts/draft-worley-call-completion-00.txt.
Please critique it.

                 Call Completion Implementation Details
                    draft-worley-call-completion-00

Abstract

   This paper gives a detailed discussion of the implementation of "call
   completion on busy subscriber" and "call completion on no reply" to
   flesh out the proposed call completion event package.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Outline  . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Detailed Description . . . . . . . . . . . . . . . . . . . . .  5
     3.1.  Caller's Call-Completion Agent . . . . . . . . . . . . . .  5
     3.2.  Callee's Call-Completion Monitor . . . . . . . . . . . . .  5
     3.3.  The Original Call Is Made  . . . . . . . . . . . . . . . .  6
     3.4.  Call-Completion Is Invoked . . . . . . . . . . . . . . . .  6
     3.5.  The Call-Completion Request Is Queued  . . . . . . . . . .  8
     3.6.  Call-Completion Is Activated . . . . . . . . . . . . . . .  8
     3.7.  Data Provided in the Call-Completion Event Package . . . .  9
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   5.  Normative References . . . . . . . . . . . . . . . . . . . . . 11
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
   Intellectual Property and Copyright Statements . . . . . . . . . . 13

Dale

_______________________________________________
BLISS mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bliss

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 26 Oct 2007 17:51:07 -0400

Dale,

I'm glad to see this! The Poetzl document doesn't stand well as it is, 
it has way too many assumptions.

General comment:

There has been extensive discussion on the list of how to map the 
semantics of the queue at the callee with the subscriptions. I do thing 
we figured it out, but it remains unclear in this document, and in 
draft-poetzl-bliss-call-completion-00.

The key is that you subscribe to a particular resource, and then the 
subsequent notifications are about the state of that resource. Initially 
people were thinking that it was the *queue* that was being subscribed 
to. Eventually, IIRC, we concluded that the resource needs to be a 
particular entry in the queue - the entry for a specific callid.

That solves many problems. It means you can return a 404 if there is no 
entry for that callid, whereas a 404 wouldn't make much sense if you 
were subscribing to the queue. Also, it means that when a particular 
queue entry change state from "queued" to "ready-for-call-completion" a 
notify is sent to subscribers for that entry, but not to other subscribers.

I don't think anything in your document or Poetzl's is *inconsistent* 
with this model, but its not clear what the model is, and I expect it 
needs to be.

Section 3.2:

    The callee's monitor has a method of monitoring the status of the
    UA(s) to determine when they are in a suitable state to receive a CC
    call.  This state may vary depending on the type of CC call in
    question.  E.g., a UA is available for CCBS when it is not busy, but
    a UA is available for CCNR when it becomes not busy after being busy
    with an established call.  This monitoring may be achieved by
    subscribing to the dialog event package of the UA(s) or by other
    means.

Note it is the act of being busy that can be used to infer presence, and 
the act of becoming unbusy that is assumed to indicate availability for 
a call completion. This is a very poor means of determining presence, 
since the callee could be sitting beside the phone for hours without 
being involved in a call. If some other means of determining presence is 
available, one would hope it would be used.

Its also not entirely reasonable to assume that being busy implies not 
being available for call completion. With multiple lines, or call 
waiting, it may be possible to take a call completion even when busy. 
This is again an issue of presence - another means of determining 
availability could override this inference.

Section 3.4:

    Question: At this point, it seems that the best choice is that the
    caller's agent need not determine what type of CC is being requested
    (CCNR vs. CCBS), as (1) it cannot determine this from the INVITE
    final response, (2) it would be a burden to make the calling user to
    specify it, and (3) the callee's monitor can determine this from the
    responses returned by the callee's UAs.

Again, this is all about presence. Regardless of the reason for the 
original failure, the proper condition for attempting call completion is 
  a high probability that the callee is *present* and *available*. 
Available is typically inferred based on unbusiness of the phone. 
Presence is inferred from having recently been busy. The only reason I 
can see for distinguishing CCNR from CCBS is that CCBS is an assertion 
by the caller that the callee is present, which CCNR is an assertion by 
the caller that the callee is not present at that time. If the callee 
monitor has better information about that, great.

These inferences aren't very good in the best of cases, and they break 
down fast in more complex cases:

- As I mentioned above, not being busy is a poor indicator of not being 
present - the user could be sitting next to the UA but not using it.

- the phone being in an invite dialog is not a perfect indicator of 
unavailability. The user may still want to take the call from the person 
waiting for completion.

- Not being busy is also a poor indicator of being available. Consider 
someone with multiple phones, or phone with multiple AORs. It can be 
quite common to hang up from one call and take a call on another line. 
This may make you unavailable for taking calls on the AOR in question.

- The value of the caller assertion (via distinguishing CCBS from CCNR) 
that the callee is/isn't present degrades with time. Immediately after 
the call attempt is has some relevance. An hour later it probably has none.

All in all, I think the concept ought to be a request to attempt call 
completion when there is an acceptably high probability that the callee 
is present and available to answer.

    Question: Should the specification of the original call be done in
    the SUBSCRIBE body rather than in an event-param?

Conceptually the callid is part of the specification of the resource 
being subscribed to, rather than being a qualifier to how the 
subscription is processed. So perhaps it ought to be a URI parameter. 
But if not that then a parameter to the event type seems better to me. 
Putting it in the body would imply that it is a filter.

    The call-completion event package returns various information to the
    caller's agent, but the vital datum is that it contains an indication
    whether the callee's monitor has chosen the caller's agent to perform
    the next CC call to the callee.  This datum is initially false.

By "initially" do you mean in the initial notification to the 
subscription? It *could* be true then.

Section 3.6

    The callee's monitor has a policy regarding when and how it selects
    CC requests to be activated.  This policy may take into account the
    type of the requests (CCNR vs. CCBS), the state of the callee's
    UA(s), the order in which the original calls arrived, and any
    previous CC attempts for the same original call.

The order in which subscriptions were received could also be a factor.

    Question: Should the callee's monitor supply a URI which should be
    used in the CC call?  This seems like it would be more reliable, as
    the monitor is probably "for" a particular callee URI, and it has no
    information about the destinations of any other forks of the original
    call.

Yes, I think this is an excellent idea.

    Question: The CC must be marked in some way as a CC call in order for
    the callee's monitor to know that the CC activation is being acted
    upon by the caller's agent.  And the marking must include the
    original Call-Id to allow correlation with the original call.
    Possibilities for a marking are a special URI-parameter on the
    request URI or a special header.

Its not entirely clear to me that the monitor *needs* to know that this 
call is a completion for some missed call. What bad thing would happen 
if it didn't know that?

BUT, one way to kill two birds with the same stone would be to provide a 
URI that routes to the callee monitor, and that references the call to 
be completed in some way. (This could be encoded in some way that 
prevents cheating.) The monitor could then forward the call to the 
appropriate destination, using whatever local tricks are needed to give 
it the appropriate priority - tricks that aren't available to normal 
incoming calls.

	Thanks,
	Paul

---

From: [email-masked]
Date: Mon, 29 Oct 2007 15:47:53 -0500

From: Paul Kyzivat <[email-masked]>

   General comment:

Yes, I need to work that through.  But initially, the purpose of this
I-D is to lay out what the machinery is for doing call-completion,
within which the specifics of the subscriptions and of the event
package must function.

The machinery is implied by a short paragraph in draft-poetzl, and the
working-out of it is straightforward, but as always, when you work out
the details, you discover things.  Such as "The SIP response to the
original INVITE tells you almost nothing about call-completion status,
because the reponse may not be from the UA that supports call
completion."

Once the machinery is clarified, it will be time to re-examine the
specifics of the subscription mechanism.

That's the explanation of what I'm trying to accomplish.  Response to
your detailed observations to come...

Dale

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Tue, 30 Oct 2007 17:02:10 +0100

Dale,

thank you very much for this work and the time you have taken.

A general comment at the beginning, following Paul's comment:

The concept is to subscribe to one's call completion state, which can have the values 'queued' or 'call completions active' (ready for recall in the current document). The call completion state usually is derived from the queue-state, if you are in you are queued, if you are at the top you are ready for recall. Anyway the important information for the user is that he has some state regarding call-completion, and when he can start the CC call.

Sections 3.1, 3.2.

I think there are many possible ways to check the availibity of the callee to receive a call-completion call as well for the caller to start a call-completion call. One solution that probably crosses one's mind at once is the dialog event package. Anyway I think we shouldn't be to explicit on that, there are many ways to implement this. 
This applies in particular for the availibility of the callee. As Paul said, at some time the state of the callee changes to a state where 'an acceptably high probability that the callee is present and available to answer' to a CC call from a certain user (where CC is active) is reached. CC informs the caller about that state change.

As Paul said it's a specification of the resource so a URI parameter would be a good solution. Could the Target-dialog header also be used for this?

Section 3.6

	Question: Is that last statement true?  Can a call appear to succeed
   	from the monitor's point of view but fail from the calling user's
   	point of view?

I think we have to be pragmatic at some point not to let CC become too complex. I suggest the monitor's point of view should be the criteria if CC was successful.

Section 3.7

The important CC information is if you are queued, and if you shall start the CC call. And the service retention information to inform the user if he is still in the CC queue when the CC call has failed, depending on the CC implemention. It is also needed for interoperability reasons.

Again thanks a lot.

BR, Martin

> -----Ursprüngliche Nachricht-----
> Von: [email-masked] [mailto:[email-masked]] 
> Gesendet: Freitag, 26. Oktober 2007 21:46
> An: [email-masked]
> Betreff: [BLISS] Call completion
> 
> 
Please critique it.

Abstract

Table of Contents

Dale

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Tue, 30 Oct 2007 17:15:10 +0100

> call is a completion for some missed call. What bad thing 
If there are still entries in the queue the callee's monitor shouldn't accept calls without this CC indication. Otherwise there could be the situation that immediately after the callee has become available there are other calls which are answered then, and the user who requested CC will never have a chance to complete the call.

BR, Martin

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 30 Oct 2007 14:16:45 -0400

> If there are still entries in the queue the callee's monitor shouldn't accept calls without this CC indication. Otherwise there could be the situation that immediately after the callee has become a…

You are making an assumption about the "monitor" that Dale didn't make:

You are assuming that calls flow through it before reaching the callee, 
and that the monitor can thus prevent those from being accepted.

If that is a key part of the mechanism then it needs to be specified 
somewhere.

	Thanks,
	Paul