Subject: [Sipping-tispan] [CCBS/CCNR] Requirements 02d

From: Tessa Silvia <[email-masked]>
Date: Thu, 08 Sep 2005 17:45:33 +0200

Hi,
some comments and additional requirements on the CCBS/CCNR requirements.

Requirement 3 (callee able to indicate its status changes) was slightly
similar to req 5 (caller and callee able to indicate thier status
changes), can they collapse? 

I see a new issue here: CCNR and CCBS needs to know callee capabilities
to indicate its status change in different moment of call setup: while
CCBS needs to know upon final response to the INVITE transaction, CCNR
needs to know already in early state. To explain the requirement a
little bit further: a user can request CCNR in the alerting phase,
without waiting for a service timeout to expire. Maybe this needs some
changes in the description as well, but for now my proposal is:

REQ-CCBS/CCNR-3:  The entity providing the CCBS/CCNR service needs to
learn the capability of callee's UA to provide an indication of its
change of status not later than upon failure response (CCBS) or not
later than the alerting phase (CCNR).

Some questions about req-4:

? Is the requirement "the entity providing the CCBS/CCNR service needs
to know the status of the caller at the time of allocating a initiating
the CCBS/CCNR request."  really necessary ? 

The entity might also try without knowing the caller state and see the
outcome. Note that even if the entity does know the state, there's still
a race condition (the caller may become busy while the service is
trying) so the entity must be ready to react to a busy state.

? When the caller is busy, the entity does not dequeue the caller, it
suspends his CCBS/CCNR subscription (actually this is the only case when
it is suspended. 
Moreover, we have not stated what is supposed to happen when the caller
is not busy but, nevertheless, communication fails (e.g. not responding,
declines...). The requestor should be dequeued.

I put letters in the additional requirement numbering, in order to keep
it aligned with 02d version, hoping this makes it easier. 
I'll try to add some suspension details. What about:
 
REQ-CCBS/CCNR-4a: Should the caller be busy at its CCBS/CCNR execution
time, caller is suspended in the queue, until its status changes (back
to free status). 
REQ-CCBS/CCNR-4b: During a caller suspension time no CCBS/CCNR request
execution must be perfomed for that caller. 
REQ-CCBS/CCNR-4c: If, when a caller CCBS/CCNR subscription is suspended,
other callers are in the queue for the same callee, they must be served.

REQ-CCBS/CCNR-4d: A suspended CCBS/CCNR subscription is resumed when
callers status changes back. The new place in the queue of that
subscription is chosen according to a local policy.

If we remove req 7 as it has been suggested, we are loosing a
requirement upon CCBS/CCNR subscriptions life time: is that what we
meant ? Otherwise, would everyone be happy with the following ?

   REQ-CCBS/CCNR-7:  The entity providing CCBS/CCNR service must be able
to choose the expiration time of a CCBS/CCNR subscription.
	
A user has no right to suspend and resume his position according to
CCBS/CCNR service,  we have already discussed it and it seemed ok to
have two different requirements:

REQ-CCBS/CCNR-10: There must be a mechanism whereby CCBS/CCNR request
initiators can check and cancel their CCBS/CCNR subscriptions.
(or maybe a negative requirement that initiators can not suspend and
resume their CCBS/CCNR subscription ?)

REQ-CCBS/CCNR-10b: There must be a mechanism whereby the entity
providing CCBS/CCNR service can suspend, resume and cancel CCBS/CCNR
subscriptions.

regards
silvia

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to
[email-masked]. Thank you
====================================================================

_______________________________________________
Sipping-tispan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sipping-tispan

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 09 Sep 2005 14:51:20 +0300

Hi Silvia:

Inline discussion.

> changes), can they collapse? 

ok, I will collapse them.

> later than the alerting phase (CCNR).

Ok, sounds good.

> trying) so the entity must be ready to react to a busy state.

Yes, I agree with you. So basically, what we are saying is that this 
requirement REQ-CCBS/CCNR-4 is an optimization: if the service knows 
that the caller is busy at the time he can get a timeslot, the service 
works faster by skipping him. But as you said, the service must be ready 
to react to a busy state from the user.

So I think we can conclude that we should smooth the wording to indicate 
that this is an optimization.

So then, requirement 3 does not affect the caller, because there is not 
requirement to know the status of the caller.
> time, caller is suspended in the queue, until its status changes (back

I will write the requirement, but I would also add a few definitions. 
Especially we need to define what the "suspend CCBS request means", it 
is not clear what it means.

> execution must be perfomed for that caller. 

Ok, as well. But we also need to define "CCBS/CCNR request" execution.

> other callers are in the queue for the same callee, they must be served.

ok, I preferred this other better wording: "the suspension of a 
CCBS/CCNR request of a user must not impact other users in the same 
queue for the same callee".

> subscription is chosen according to a local policy.

Ok.

> to choose the expiration time of a CCBS/CCNR subscription.

Here you are having the assumption that the CCBS/CCNR service will be 
implemented with a subscription/notification model, which probably is 
true, but from the requirements point of view we should be a bit more 
agnostic.

Perhaps a better wording is:

    CCBS/CCNR requests expire upon a certain time controlled by the 
entity providing the CCBS/CCNR service.

> resume their CCBS/CCNR subscription ?)

ok.

> providing CCBS/CCNR service can suspend, resume and cancel CCBS/CCNR

I think that the initiator should be informed if his request has been 
cancelled (at least cancelled). What do you think?

I am writing all these in a new version that will be released later today.

/Miguel

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland