Hi Brett, Thanking you for the reply !!! I could understand the points explained clearly .However i would like to bring in your notice the same RFC 3261 indicates " If there is no final response for the original request in 64*T1 seconds the client SHOULD then consider the original transaction cancelled and SHOULD destroy the client transaction handling the original request."
RFC 3261 section 9.1 indicates to expect the final response up to 64*T1 (i.e. 32 seconds) after the CANCEL acknowledgement. "Note that both the transaction corresponding to the original request and the CANCEL transaction will complete independently. However, a UAC canceling a request cannot rely on receiving a 487 (Request Terminated) response for the original request, as an RFC 2543- compliant UAS will not generate such a response. If there is no final response for the original request in 64*T1 seconds (T1 is defined in Section 17.1.1.1), the client SHOULD then consider the original transaction cancelled and SHOULD destroy the client transaction handling the original request." Therefore In my case The original Invite Message has been sent at 15:51:00 and CANCEL request sent at 15:51:16 from UAC i.e(SOURCE) and is being acknoledged with 200 OK at 15:51:16 by the PROXY. However the same PROXY is sending the error SERVER TIMEOUT at 15:52:00 which is more than the time(64*T1) specified/allowed to respond to original INVITE request .So my question on TIMER expiry seems to be a valid one as to why the SBG (PROXY) is not responding on time (pls note that the time difference between 7th INVITE and 504 Message is again 30secs.Does the SBG takes that much time to respond? What should be the time to respond to source indicating the reason of time out? I would request to spare a thought on this and would be thankful if you can correct me incase i am wrong. Regards Sampat ________________________________ From: Brett Tate <br...@broadsoft.com> To: sampat patnaik <sam_e...@yahoo.co.in>; "sip-implementors@lists.cs.columbia.edu" <sip-implementors@lists.cs.columbia.edu> Sent: Saturday, 21 September 2013 1:26 AM Subject: RE: [Sip-implementors] SIP ISSUE The attachment won't make it through. If you want someone to verify that the CANCEL was truly built correctly, you can provide the INVITE and CANCEL. > 1)Don't you think there can be a issue at SBG end > because "When a CANCEL message is being sent by > Source to cancel the ORIGINAL INVITE request and > is being acknowledged by PROXY server with a > 200 OK message. However the same PROXY server is > sending the 7th INVITE message and finally in turn > generates this 504 error and floods towards UAC. It sounds like you prefer RFC 2543 instead of RFC 3261. :) "Note that both the transaction corresponding to the original request and the CANCEL transaction will complete independently." As far as I know, the proxy is behaving per RFC 3261 (although another failure response such as 408 or 487 might be more appropriate). However, some proxies might not try so hard to receive the 1xx so that they can CANCEL it. As far as I know, the UAC is not following RFC 3261 section 9.1. > However my point is what is the use of sending this > CANCEL request by UAC. Does that mean that there is > no significance to this CANCEL request. It has significance; however atypical situations exist. Section 15 provides a good summary concerning the significance of CANCEL. "The impact of a non-2xx final response to INVITE on dialogs and sessions makes the use of CANCEL attractive. The CANCEL attempts to force a non-2xx response to the INVITE (in particular, a 487)." > I think the UAC should have the authority to do > end to end Cancellation. Okay; however that isn't how it works. > But what i am seeing is the entire responsibility / > response is dependent on UAS here because inspite of > receiving a request for CANCEL at 15:51:16 secs , > it sends 7th INVITE message at 15:51:32 .so there is > a gap of 16secs. Yes; and RFC 3261 section 9.1 indicates to expect the final response up to 64*T1 (i.e. 32 seconds) after the CANCEL acknowledgement. "Note that both the transaction corresponding to the original request and the CANCEL transaction will complete independently. However, a UAC canceling a request cannot rely on receiving a 487 (Request Terminated) response for the original request, as an RFC 2543- compliant UAS will not generate such a response. If there is no final response for the original request in 64*T1 seconds (T1 is defined in Section 17.1.1.1), the client SHOULD then consider the original transaction cancelled and SHOULD destroy the client transaction handling the original request." _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
