[Sip] 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