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

Tessa Silvia <Silvia.Tessa@TILAB.COM> Fri, 02 September 2005 11:33 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB9nU-0000R3-Av; Fri, 02 Sep 2005 07:33:28 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EB9nS-0000Qt-IH for sipping-tispan@megatron.ietf.org; Fri, 02 Sep 2005 07:33:26 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA00249 for <sipping-tispan@ietf.org>; Fri, 2 Sep 2005 07:33:25 -0400 (EDT)
Received: from dns2.tilab.com ([163.162.42.5]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EB9pb-0007Ak-B1 for sipping-tispan@ietf.org; Fri, 02 Sep 2005 07:35:39 -0400
Received: from iowa2k01b.cselt.it ([163.162.242.202]) by dns2.cselt.it (PMDF V6.1 #38895) with ESMTP id <0IM600E9DSRAV3@dns2.cselt.it> for sipping-tispan@ietf.org; Fri, 02 Sep 2005 13:18:46 +0200 (MEST)
Received: from EXC01A.cselt.it ([163.162.4.198]) by iowa2k01b.cselt.it with Microsoft SMTPSVC(6.0.3790.211); Fri, 02 Sep 2005 13:31:11 +0200
Date: Fri, 02 Sep 2005 13:30:18 +0200
From: Tessa Silvia <Silvia.Tessa@TILAB.COM>
Subject: R: [Sipping-tispan] [CCBS/CCNR]
To: "Michael Hammer (mhammer)" <mhammer@cisco.com>, Miguel Garcia <Miguel.An.Garcia@nokia.com>, sipping-tispan@ietf.org
Message-id: <DCB4E22C68A78643A9550CC8E381128F01012B5B@EXC01A.cselt.it>
MIME-version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.3790.326
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: quoted-printable
Importance: normal
Priority: normal
Thread-Topic: [Sipping-tispan] [CCBS/CCNR]
Thread-Index: AcWu4um+T6SzZUQ/QNOHd1bD6CeBdgAOspqAACTVQfA=
Content-class: urn:content-classes:message
X-OriginalArrivalTime: 02 Sep 2005 11:31:11.0234 (UTC) FILETIME=[D1B59E20:01C5AFB1]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024
Content-Transfer-Encoding: quoted-printable
Cc:
X-BeenThere: sipping-tispan@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Discussion of requirements for SIP introduced by ETSI TISPAN <sipping-tispan.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sipping-tispan>, <mailto:sipping-tispan-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/sipping-tispan>
List-Post: <mailto:sipping-tispan@ietf.org>
List-Help: <mailto:sipping-tispan-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sipping-tispan>, <mailto:sipping-tispan-request@ietf.org?subject=subscribe>
Sender: sipping-tispan-bounces@ietf.org
Errors-To: sipping-tispan-bounces@ietf.org

> > - 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
MailAdmin@tilab.com. Thank you
====================================================================

_______________________________________________
Sipping-tispan mailing list
Sipping-tispan@ietf.org
https://www1.ietf.org/mailman/listinfo/sipping-tispan