[Sipping] I-D update on forcing parallel forking

[worley at dworley.hsd1.ma.comcast.net]

I've submitted an updated I-D that suggests that the
"Request-Disposition: parallel" header (per RFC 3841) should be used
to force truly parallel forking of a request -- the UAC receives
responses from all UASs that get copies of the request.  It can be
fetched from

https://scm.sipfoundry.org/rep/ietf-drafts/worley/draft-worley-sipping-forking-01.{txt,html,xml}

     A New Forking Mechanism for Session Initiation Protocol (SIP)
                    draft-worley-sipping-forking-01

   The rules for SIP proxies are organized so that when a UAC sends an
   out-of-dialog request, even if the request is forked to a number of
   UASs, (usually) only one UAS will accept the request, and only the
   final response from that UAS will be returned to the UAC.  This
   forking mechanism is optimal for an INVITE intended to connect one
   human user with another human uses, but is poor for requests that
   have a "one to many" nature, especially PUBLISH and SUBSCRIBE
   requests, but also including some INVITEs.  This document proposes an
   alternative forking mechanism that better supports "one to many"
   requests, and that mechanism be the standardized meaning of the
   (existing but weakly specified) "Request-Disposition: parallel"
   header.

I'm interested in comments, as we haven't gotten to the bottom of this
problem yet.

Dale

Dale Worley						worley at theworld.com
--
Simon acknowledges that his theory offers a somewhat cynical view of
human nature.  But that, he says, is an inevitable consequence of doing
serious social science.

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sip at ietf.org for new developments of core SIP