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

"Michael Hammer \(mhammer\)" <mhammer@cisco.com> Thu, 29 September 2005 15:54 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL0jk-000874-Qo; Thu, 29 Sep 2005 11:54:20 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EL0jj-00086z-D0 for sipping-tispan@megatron.ietf.org; Thu, 29 Sep 2005 11:54:19 -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 LAA19870 for <sipping-tispan@ietf.org>; Thu, 29 Sep 2005 11:54:16 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EL0rP-0005sd-Py for sipping-tispan@ietf.org; Thu, 29 Sep 2005 12:02:16 -0400
Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-3.cisco.com with ESMTP; 29 Sep 2005 08:54:09 -0700
X-IronPort-AV: i="3.97,158,1125903600"; d="scan'208"; a="346710105:sNHT37165472"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j8TFs3KC004687; Thu, 29 Sep 2005 08:54:04 -0700 (PDT)
Received: from xmb-rtp-20b.amer.cisco.com ([64.102.31.53]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 29 Sep 2005 11:53:58 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
Date: Thu, 29 Sep 2005 11:53:57 -0400
Message-ID: <072C5B76F7CEAB488172C6F64B30B5E39C9C9B@xmb-rtp-20b.amer.cisco.com>
Thread-Topic: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
Thread-Index: AcXFCB4VNkuHgRKiRVWDh9DThJjv7gABYIFg
From: "Michael Hammer \(mhammer\)" <mhammer@cisco.com>
To: "Elwell, John" <john.elwell@siemens.com>, "GARCIN Sebastien RD-CORE-ISS" <sebastien.garcin@francetelecom.com>, "Miguel Garcia" <Miguel.An.Garcia@nokia.com>
X-OriginalArrivalTime: 29 Sep 2005 15:53:58.0419 (UTC) FILETIME=[00D65E30:01C5C50E]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 2a9ffb6f997442a3b543bcdaf483b990
Content-Transfer-Encoding: quoted-printable
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

I can go along with the direction this thread has taken.  I guess I am mainly pointing out that this in effect is an interaction with what in the PSTN are implemented as hunt group features.  The nature of a call to a SIP AOR is broader than what was typically to a PSTN line.  Just wanted to take such things into account.

Mike

> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens.com] 
> Sent: Thursday, September 29, 2005 11:04 AM
> To: Michael Hammer (mhammer); GARCIN Sebastien RD-CORE-ISS; 
> Miguel Garcia
> Cc: Tessa Silvia; sipping-tispan@ietf.org
> Subject: RE: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
> 
> Mike,
> 
> Hopefully the so-called recall would be presented to the user 
> as a CCBS recall and not just as a normal incoming call. This 
> would allow the appropriate user to identify it as such (if 
> there are multiple users) and would also allow that user to 
> prioritise the handling of the recall with respect to any 
> other activities he/she is performing at the time.
> 
> John
> 
> > -----Original Message-----
> > From: Michael Hammer (mhammer) [mailto:mhammer@cisco.com]
> > Sent: 29 September 2005 15:28
> > To: Elwell, John; GARCIN Sebastien RD-CORE-ISS; Miguel Garcia
> > Cc: Tessa Silvia; sipping-tispan@ietf.org
> > Subject: RE: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
> > 
> > It seems to make more sense to focus on the request being from a 
> > specific terminal of the user.  I can picture the call completed to 
> > another terminal with a second person and the ensuing, "no 
> you called 
> > me" confusion.
> > 
> > Mike
> >  
> > 
> > > -----Original Message-----
> > > From: Elwell, John [mailto:john.elwell@siemens.com]
> > > Sent: Thursday, September 29, 2005 8:22 AM
> > > To: GARCIN Sebastien RD-CORE-ISS; Miguel Garcia; Michael Hammer 
> > > (mhammer)
> > > Cc: Tessa Silvia; sipping-tispan@ietf.org
> > > Subject: RE: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
> > > 
> > > Sebastien,
> > > 
> > > Irrespective of the need for a service provider on the 
> caller side, 
> > > what is the requirement concerning the call resulting 
> from CCBS/CCNR 
> > > - should it use the same caller UA as that which issued the 
> > > CCBS/CCNR request, or should it use any UA registered as 
> contact for 
> > > the AoR concerned?
> > > 
> > > John
> > >  
> > > 
> > > > -----Original Message-----
> > > > From: GARCIN Sebastien RD-CORE-ISS 
> > > > [mailto:sebastien.garcin@francetelecom.com]
> > > > Sent: 29 September 2005 12:58
> > > > 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,
> > > > 
> > > > Basically it enables "service interactions", "charging model", 
> > > > "control of subscriber rights to the service", "playing
> > > CCBS related
> > > > announcement"...Having the service logic embedded in an
> > Application
> > > > Server serving the originating user makes all this possible.
> > > > 
> > > > If you want a more detailed to understand the role of 
> the service 
> > > > provider acting of behalf of the caller, I suggest you read the 
> > > > related section dealing with the originating exchange in
> > > ITU-T Q.733
> > > > or contact your Siemens collegues that participate to TISPAN.
> > > > 
> > > > Regards,
> > > > sébastien
> > > > 
> > > > 
> > > > 
> > > > 
> > > > -----Message d'origine-----
> > > > De : Elwell, John [mailto:john.elwell@siemens.com] Envoyé : 
> > > jeudi 29
> > > > septembre 2005 13:11 À : GARCIN Sebastien RD-CORE-ISS;
> > > Miguel Garcia;
> > > > Michael Hammer (mhammer) Cc : Tessa Silvia;
> > sipping-tispan@ietf.org
> > > > Objet : RE: [Sipping-tispan] Re: CCBS/CCNR in Version -02f
> > > > 
> > > > 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
> > > > > 
> > > > 
> > > 
> > 
> 

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