RE: [Sipping-tispan] Parallel Ringing

"Bemmel, Jeroen van (Jeroen)" <jbemmel@lucent.com> Fri, 17 February 2006 15:04 UTC

Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA79d-0000GE-R9; Fri, 17 Feb 2006 10:04:17 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1FA708-0002GB-DM for sipping-tispan@megatron.ietf.org; Fri, 17 Feb 2006 09:54:28 -0500
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12188 for <sipping-tispan@ietf.org>; Fri, 17 Feb 2006 09:29:49 -0500 (EST)
Received: from ihemail2.lucent.com ([192.11.222.163]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FA6re-0001HR-Ox for sipping-tispan@ietf.org; Fri, 17 Feb 2006 09:45:47 -0500
Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by ihemail2.lucent.com (8.12.11/8.12.11) with ESMTP id k1HEUhIQ028505; Fri, 17 Feb 2006 08:30:44 -0600 (CST)
Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2657.72) id <DVB4RM12>; Fri, 17 Feb 2006 15:30:43 +0100
Message-ID: <7D5D48D2CAA3D84C813F5B154F43B1550577E36D@nl0006exch001u.nl.lucent.com>
From: "Bemmel, Jeroen van (Jeroen)" <jbemmel@lucent.com>
To: "'Alexeitsev, D'" <D.Alexeitsev@t-com.net>, sipping-tispan@ietf.org, TISPAN_WG3@LIST.ETSI.ORG
Subject: RE: [Sipping-tispan] Parallel Ringing
Date: Fri, 17 Feb 2006 15:30:38 +0100
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2657.72)
X-Spam-Score: 0.9 (/)
X-Scan-Signature: 0e9ebc0cbd700a87c0637ad0e2c91610
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>
Content-Type: multipart/mixed; boundary="===============1437118338=="
Sender: sipping-tispan-bounces@ietf.org
Errors-To: sipping-tispan-bounces@ietf.org

Denis,
 
My comment would be: this feature sounds straightforward enough, but I expect it is in fact quite tricky to realize, and may even introduce more issues than it solves.
 
When you start forking, an issue that arises is HERFP. See http://www.ietf.org/internet-drafts/draft-jbemmel-sipping-herfp-solution-00.txt <http://www.ietf.org/internet-drafts/draft-jbemmel-sipping-herfp-solution-00.txt>  for details; basically a quick error response from one of the targets could block succesful accepts from others, causing the call to fail
 
Second, what about currently deployed voice mail servers? They would not understand the 'parallel ringing' flag and respond immediately anyway. A 'Require: parallel-ringing' might avoid that (should trigger an error response), but proxies aren't currently allowed to insert a Require (and the error response would cause HERFP). The proxy might instead be adapted to delay processing of a voicemail server response, but then you have the issue how to recognise a response from a voicemail server. 
 
And then there are probably more issues. In other words, I expect that you would probably need additional SIP procedures to make this work (in particular for error scenarios)
 
Best regards,
 
Jeroen van Bemmel, Lucent
 

-----Original Message-----
From: sipping-tispan-bounces@ietf.org [mailto:sipping-tispan-bounces@ietf.org]On Behalf Of Alexeitsev, D
Sent: Friday, February 17, 2006 2:30 PM
To: sipping-tispan@ietf.org; TISPAN_WG3@LIST.ETSI.ORG
Subject: [Sipping-tispan] Parallel Ringing



Hello altogether 

I would like to discuss the parallel ring service, that was not on the TISPAN release one, but we would like to it get introduced in release two.

>From the signalling point of view, there should be no additional SIP procedures required except for the indication in both directions that the parallel ringing is taking place. That is important for example to be able to prevent a voicemail box being one of the parallel ring targets from automatically accepting the call. On receiving this cause it could delay the answer for some time giving other parties a chance of answering.

As the parallel ringing can be considered as a very special case of call forwarding, that same procedures could be used to indicate it, namely History-Info header. What is needed is just another cause code, that would indicate a parallel ringing.

As a nice side effect this indication would also allow endpoints to understand when to send 486 Busy Here and when 600 Busy Everywhere.

A forking event could be incorporated in to the same cause or could have an explicit one. 

Waiting for comments, 
Denis Alexeitsev 

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