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
- R: [Sipping-tispan] [CCBS/CCNR] Tessa Silvia
- R: [Sipping-tispan] [CCBS/CCNR] Tessa Silvia
- Re: R: [Sipping-tispan] [CCBS/CCNR] Miguel Garcia
- R: [Sipping-tispan] [CCBS/CCNR] Tessa Silvia
- R: [Sipping-tispan] [CCBS/CCNR] Tessa Silvia
- Re: R: [Sipping-tispan] [CCBS/CCNR] Miguel Garcia
- Re: R: [Sipping-tispan] [CCBS/CCNR] Paul Kyzivat
- RE: R: [Sipping-tispan] [CCBS/CCNR] Drage, Keith (Keith)
- RE: R: [Sipping-tispan] [CCBS/CCNR] Elwell, John