Re: [Sip] RE: Open Issue #138: to fork, or not to fork
Christer Holmberg <christer.holmberg@lmf.ericsson.se> Mon, 10 September 2001 05:27 UTC
Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22671 for <sip-archive@odin.ietf.org>; Mon, 10 Sep 2001 01:27:58 -0400 (EDT)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA15728; Mon, 10 Sep 2001 01:08:00 -0400 (EDT)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id BAA15676 for <sip@optimus.ietf.org>; Mon, 10 Sep 2001 01:07:57 -0400 (EDT)
Received: from penguin-ext.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.110]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21127 for <sip@ietf.org>; Mon, 10 Sep 2001 01:06:17 -0400 (EDT)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by penguin.wise.edt.ericsson.se (8.11.0/8.10.1/WIREfire-1.3) with ESMTP id f8A57hv07649; Mon, 10 Sep 2001 07:07:44 +0200 (MEST)
Received: from lmf.ericsson.se (lmf00234pc.lmf.ericsson.se [131.160.30.33]) by fogerty.lmf.ericsson.se (8.11.3/8.11.3) with ESMTP id f8A57gb13398; Mon, 10 Sep 2001 08:07:42 +0300 (EET DST)
Message-ID: <3B9C4A9D.B4ED7EFA@lmf.ericsson.se>
Date: Mon, 10 Sep 2001 08:07:41 +0300
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: "'sip@ietf.org'" <sip@ietf.org>
Subject: Re: [Sip] RE: Open Issue #138: to fork, or not to fork
References: <B65B4F8437968F488A01A940B21982BF020D67FC@DYN-EXCH-001.dynamicsoft.com>
Content-Type: multipart/mixed; boundary="------------67AB2EFE0A45A4870C917040"
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Hi, First, I am NOT going to propose the removal of forking :) I will, however, give some comments. I mentioned this issue in another mail (my comments about the manyfolks draft), but I will take it up here too. So, I guess most of us agree that forking does produce a number of problems in different scenario. And, sometimes when we have a cool SIP extension we later find out that it doesn't always work with forking. So, the following proposal came up when I read the manyfolks draft: why not always, in every SIP extension draft, include a chapter how the specific extension/feature works in a working environment. That way, if the author takes that into consideration from the beginning, we don't have to start thinking of it 6 months later when the draft is supposed to go for last call... And, if someone comes up with something, but it does NOT work in a forking environment, it should at least be mentioned that it doesn't work in a forking environment. It will then be easier to decide if it's worth making a WG item in the first place. Comments? Christer Holmberg Ericsson Finland Jonathan Rosenberg wrote: > > It has been two weeks since I posted this. > > There were no responses. Since there was consensus on this at IETF, I will > now assume list consensus on this, and therefore close this open issue. > > Thanks, > Jonathan R. > > --- > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > Chief Scientist First Floor > dynamicsoft East Hanover, NJ 07936 > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > http://www.jdrosen.net PHONE: (973) 952-5000 > http://www.dynamicsoft.com > > > > -----Original Message----- > > From: Jonathan Rosenberg > > Sent: Wednesday, August 22, 2001 7:14 PM > > To: 'sip@ietf.org' > > Subject: Open Issue #138: to fork, or not to fork > > > > > > Issue: > > > > Do we deprecate forking for INVITE? > > > > Do we deprecate forking for non-INVITE? > > > > Points of discussion: > > > > There was quick discussion on the first issue, followed by a > > hum of consensus. THere was strong consensus to keep forking > > of INVITE, with the notable exception of the esteemed chair, > > Mr. Willis. There was agreement to close on this so that we > > can stifle continued dsicussion of the subject on the list. > > > > The second one is more complex. Forking of non-INVITE is > > complex since the non-INVITE only generates a single > > response. Forking makes sense when the things you fork to are > > homogeneous and don't create state. Thus, speaking to any one > > is fine. If state is created by the non-INVITE, and this > > state needs to be managed, the non-INVITE has to have some > > companion method that allows the "called party" to send a > > request back towards the "caller" to indicate that a "leg" > > was created there. > > > > We have encountered a need for this for SUBSCRIBE. It appears > > to be useful to fork SUBSCRIBE, and so long as we use Adam's > > proposed approach of constructing route sets and leg state > > through the NOTIFY, it works fine. > > > > Proposal: > > > > Continue to allow forking of non-INVITE. > > > > There was consensus on this proposal. > > > > -Jonathan R. > > > > --- > > Jonathan D. Rosenberg, Ph.D. 72 Eagle Rock Ave. > > Chief Scientist First Floor > > dynamicsoft East Hanover, NJ 07936 > > jdrosen@dynamicsoft.com FAX: (973) 952-5050 > > http://www.jdrosen.net PHONE: (973) 952-5000 > > http://www.dynamicsoft.com > > > > > > _______________________________________________ > Sip mailing list http://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use sip-implementors@cs.columbia.edu for questions on current sip > Use sipping@ietf.org for new developments on the application of sip
- [Sip] Open Issue #138: to fork, or not to fork Jonathan Rosenberg
- [Sip] RE: Open Issue #138: to fork, or not to fork Jonathan Rosenberg
- Re: [Sip] RE: Open Issue #138: to fork, or not to… Christer Holmberg
- RE: [Sip] RE: Open Issue #138: to fork, or not to… Tan Ya-Ching ICM N MC MI E73
- Re: [Sip] RE: Open Issue #138: to fork, or not to… Christer Holmberg
- RE: [Sip] RE: Open Issue #138: to fork, or not to… Jonathan Rosenberg
- RE: [Sip] RE: Open Issue #138: to fork, or not to… Jonathan Rosenberg
- Re: [Sip] RE: Open Issue #138: to fork, or not to… Christer Holmberg