Re: R: [Sipping-tispan] [CCBS/CCNR]

[Miguel Garcia <[e-mail]>]

Hi Silvia, inline comments.

Tessa Silvia wrote:

>>>- A bit more elaboration on the queue management, precisely,
>>>what are the implications for the service (I think there is
>>>the concept of a "timeslot" in which a user can return a
>>>call, and if it doesn't happen, the user misses his turn in
>>>the queue ... or somethign like that.
>>
>>How about:
>>
>>The submission of a CCBS/CCNR queue request must include a time limit.
>>
>>The CCBS/CCNR queue service may adjust the request time limits based
> 
> on
> 
>>local policy.
> 
> 
> 
> Actually, I've interpreted Miguel's "timeslot" as follows :
> 
> Any time a user does not accept a session returned by CCBS within a
> given timeslot his place in queue is removed, unless he is busy.
> 
> Any time a user is busy when a session returned by CCBS is delivered, he
> keeps his place in queue. Other users in queue, if any, can be served.
> (this last scenario is known as "suspension")
> 
> Would that be ok ?

Works for me. As I said before, I think the explanation of this service 
requires quite a few definitions, and the "suspension" is one of them.

> 
> 
>>>- A definition of a "CCBS/CCNR request", which at the moment,
>>>misleads me in the interpretation of the service. It can mean
>>>two different
>>>things: "Please add me to the CCBS/CCNR queue of the callee",
>>>or "this is a session returned as a result of an indication
>>>from CCBS/CCNR".
> 
> 
> 
> The "CCBS/CCNR request" as I read it in the draft, is used as "Please
> add me to the CCBS/CCNR queue of the callee": it's a request to monitor
> a user status changes, not a call. If it's not clear enough, we could
> replace it in the requirements with "CCBS/CCNR subscription": would that
> be easier or is it even more confusing?

For me it would be easier to understand. Especially if you assume that 
this service will require a subscription/notification implementation.


> 
> 
>>and:
>>
>>The CCBS/CCNR callee must have the means to inform a queued caller
> 
> that
> 
>>the callee is free along with the means for the caller to originate
> 
> the
> 
>>subsequent session setup such that it can be distinguished by the
> 
> callee
> 
>>from other possible session setups.
> 
> 
> The requirement is not strictly for the caller to be notified of the
> callee status, nor for him to setup the call, in my opinion it  should
> just be:
> 
>   The CCBS/CCNR simulation service should be able to deliver a
> communication to the caller, when the service-specific condition related
> to user state is met. Any communication performed as a result of a
> CCBS/CCNR should be distinguishable from regular calls.

Sounds good. The two sentences constitute two different requirements, 
but they are fine.

I will try to combine all the comments and post an update with a proposal.

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

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