> 1)Incase that case what is expected out of source node.. > i.e the SBG(proxy) must be expecting an ACK message to > the error 504 sent..right?
Yes. RFC 3261 section 9.1: "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." > 2) second query would be why not this CANCEL message is > forwarded to next hop i.e destination node .should the flow > mentioned below be followed: RFC 3261 requires a 1xx to be received before sending a CANCEL. Section 9.1 (referenced by 16.7 and 16.10) "If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request." "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." > 3) i would suspect that the INVITE in F11 message(trailing mail) is > becoz the cancel request is not being sensed by the SBG and is busy > in resending the REINVITE message to the destination(maximum 7 invites > due to timer issue of 64*T1 i.e 32secs) .Also i thing the error > 504 is populated because there is time out error generated after destn > server failed to respond to 7th(F11) reinvite request and is > flooded to sorce side expecting an ACK before ending the entire > process. You mentioned REINVITE. Are your questions about an INVITE or re-INVITE? > 4)what would have happened had there not been that F11 invite message? I don't understand the question. > I am currently facing an issue that as follows :..my question is why > PROXY1 is unable to process the CANCEL message in this case. The proxy processed the CANCEL; the proxy returned a 2xx response. > CASE: REMOTE NODE IS COMPLETELY DOWN and we need to understand why > flooding of 504 sip error is happening towards source side while > it is not responding with ACK mesg The proxy is retrying the response per RFC 3261 section 17.2.1. The UAC is not acting per RFC 3261 since it did not wait 64*T1 for final response. > 504 message is sent 11 times from proxy to source.. > why this abnormal behavior? Ask the UAC vendor why they are not ACKing the 504. There might be configuration option to comply with RFC 3261 (i.e. wait longer for the final response). NOTE: RFC 2543 did not require completing INVITE transactions (such as with a 487). _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
