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

[Tessa Silvia <[e-mail]>]

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
[e-mail]. Thank you
====================================================================

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