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

[Miguel Garcia <[e-mail]>]

Hi Silvia:

Inline discussion.

Tessa Silvia wrote:

> 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? 

ok, I will collapse them.

> 
> 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).

Ok, sounds good.

> 
> 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.

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.
> 
> 
> ? 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). 

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.

> REQ-CCBS/CCNR-4b: During a caller suspension time no CCBS/CCNR request
> execution must be perfomed for that caller. 

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

> 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.

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".

> 
> 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.

Ok.

> 
> 
> 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.

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.

> 	
> 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 ?)

ok.

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

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


> 
> 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
> 

-- 
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