Subject: [Sip] RE: Open Issue #138: to fork, or not to fork

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 7 Sep 2001 15:28:18 -0400

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
[email-masked]                     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: [email-masked]'
> 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
> [email-masked]                     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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 10 Sep 2001 08:07:41 +0300

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