----- Original Message ----- From: "Alf Salte" <[EMAIL PROTECTED]> To: "Bob Penfield" <[EMAIL PROTECTED]> Sent: Thursday, September 28, 2006 7:32 AM Subject: Re: [Sip-implementors] query regarding parallel forking
> On Thu, 2006-09-28 at 07:09 -0400, Bob Penfield wrote: <snip> >> > This is not specified in any RFC. It is up to the proxy how to handle >> > this. >> >> This is not correct. RFC 3261 requires that a proxy send all 2xx >> responses >> to the UAC (See section 16.7). Upon receipt of the first 2xx response, >> the >> proxy sends a CANCEL on all other branches of the fork (that have not >> received a final response). However, this does not prevent another UAS >> from >> sending a 200-OK (in the case where the CANCEL does not reach the UAS in >> time). > > Yes, you are correct. I was thinking of the fact that the proxy can > choose whether to send CANCEL or not and that is not specified in the > RFC. However, as you say, if it chooses to send CANCEL but the CANCEL do > not reach the UAS in time and so the branch still send a 2xx response > the proxy MUST forward that 2xx response as well and thus the UAC > receives multiple 2xx responses. > > My point was that whether or not a proxy chooses to send CANCEL to other > brances in this situation - is left to the implementation of the proxy > and is not specified in the RFC. The CANCEL is not optional (see step 10 in section 16.7). The proxy MUST send a CANCEL to pending branches when it forwards the first final response on the server transaction. <snip> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
