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

From: Tessa Silvia <[email-masked]>
Date: Fri, 02 Sep 2005 13:30:18 +0200

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

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

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

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
[email-masked]. Thank you
====================================================================

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

---

From: Miguel Garcia <[email-masked]>
Date: Fri, 02 Sep 2005 15:05:20 +0300

Hi Silvia, inline comments.

> (this last scenario is known as "suspension")

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.

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

> 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

-- 
Miguel A. Garcia           tel:+358-50-4804586
sip:[email-masked]
Nokia Research Center      Helsinki, Finland