Agree with Inaki here. More info here
11.2 Processing of OPTIONS Request This use of OPTIONS has limitations due to the differences in proxy handling of OPTIONS and INVITE requests. While a forked INVITE can result in multiple 200 (OK) responses being returned, a forked OPTIONS will only result in a single 200 (OK) response, since it is treated by proxies using the non-INVITE handling. See Section 16.7 for the normative details. FYI -Rockson -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of I?aki Baz Castillo Sent: Thursday, August 21, 2008 4:51 PM To: [email protected] Subject: Re: [Sip-implementors] Does proxy need cancel forked non-INVITE req? El Thursday 21 August 2008 10:12:51 Attila Sipos escribió: > 3. if the OPTIONS is forked - and the first fork responded > with 200 OK? What does the proxy do with subsequent > 200 OKs? 16.7 Response Processing 5. Check response for forwarding Until a final response has been sent on the server transaction, the following responses MUST be forwarded immediately: - Any provisional response other than 100 (Trying) - Any 2xx response ... After a final response has been sent on the server transaction, the following responses MUST be forwarded immediately: - Any 2xx response to an INVITE request <--- just INVITE !!!!! This step, combined with the next, ensures that a stateful proxy will forward exactly one final response to a non-INVITE request, and either exactly one non-2xx response or one or more 2xx responses to an INVITE request. 6. Choosing the best response A stateful proxy MUST send a final response to a response context's server transaction if no final responses have been immediately forwarded by the above rules (This is the point, since a 200 OK for a non-INVITE was already received !!!) So, the documented behaviour is that when a proxy forks a non-INVITE request (an OPTIONS for example), if it receives a 200 from one location it replies it directly to the UAC and absorb the rest of future responses from other branches (other client transactions). -- Iñaki Baz Castillo [EMAIL PROTECTED] _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
