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