[Sipping-tispan] AW: CCBS/CCNR in Version -02f

["Schmidt, Christian" <[e-mail]>]

Hi Miguel,

What do you think about following structure:

Invocation:

   REQ-CCBS/CCNR-1:  In order to assure that end-to-end functionality of
                     the CCBS/CCNR services is possible, there must be a
                     mechanism whereby the caller gets knowledge of the
                     availability of the CCBS/CCNR service at the callee
                     or the PSTN/ISDN terminal on a communication by
                     communication basis.

   REQ-CCBS/CCNR-xx: The caller must be able to invoke CCBS / CCNR
service.


Control of callee status and information to the caller:

   REQ-CCBS/CCNR-2:  The CCBS/CCNR simulation service should be able to
                     handle queues and arbitrate multiple simultaneous
                     CCBS/CCNR requests according to a locally defined
                     policy (e.g., first in first out).

   REQ-CCBS/CCNR-3:  The entity providing the CCBS/CCNR service needs to
                     know the change of the status at the callee's
                     (e.g., in CCBS a transition when the callee sends
                     or receive a BYE request for an existing session;
                     in CCNR any activity indicated by the presence of
                     the user, such as a key press or any other
                     interaction with the device).

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

   REQ-CCBS/CCNR-11: The CCBS/CCNR service duration timer expires after
                     a certain time controlled by the entity providing
                     the CCBS/CCNR service.

   REQ-CCBS/CCNR-12: Any communication performed as a result of the
                     execution of a CCBS/CCNR request should be
                     distinguishable from regular communications.
			   This can be used to priorize CCBS/CCNR calls
towards the callee.

   REQ-CCBS/CCNR-5:  The CCBS/CCNR service must be able to inform the
                     caller when the service-specific condition related
                     to the callee's state is met.

   
Suspend State:

   REQ-CCBS/CCNR-4:  Similarly, the entity providing the CCBS/CCNR
                     service needs to know the change of the status at
                     the caller's (e.g., to find out when a pending
                     CCBS/CCNR request can be resumed or to allocate a
                     time-slot to execute a pending CCBS/CCNR request).

   REQ-CCBS/CCNR-7:  Should the caller be busy at the time of executing
                     CCBS/CCNR request, the request is suspended until
                     its status changes (back to free status).

   REQ-CCBS/CCNR-8:  During the period of time when a CCBS/CCNR request
                     is in suspended state for a given caller, no other
                     CCBS/CCNR request execution must be performed for
                     that caller.

   REQ-CCBS/CCNR-9:  A suspended CCBS/CCNR request is resumed when
                     caller's status changes to non-busy.  The new place
                     in the queue of that subscription is chosen
                     according to a local policy.

   REQ-CCBS/CCNR-10: The suspension of a CCBS/CCNR request of a user
                     must not impact other users in the same queue for
                     the same callee.

   REQ-CCBS/CCNR-13: There must be a mechanism whereby CCBS/CCNR request
                     initiators can check or cancel their pending CCBS/
                     CCNR requests.

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



> 




> For the benefit of the reader, I would recommend to structure the
> requirements. For example in gathering
> requirements arround pending CCBS/CCNR requests in a block.

Good idea. So far I have been trying to draft the requirements in 
sequential order. I thought this would be easier to understand. Can you 
indicate what would be the suggestion for better understand? I mean, 
which groups will you form and which requirements will you group?

BR,

       Miguel
> 
> Regards,
> Christian
> 
> 
> 

-- 
Miguel A. Garcia           tel:[phone]
sip:[e-mail]
Nokia Research Center      Helsinki, Finland


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