Subject: [BLISS] latest call-completion draft

From: "Huelsemann, Martin" <[email-masked]>
Date: Mon, 9 Jul 2007 13:52:16 +0200

Hi all,

the latest call-completion draft has been uploaded, as agreed call-completion was shifted to BLISS, so you can find the result under http://www.ietf.org/internet-drafts/draft-poetzl-bliss-call-completion-00.txt.

The main issue of the discussion on the mailing list was the usage of SUBSCRIBE bodies for queue manipulation actions (e.g. add, suspend, resume), which is not in accordance with RFC 3265.

The solution discussed was the scenario, where not answered calls (because of busy or no reply) are getting queued at the callee, and the caller is informed that he can receive call-completion information, which would inform him that he is either still queued, or that he can start the recall.

So what is described now is a proposal for a pure call-completion event package with the values 'queued' and 'ready-for-call-completion' (and an additional value for service retention), so no more queue manipulation parameters in the SUBSCRIBE body, and the proposed usage of the Allow-events in 180 and 486. 
Suspending and resuming would be done by un-subscribing and subscribing again to the call-completion event package.

Comments and questions are welcome.

Regards, Martin

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Jul 2007 17:09:14 -0400

[Removing sipping from the mailing list becasue cross posting is annoying.]

Thank you for producing this revised version! It goes a long way toward 
addressing the problems that have been raised before - at least those 
raised by me. I think the direction is quite reasonable now. I still 
have comments to make, but they are refinements.

General Issue:

IMO it isn't clear what resource the subscription is targeted to. From 
the text it seems that it is the *queue*. But that leads to problems 
about who is notified when. There is some implied relationship between 
subscribers and queue *entries* but that is not explained.

I think this would better modeled as subscription to queue *entries*. 
What is lacking is how the entry is referenced in the subscription 
request. I can see a couple of possibilities:

- the entry could be identified explicitly. E.g. there could be an event 
parameter containing the callid of the failing call that caused the 
queue entry to be made.

- it could be implicit - when the subscription request (to the AOR) is 
received and processed, an association to an entry could be made - 
perhaps by matching the From address of the subscriber with the From 
address of the caller.

I think either way can be made to work. What is needed is some text that 
explains this. Part of this is probably to be more explicit in modeling 
the queue itself - what it contains, when things are added and removed, 
etc. (This would also provide a place to identify odd cases, such as 
when a particular caller makes multiple call attempts to the callee. In 
that case, are multiple entries made in the queue, or what?)

If the subscription is modeled as being to an *entry* then many things 
get simpler and clearer. For instance one class of errors occurs when no 
matching entry can be found. The triggering event for a notification is 
then very simple - it is when the state of the *entry* changes from 
"queued" to "ready-for-call-completion".

Another small issue: there is no mention of how long a subscriber has to 
make a call completion attempt after receiving a 
"ready-for-call-completion" notification. Presumably at some point there 
is a state change back to queued, or the entry is removed altogether. It 
would be good to tell the subscriber about this. Perhaps the 
"ready-for-call-completion" notification could carry the amount of time 
allotted for the attempt. This also should probably also be part of the 
model of the queue.

The following are more localized comments about particular parts of the 
draft.

> 3. 
>     Overview 
>      
>     Completion of Calls on no Reply (CCNR) provides the cability to 
>     queue not answered calls from several callers to a callee and to 
>     inform the caller that he can initiate a call-completion call after 
>     the callee has become not busy after having initiated an activity. 

The above is a pretty narrow definition. Isn't the *goal* to inform the 
caller when the callee is available? In some implementations "callee has 
become not busy after having initiated an activity" may be the best that 
can be done to determine availability. But should that be enshrined in 
the specification?

For instance in some cases there may be other presence sources. E.g. if 
the callee device is a softphone on a PC then typing on the keyboard is 
also an indication of presence.

> 5.1 
>      Proposed solution 

>     ... A NOTIFY 
>     request that reports that the callee is available for a call-
>     completion call attempt to be made will cause the subscriber to 
>     trigger the establishment of that call, subject to the caller being 
>     available too. 

Its a stretch to say the notification will *cause* the subscriber to 
call. All it does is inform the caller that it *may* initiate a call 
with reasonable expectation of success.

How about:

"A NOTIFY request that reports the callee is available for a 
call-compleion call attempt to be made will inform the subscriber that 
it has an opportunity to attempt establishment of that call."

>     ... It is 
>     assumed that the call-completion service logic can distinguish 
>     between a new subscription and a resuming subscription, when there 
>     is an entry for the subscriber in the call completion queue. 

Why should it matter? Either somebody is interested in the entry, or 
nobody is.

If it really does matter (which I doubt) then the model of the queue, 
which I requested above, should explain what this extra state is and why 
it is important.

>  6.7 
>      Notifier Processing of SUBSCRIBE Requests 
>      
>     Upon receiving a subscription refresh, the notifier MUST set the 
>     "expires" parameter of the Subscription-State header to the current 
>     remaining duration of the subscription regardless of the value 
>     received in the Expires header (if present) of the subscription 
>     refresh.   

This needs to be changed somewhat for compliance with 3265. The response 
to the subscription refresh must not return a value larger than in the 
request.

I gather you don't want the subscription to remain once the queue entry 
it is associated with ages out of the queue. You *could* define the 
maximum value based on that time. Or you could just terminate the 
subscription, sending a final NOTIFY with Terminated status, when it 
ages out. It is probably better to do that, because otherwise the 
subscriber may decide that it needs to refresh the subscription just 
before it is about to age out.

>     If a subscription is not successful because the call-completion 
>     queue has reached the maximum number of entries (short term 
>     denial), the notifier MUST send a 480 Temporarily Unavailable 
>     response to the subscriber. 
>     If a subscription is not successful because a general error that 
>     prevents the call-completion service has occurred (long term 
>     denial), the notifier MUST send a 403 Forbidden response to the 
>     subscriber. 

I'm confused by this. As I understand it, the queue is populated as call 
attempts fail. I do understand that if the queue is full, it may be that 
another call attempt may fail to be queued.

But that has nothing to do with the subscription, which simply checks on 
the status of an entry in the queue. If an entry was not queued, due to 
the queue being full, then a subsequent subscription inquiring about 
that entry will be able to tell that there is no such entry, but won't 
be able to discern *why* the entry is absent. Nor will a subsequent 
subscription request somehow be able to get a different conclusion in 
this case.

Or are you limiting the number of subscribers to the event? Under normal 
circumstances one would expect that the number of subscriptions would be 
less than or equal to the number of entries in the queue. It would be 
unwise for an implementation to allow fewer subscriptions than that. 
There could be more, for valid or invalid reasons. A valid reason might 
be if the caller has multiple devices, using the same identity, that 
wish to track the same queue entry. An invalid reason would be when 
devices subscribe but have no entry in the queue.

The invalid case can be handled by 403 as you suggest, or by a 200 
response with a single NOTIFY that terminates the subscription and 
indicates no entry in the queue.

The valid case could be handled by 480 as you suggest.

Maybe this would all be clearer if you provide a sufficient model of the 
queue.

>  7.2 
>      service-retention 
>      
>     The service-retention indicates the support of the retain option.  
>     The retain option, if supported at the callee, will maintain the 
>     entry in the call-completion queue, if a call-completion call has 
>     failed due to destination busy condition.  If present, this 
>     parameter indicates that the retain option is supported, otherwise 
>     it is not supported.  This parameter MAY be present in NOTIFY 
>     requests. 

I'm confused about this "option". In what sense is it an option? I 
gather this is not an option requested by the subscriber or caller, but 
rather is an implementation choice on the part of the notifier. Is that 
right? So from the point of view of the subscriber this simply says what 
to expect after it tries and fails to make a call-completion call???

IMO this deserves more complete explanation, even if I got it right. It 
sounds like there might be two different models for queue management. If 
so, when modeling the queue you should show both models and specify that 
a node may choose (or be configured) to support one or the other.

> 8. 
>     Signaling Flows 

All the NOTIFYs have the To/From URIs interchanged. (The To/From of the 
NOTIFY should be reversed from that in the SUBSCRIBE.)

>  9. 
>      Security Considerations 

Given the intended usage, I think it might be better to give more 
guidance. In particular I suggest that in the absence of some explicit 
policy to the contrary, subscriptions SHOULD only be allowed from the 
same identity that made the original call attempt.

	Thanks,
	Paul

Huelsemann, Martin wrote:
> 
> 
> Hi all,
> 
> the latest call-completion draft has been uploaded, as agreed 
> call-completion was shifted to BLISS, so you can find the result under 
> _http://www.ietf.org/internet-drafts/draft-poetzl-bliss-call-completion-00.txt_.
> 
> The main issue of the discussion on the mailing list was the usage of 
> SUBSCRIBE bodies for queue manipulation actions (e.g. add, suspend, 
> resume), which is not in accordance with RFC 3265.
> 
> The solution discussed was the scenario, where not answered calls 
> (because of busy or no reply) are getting queued at the callee, and the 
> caller is informed that he can receive call-completion information, 
> which would inform him that he is either still queued, or that he can 
> start the recall.
> 
> So what is described now is a proposal for a pure call-completion event 
> package with the values 'queued' and 'ready-for-call-completion' (and an 
> additional value for service retention), so no more queue manipulation 
> parameters in the SUBSCRIBE body, and the proposed usage of the 
> Allow-events in 180 and 486.
> 
> Suspending and resuming would be done by un-subscribing and subscribing 
> again to the call-completion event package.
> 
>

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Wed, 11 Jul 2007 08:24:22 +0200

Hi all,

the latest call-completion draft has been uploaded, as agreed 
call-completion was shifted to BLISS, so you can find the 
result under 
http://www.ietf.org/internet-drafts/draft-poetzl-bliss-call-completion-00.txt.

The main issue of the discussion on the mailing list was the 
usage of SUBSCRIBE bodies for queue manipulation actions 
(e.g. add, suspend, resume), which is not in accordance with RFC 3265.

The solution discussed was the scenario, where not answered 
calls (because of busy or no reply) are getting queued at the 
callee, and the caller is informed that he can receive 
call-completion information, which would inform him that he 
is either still queued, or that he can start the recall.

So what is described now is a proposal for a pure 
call-completion event package with the values 'queued' and 
'ready-for-call-completion' (and an additional value for 
service retention), so no more queue manipulation parameters 
in the SUBSCRIBE body, and the proposed usage of the 
Allow-events in 180 and 486. 
Suspending and resuming would be done by un-subscribing and 
subscribing again to the call-completion event package.

Regards, Martin

---

From: "Huelsemann, Martin" <[email-masked]>
Date: Tue, 17 Jul 2007 18:17:52 +0200

Hi Paul,

I've never seen the mail in my BLISS folder, but it's in the BLISS archive, so I think it works when I answer on the list.

A lot of comments, thanks. The answers are included in the text below.

One major issue for the next revision seems to provide a more exact explanation of model for the queue.

Shortly:

When a call ends in busy, a queue entry is created (to which the caller can subscribe). 

The queue entry is deleted after timer expiry, or during the call-completion attempt. For the latter there are two options: 

1) every call-completion attempt deletes the entry, or 

2) only a successful call-completion attempt (the callee is not busy again) deletes the entry

The caller has to be informed, which option is true.

Regards, Martin

> -----Ursprüngliche Nachricht-----
> Von: Paul Kyzivat [mailto:[email-masked]] 
> Gesendet: Dienstag, 10. Juli 2007 23:09
> An: Hülsemann, Martin
> Cc: [email-masked]; [email-masked]; 
> [email-masked]; [email-masked]; 
> [email-masked]; Alexeitsev, Denis; 
> [email-masked]; [email-masked]; [email-masked]
> Betreff: Re: latest call-completion draft
> 
> 

I have no strong opinion to this, except the fact that there is explaining text missing, because the intention really is to subscribe to a certain entry.
To keep it simple, a correlation between the From headers of caller and subscriber might be sufficient. 
The other option you mentioned is not quite clear to me. It would have to be a parameter transported somehow in the 486 or the 180. Is it possible to use a special event parameters with the Allow-events header?

> "queued" to "ready-for-call-completion".

Once a caller has subscribed to a certain entry and calls again, different implementations in the service logic are possible:
- the existing entry can be deleted, a new entry can be created and Allow-events is again included in the response
- the existing entry is not deleted, Allow-events is not included in the response; the entry matures and is deleted after timer expiry.

In my opinion the second possibility is the better one (this is also the way it is mostly done in the PSTN, and this is how I woulk like to have ot done), but I didn't want to prescribe the solution in the draft. If people think it's better to have some normative text (for the second possibility, timer expiry) in the draft, I can include that in the next revision.

> allotted for the attempt. This also should probably also be 

There is a timer for this attempt, if there is no recall in this time the state chages to queued again and the subscriber is informed. I think we can do without the indication of the granted time for the call-completion attempt, the subscribers will realize that this time is limited after their state has changed back to 'queued' several times. But if people would like this indication, it's noted for the next revision.

> can be done to determine availability. But should that be 

Yes, 'become not busy after some activity' is the PSTN trigger. There are of course other triggers. The text has to be modified.

> it has an opportunity to attempt establishment of that call."

Noted for the revision.

> which I requested above, should explain what this extra state 

I have received comments that asked for this correlation. I see also a advantage for the interworking with the PSTN, where Suspend and Resume are different messages. We can discuss if the reference to the optional usage of etags is useful for the call-completion draft. I haven't really a strong opinion.

> before it is about to age out.

Yes, this has to be changed. 
It has to be avoided that there is a subsription when there is no queue entry any longer. So what is really meant is that
"Upon receiving a subscription refresh, the notifier MUST set the "Expires" parameter of the Subscription-State header to the current remaining duration of the subscription or to the value received in the Expires header (if present) of the subscription refresh, if this value is less then the remaining duration."
So the maximum for the refresh would be the remaining duration, or a value less then that if the user thinks that a call-completion notification doesn't make sense for him longer.

> Maybe this would all be clearer if you provide a sufficient 

The model of the queue is a limited number of queue entries which are generated when a particular call fails. To this queue entries the regarding callers can subscribe, so that in fact the number of subscriptions is less than or equal to the number of entries in the queue.
However, regardless the fact that the caller was informed with 'Allow-events' of the possibility to subscribe to the queue entry, there might occur error conditions, which means the queue entry doesn't exist anymore when the SUBSCRIBE is received. This especially occurs at the interworking with the PSTN, where you are just informed about the general availability of the call-completion service, but your activation request can fail because the queue is already full. So for the interworking of the PSTN 'short term denial' and 'long term denial' the 403 and the 480 would be very helpful. But I think also in a pure SIP environment, which this draft of course aims for, such errors can occur, for the reasons you mentioned.

> a node may choose (or be configured) to support one or the other.

The option here is wether a queue entry is deleted when call-completion is just attempted or when call-completion is attempted successfully. Also a call for call-completion can end in busy, if there was another call to the callee after the NOTIFY 'ready-for-call-completion' was sent. 
In the case the entry is deleted at every attempt, successful or not, and the callee is busy again, the normal procedure would be that the subscription would have to be terminated when the entry is deleted by sending the final NOTIFY, and more or less at the same time a new Allow-events would have to be sent.
The usage of the service-retention parameter avoids these complicated procedures and informs the user before the call-completion attempt if his queue entry remains or not in case of a not successful attempt. 
And, you guess it, this parameter is also needed for the PSTN interworking, where the user is also informed before the call-completion attempt, if his call-completion request remains activated in case of a failure. So when the call fails, there is no new 'CCBS possible' indication which could be mapped into a new 'Allow-events:call-completion'.

> NOTIFY should be reversed from that in the SUBSCRIBE.)

Yes, thanks, noted for the revision.

> same identity that made the original call attempt.

Okay. Other comments/suggestions?

> 'ready-for-call-completion' (and an 
> subscribing

---

From: [email-masked]
Date: Thu, 19 Jul 2007 22:40:22 -0400

From: "Huelsemann, Martin" <[email-masked]>

   the latest call-completion draft has been uploaded, as agreed
   call-completion was shifted to BLISS, so you can find the result
   under
   http://www.ietf.org/internet-drafts/draft-poetzl-bliss-call-completion-00.txt.

As a big nit, the text seems to have been put through something that
has altered the formatting a great deal.

Technically, I think it would help to clean up the Requirements
section.  As written, it mixes details of the mechanism (e.g., "In
this case the state of the caller changes from 'queued' to
'ready-for-call-completion' and the caller will be informed
accordingly.") with the actions it is to support.  A careful
enumeration of the high-level operations would be quite helpful.

Also, I don't see a discussion of how the "queue manipulation
operations" are performed.  Maybe those are implicit.  But I get the
feeling that the author understands how CCBS works so intuitively that
he is not spelling out the algorithms and interactions in the
necessary detail.

Dale