AW: [Sipping-tispan] [CCBS/CCNR]
"Schmidt, Christian" <christian-schmidt@siemens.com> Thu, 01 September 2005 11:46 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32)
id 1EAnWT-0002gs-IG; Thu, 01 Sep 2005 07:46:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org)
by megatron.ietf.org with esmtp (Exim 4.32) id 1EAnWR-0002bV-4J
for sipping-tispan@megatron.ietf.org; Thu, 01 Sep 2005 07:46:23 -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 HAA28555
for <sipping-tispan@ietf.org>; Thu, 1 Sep 2005 07:46:20 -0400 (EDT)
Received: from thoth.sbs.de ([192.35.17.2])
by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EAnYN-00038h-Jo
for sipping-tispan@ietf.org; Thu, 01 Sep 2005 07:48:24 -0400
Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14])
by thoth.sbs.de (8.12.6/8.12.6) with ESMTP id j81BkLUn028224;
Thu, 1 Sep 2005 13:46:21 +0200
Received: from mhpahx0c.ww002.siemens.net (mhpahx0c.ww002.siemens.net
[139.25.165.42])
by mail3.siemens.de (8.12.6/8.12.6) with ESMTP id j81BkKXX012889;
Thu, 1 Sep 2005 13:46:20 +0200
Received: from MCHP7R5A.ww002.siemens.net ([139.25.131.163]) by
mhpahx0c.ww002.siemens.net with Microsoft SMTPSVC(6.0.3790.211);
Thu, 1 Sep 2005 13:44:48 +0200
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
x-mimeole: Produced By Microsoft Exchange V6.5.7226.0
Subject: AW: [Sipping-tispan] [CCBS/CCNR]
Date: Thu, 1 Sep 2005 13:46:20 +0200
Message-ID: <72963DDDF17D7949ABD18DC5DA58E7700583EE@MCHP7R5A.ww002.siemens.net>
Thread-Topic: [Sipping-tispan] [CCBS/CCNR]
Thread-Index: AcWu4tVCR8+10prpSdmPzRs37GfeiQAA6BjA
From: "Schmidt, Christian" <christian-schmidt@siemens.com>
To: "Miguel Garcia" <Miguel.An.Garcia@nokia.com>, <sipping-tispan@ietf.org>
X-OriginalArrivalTime: 01 Sep 2005 11:44:48.0265 (UTC)
FILETIME=[8E48E790:01C5AEEA]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0
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
Some additional questions / comments: - Are CCBS / CCNR related to a terminal or an AOR of caller/callee? - A more precise definition of state change is needed (e.g. using BYE or INVITE for a call, avoiding busy/idle expression) - What is the meaning of "the callee showed activity"? Could this be WWW search as well? - A message toward the caller about state change of the callee is missing - Are multiple request possible for CCNR as with CCBS? - Is it possible for a caller to have simultaneous CCBS and CCNR requests? - If a CCBS / CCNR request is cancelled from the network, should the caller be informed? - The same expression as in the other requirements should be used, meaning caller and callee instead of UAC and UAS. Or UAC and UAS have to be explained in this context. Regards, Christian -----Ursprüngliche Nachricht----- Von: sipping-tispan-bounces@ietf.org [mailto:sipping-tispan-bounces@ietf.org] Im Auftrag von Miguel Garcia Gesendet: Donnerstag, 1. September 2005 11:19 An: sipping-tispan@ietf.org Betreff: [Sipping-tispan] [CCBS/CCNR] Hi: with respect the added CCBS/CCNR requirements, I think something is still missing. - 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. - 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". - Perhaps and explanation that the queue manager must be able to distinguish between "call in return to CCBS/CCNR free indication" from regular calls. This is related to the "timeslot" concept as well. Anyone with further information of the requirements, please comment. /Miguel -- Miguel A. Garcia tel:+358-50-4804586 sip:miguel.an.garcia@openlaboratory.net Nokia Research Center Helsinki, Finland _______________________________________________ Sipping-tispan mailing list Sipping-tispan@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-tispan _______________________________________________ Sipping-tispan mailing list Sipping-tispan@ietf.org https://www1.ietf.org/mailman/listinfo/sipping-tispan
- AW: [Sipping-tispan] [CCBS/CCNR] Schmidt, Christian
- Re: AW: [Sipping-tispan] [CCBS/CCNR] Miguel Garcia