Subject: [Sip] forking of PUBLISH

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 21 Sep 2005 21:56:02 +0200

Hi,

RFC3903 does not seem to make any statements regarding the forking of PUBLISH requests. Is it allowed? 

Regards,

Jeroen

_______________________________________________
Sip mailing list  https://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: Aki Niemi <[email-masked]>
Date: Wed, 21 Sep 2005 23:44:03 +0300

Hi,

Since it isn't disallowed, it's allowed by default. RFC 3903 doesn't 
make any special requirements for forking proxies in addition to what 
RFC 3261 already says about non-INVITEs.

Cheers,
Aki

ext Jeroen van Bemmel wrote:
> ------------------------------------------------------------------------
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 22 Sep 2005 23:11:08 -0400

> RFC 3261 already says about non-INVITEs.

However, note that the sender cannot trust that forking will result in 
all the candidate recipients receiving the publish, for several reasons:
- the proxy isn't required to fork
- if the proxy forks, it isn't required to do parallel forking
- once the proxy receives a 2xx response from any form, it is
   supposed to cease forking and cancel any outstanding requests.
   In the case of serial forking, none of the candidates that
   have not been tried will get the publish. In the case of parallel
   forking, the cancels aren't likely to be effective, but you can't
   be sure.
- at most one error response will be sent, and that only if a
   2xx response is not sent. So errors at some forks may not be
   reported to the sender.

All in all, if you need the PUBLISH to get to more than one target, then 
you had better send to each, and not count on forking to do it for you.

	Paul

---

From: Aki Niemi <[email-masked]>
Date: Fri, 23 Sep 2005 09:30:27 +0300

Hi,

> you had better send to each, and not count on forking to do it for you.

Yes, this is certianly true, and in retrospect, perhaps it would have 
been appropriate to state in RFC 3903 that PUBLISH doesn't support a set 
of heterogeneous compositors for a given resource. If a PUBLISH forks, 
then those targets should all be UASs that handle the resource state in 
a coordinated manner, e.g., they have shared entity tags in addition to 
the shared event state.

Cheers,
Aki