hmmm... not so sure now. I can see that a client must not generate a CANCEL. Maybe a proxy can.
I have a few questions myself: 1. of what use is a CANCEL for OPTIONS? Won't the OPTIONS just be responded to very quickly anyway. I doubt the CANCEL would ever arrive in time to have an effect unless somehow the OPTIONS took a long time. 2. what use is forking an OPTIONS anyway? Isn't the purpose of OPTIONS to find out capabilities of a specific UA? 3. if the OPTIONS is forked - and the first fork responded with 200 OK? What does the proxy do with subsequent 200 OKs? Regards, Attila -----Original Message----- From: Rockson Li (zhengyli) [mailto:[EMAIL PROTECTED] Sent: 21 August 2008 08:56 To: Attila Sipos; [email protected] Subject: RE: [Sip-implementors] Does proxy need cancel forked non-INVITE req ? So another bug here? The *MUST* in "10. Generate CANCELs" cannot apply to non-INVITE client transactions -Rockson -----Original Message----- From: Attila Sipos [mailto:[EMAIL PROTECTED] Sent: Thursday, August 21, 2008 3:50 PM To: Rockson Li (zhengyli); [email protected] Subject: RE: [Sip-implementors] Does proxy need cancel forked non-INVITE req ? As you say: A CANCEL request SHOULD NOT be sent to cancel a request other than INVITE. So, there is no CANCEL for non-INVITE. (In other words, there is only CANCEL for INVITE) Since the above is true, the "10. Generate CANCELs" section can be ignored for non-INVITEs. Regards, Attila -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rockson Li (zhengyli) Sent: 21 August 2008 08:25 To: [email protected] Subject: [Sip-implementors] Does proxy need cancel forked non-INVITE req ? Hi folks, Suppose a proxy which forks OPTIONS to two endpoints, endpoint A responds with 200 promptly, endpoint B responds with 100. so does proxy need to send to CANCEL to endpoint B? from RFC3261, 16.7 Response Processing 10. Generate CANCELs If the forwarded response was a final response, the proxy MUST generate a CANCEL request for all pending client transactions associated with this response context. it looks proxy MUST do it. However, I wonder if it's really true. since sec 9.1 Client Behavior A CANCEL request SHOULD NOT be sent to cancel a request other than INVITE. so why proxy MUST cancel forked non-INVITE req here? thanks -Rockson _______________________________________________ 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
