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

[Miguel Garcia <[e-mail]>]

Good. I have done these changes. There are a couple of requirements that 
are listed under the Suspension, but they affect other areas as well... 
but it is not so important.

/Miguel

Schmidt, Christian wrote:

> 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