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
