Subject: [Sipping-tispan] Parallel Ringing

From: "Alexeitsev, D" <[email-masked]>
Date: Fri, 17 Feb 2006 14:30:18 +0100

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/sipping-tispan

---

From: "Alexeitsev, D" <[email-masked]>
Date: Fri, 17 Feb 2006 15:46:27 +0100

Hello Jeroen
 
Thanks for the comments, my comments inline
 
greetings,
Denis Alexeitsev

-----Ursprüngliche Nachricht-----
Von: Bemmel, Jeroen van (Jeroen) [mailto:[email-masked]] 
Gesendet: Freitag, 17. Februar 2006 15:31
An: Alexeitsev, Denis; [email-masked]; [email-masked]
Betreff: RE: [Sipping-tispan] Parallel Ringing

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. 
>I hope that the issues will not overweigt the simplicity, but we will see 
 
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
 
>Surely the PRNG will inherit some of  the forking problems and we will need to assert what troubles they can cause.
 
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.  
 
> processing of the flag as it is also in the Call-Forwarding case is not mandatory. If a voicemail provider does not care about it, it should not worry, but a 
> more user friendly one will get a possibility to react. 
 
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) 
 
>I will be happy to discuss them

---

From: "Bemmel, Jeroen van (Jeroen)" <[email-masked]>
Date: Fri, 17 Feb 2006 15:30:38 +0100

Denis,

 

Best regards,
 
Jeroen van Bemmel, Lucent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of Alexeitsev, D
Sent: Friday, February 17, 2006 2:30 PM
To: [email-masked]; [email-masked]
Subject: [Sipping-tispan] Parallel Ringing

Hello altogether 

Waiting for comments, 
Denis Alexeitsev