RE: [Sipping-tispan] Requirements -02h

"Drage, Keith (Keith)" <drage@lucent.com> Tue, 11 October 2005 21:09 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPRNE-0001Ud-6g; Tue, 11 Oct 2005 17:09:24 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EPRND-0001UU-1x for sipping-tispan@megatron.ietf.org; Tue, 11 Oct 2005 17:09: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 RAA04355 for <sipping-tispan@ietf.org>; Tue, 11 Oct 2005 17:09:20 -0400 (EDT)
Received: from hoemail1.lucent.com ([192.11.226.161]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EPRXN-0001pd-A3 for sipping-tispan@ietf.org; Tue, 11 Oct 2005 17:19:54 -0400
Received: from uk0006exch001h.wins.lucent.com (h135-221-14-69.lucent.com [135.221.14.69]) by hoemail1.lucent.com (8.12.11/8.12.11) with ESMTP id j9BL9CqI026870; Tue, 11 Oct 2005 16:09:13 -0500 (CDT)
Received: by uk0006exch001h.uk.lucent.com with Internet Mail Service (5.5.2657.72) id <TVC7N1ZF>; Tue, 11 Oct 2005 22:09:12 +0100
Message-ID: <475FF955A05DD411980D00508B6D5FB010E7513F@en0033exch001u.uk.lucent.com>
From: "Drage, Keith (Keith)" <drage@lucent.com>
To: "'Paul Kyzivat'" <pkyzivat@cisco.com>, "'Michael Hammer (mhammer)'" <mhammer@cisco.com>
Subject: RE: [Sipping-tispan] Requirements -02h
Date: Tue, 11 Oct 2005 22:09:09 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
Content-Type: text/plain; charset="iso-8859-1"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4
Cc: "'sipping-tispan@ietf.org'" <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

In the ISDN service there is no "try again" to the callee, once the CCBS completion has been presented to the end terminal, and therefore performed alerting to the absent user.. 

As you identify, it is almost impossible to identify an algorithm that works for the user, apart from the knowledge that the user is there and involved in another call. In the latter case, the callee is not alerted on the assumption that the user can only deal with one call at once.

So, just as on every PBX that I know of, if the recall to the callee fails, then the CCBS is cancelled. The callee can come back to the phone, interrogate the service to see if the CCBS request is still there, and if it is not, then reactivate it.

regards

Keith

> -----Original Message-----
> From: sipping-tispan-bounces@ietf.org
> [mailto:sipping-tispan-bounces@ietf.org]On Behalf Of Paul Kyzivat
> Sent: 30 September 2005 18:43
> To: Michael Hammer (mhammer)
> Cc: sipping-tispan@ietf.org; Alexeitsev, D
> Subject: Re: [Sipping-tispan] Requirements -02h
> 
> 
> 
> 
> Michael Hammer (mhammer) wrote:
> > Paul,
> > 
> > This would suggest that so long as one terminal belonging 
> to the AoR has
> > the capability to accept another call *and* that terminal 
> was recently
> > used by the user
> 
> This is the weak spot in the whole service.
> 
> If the callee has been alerted without success once, there is 
> need for 
> some algorithm to decide when to try again. *Any* change in 
> state of any 
> registered UA may be considered justification for trying 
> again. But even 
> that isn't a great huristic. I may have been gone all afternoon, and 
> have recently returned. I am now available though I have not recently 
> used any terminal. I would think that even in the absence of 
> any state 
> change, another attempt should be made periodically.
> 
> > (hopefully the correct human),
> 
> I think by definition any human that can cause the terminal 
> to answer is 
> a correct human. Certainly that is the assumption when regular calls 
> arrive, and I see no reason why it should be different here.
> 
> > an attempt should be
> > made to complete using that terminal (plus any terminal 
> that can accept
> > a call independent of activity - could be broadcast to all).
> > 
> > Boy, hope that presence system is smart.
> 
> One that can detect "someone is now in the area" would be good.
> 
> 	Paul
> 
> _______________________________________________
> 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