RE: [Sipping-tispan] Re: CCBS/CCNR in Version -02f

"Elwell, John" <john.elwell@siemens.com> Thu, 29 September 2005 06:20 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKrmL-0008JF-Qs; Thu, 29 Sep 2005 02:20:25 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKrmK-0008Iy-A8 for sipping-tispan@megatron.ietf.org; Thu, 29 Sep 2005 02:20:24 -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 CAA20373 for <sipping-tispan@ietf.org>; Thu, 29 Sep 2005 02:20:21 -0400 (EDT)
Received: from mailgate.siemenscomms.co.uk ([195.171.110.225]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKrtp-0007vm-H3 for sipping-tispan@ietf.org; Thu, 29 Sep 2005 02:28:11 -0400
Received: from CONVERSION-DAEMON.siemenscomms.co.uk by siemenscomms.co.uk (PMDF V6.0-24 #40642) id <0INK00D01ET6FS@siemenscomms.co.uk> for sipping-tispan@ietf.org; Thu, 29 Sep 2005 07:17:30 +0100 (BST)
Received: from ntht207e.uksgcs.siemenscomms.co.uk ([137.223.247.82]) by siemenscomms.co.uk (PMDF V6.0-24 #40642) with ESMTP id <0INK0059JET52Z@siemenscomms.co.uk>; Thu, 29 Sep 2005 07:17:29 +0100 (BST)
Received: by ntht207e.uksgcs.siemenscomms.co.uk with Internet Mail Service (5.5.2657.72) id <TTA60ZQ9>; Thu, 29 Sep 2005 07:19:57 +0100
Content-return: allowed
Date: Thu, 29 Sep 2005 07:19:48 +0100
From: "Elwell, John" <john.elwell@siemens.com>
Subject: RE: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
To: Miguel Garcia <Miguel.An.Garcia@nokia.com>, "Michael Hammer (mhammer)" <mhammer@cisco.com>
Message-id: <50B1CBA96870A34799A506B2313F266706879079@ntht201e.siemenscomms.co.uk>
MIME-version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-type: text/plain
Content-transfer-encoding: 7BIT
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab
Content-Transfer-Encoding: 7BIT
Cc: Tessa Silvia <Silvia.Tessa@TILAB.COM>, sipping-tispan@ietf.org
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

Miguel,

In-line,

John

> -----Original Message-----
> From: Miguel Garcia [mailto:Miguel.An.Garcia@nokia.com] 
> Sent: 28 September 2005 10:31
> To: Michael Hammer (mhammer)
> Cc: Tessa Silvia; sipping-tispan@ietf.org
> Subject: Re: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
> 
> Hi Mike:
> 
> Inline discussion.
> 
> Michael Hammer (mhammer) wrote:
> 
> > Miguel,
> > 
> > I think there is still a little bit of schizophrenia in the
> > requirements.  I assume that a server is acting on behalf 
> of either the
> > caller or the callee, but not both because each could be served by a
> > different host, domain, or organization.  The first 
> requirement seems to
> > assume that the CCBS is a terminating service of the callee.  Other
> > requirements seem to assume that the CCBS is a service of 
> the caller.
> > Which is it?
> 
> Both. It has been demonstrated that CCBS is a service that requires 
> cooperation of both the originating and terminatine service 
> providers. 
> This cooperation is mostly required to manage queues of both 
> the caller 
> and callee, and to manage susped/resume states.
[JRE] It is not clear to me what the involvement of the originating service
provider is. Perhaps this comes down to what exactly are the requirements
for notifying the caller that a call may now succeed. Is this notification
constrained to go to the same UA that requested CCBS/CCNR in the first
place, or should it go to any UA currently registered as a contact for the
caller's AoR? In my opinion the former is sufficient and indeed probably
preferable. If I request CCBS/CCNR from a particular UA I would expect to
receive the notification on that same UA and make the new call attempt from
there. In the relatively infrequent event that I move to a different UA in
the intervening period, I could simply request CCBS/CCNR again from the new
UA.

So on the assumption that CCBS/CCNR involves only a single UA on the caller
side, what service does the originating service provider perform? Why can't
the UA directly request CCBS/CCNR and communicate with the service provider
on the callee side to achieve this? The caller's UA will receive
notification when a the call can be made and can present that information to
the caller somehow, allowing the caller to choose when to proceed with that
call, e.g., whether to interrupt any ongoing communications in order to make
that call.


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