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

Miguel Garcia <Miguel.An.Garcia@nokia.com> Fri, 30 September 2005 08:05 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELFtD-0005C1-Ix; Fri, 30 Sep 2005 04:05:07 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELFtA-0005Ax-38 for sipping-tispan@megatron.ietf.org; Fri, 30 Sep 2005 04:05:05 -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 EAA27896 for <sipping-tispan@ietf.org>; Fri, 30 Sep 2005 04:05:02 -0400 (EDT)
Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELG0y-0006tr-3e for sipping-tispan@ietf.org; Fri, 30 Sep 2005 04:13:09 -0400
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8U84GNN021391; Fri, 30 Sep 2005 11:04:19 +0300
Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 30 Sep 2005 11:04:20 +0300
Received: from [127.0.0.1] ([172.21.36.159]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 30 Sep 2005 11:04:18 +0300
Message-ID: <433CF183.1070202@nokia.com>
Date: Fri, 30 Sep 2005 11:04:19 +0300
From: Miguel Garcia <Miguel.An.Garcia@nokia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax)
X-Accept-Language: en-us, en, es-es
MIME-Version: 1.0
To: "Elwell, John" <john.elwell@siemens.com>
Subject: Re: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
References: <50B1CBA96870A34799A506B2313F266706879604@ntht201e.siemenscomms.co.uk>
In-Reply-To: <50B1CBA96870A34799A506B2313F266706879604@ntht201e.siemenscomms.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-OriginalArrivalTime: 30 Sep 2005 08:04:18.0488 (UTC) FILETIME=[8EB3E380:01C5C595]
Content-Transfer-Encoding: quoted-printable
X-MIME-Autoconverted: from 8bit to quoted-printable by mgw-ext01.nokia.com id j8U84GNN021391
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985
Content-Transfer-Encoding: quoted-printable
Cc: sipping-tispan@ietf.org, Tessa Silvia <Silvia.Tessa@TILAB.COM>
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

John:

I think that the role of the CCBS/CCNR server on the caller side is to 
arbitrate the caller's queue (of CCBS/CCNR request), and monitor its 
status (as to change the state from pending to suspended and back to 
pending).

/Miguel


Elwell, John wrote:
> Sebastien,
> 
> I was not trying to open up an old debate. I was simply continuing the
> recent debate about on whose behalf the service provider is acting, and
> whether there are two service providers or one. I can see a role for a
> service provider acting on behalf of the callee, since it needs to look out
> for different UAs registered for the AoR concerned that might be in a
> position to satisfy the CCBS/CCNR request. I am not sure I understand what a
> service provider acting on behalf of the caller would do. It would be good
> to get an answer to my question about whether a CCBS/CCNR request results in
> a call from the same UA as that from which the request was made or any UA
> registered as contact for the caller's AoR.
> 
> John
> 
> 
> 
>>-----Original Message-----
>>From: GARCIN Sebastien RD-CORE-ISS 
>>[mailto:sebastien.garcin@francetelecom.com] 
>>Sent: 29 September 2005 09:11
>>To: Elwell, John; Miguel Garcia; Michael Hammer (mhammer)
>>Cc: Tessa Silvia; sipping-tispan@ietf.org
>>Subject: RE: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
>>
>>John,
>>
>>You seems to want try and open the endless debate about where 
>>the intelligence should be placed in the network or in the 
>>terminals. The approach you are proposing is not something 
>>that TISPAN will accept so I suggest that we move out of this debate.
>>
>>sébastien 
>> 
>>
>>-----Message d'origine-----
>>De : sipping-tispan-bounces@ietf.org 
>>[mailto:sipping-tispan-bounces@ietf.org] De la part de Elwell, John
>>Envoyé : jeudi 29 septembre 2005 08:20
>>À : Miguel Garcia; Michael Hammer (mhammer)
>>Cc : Tessa Silvia; sipping-tispan@ietf.org
>>Objet : RE: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
>>
>>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
> 
> 

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