Thanks for the response. Reply inline.
> Also, UAS is not supposed to send final response to initial > INVITE, unless it receives PRACK. That statement is only true for some situations; I'm referring to situations where it is valid. Concerning your supporting quote reference (below), it sounds like you are misinterpreting when the "MUST NOT send" applies. > From RFC: "The UAS MAY send a final response to the initial > request before having received PRACKs for all unacknowledged > reliable provisional responses, unless the final response is > 2xx and any of the unacknowledged reliable provisional responses > contained a session description. In that case, it MUST NOT > send a final response until those provisional responses are > acknowledged." > > From above statements, even though UAS has sent the final > response to initial INVITE, which it was not supposed send, > it must be prepared to process the PRACK and acknowledge it. > So, it must send 200 OK for PRACK and not reject it with 481. Processing the late PRACK and having to send 200 OK are two separate things. One of the common debates/ambiguities concerning rfc3262 relates to some interpreting the RFC in a way which usually requires sending 200 responses. It has been and continues to be debated. RFC 3262 section 3 indicates: "If the UAS does send a final response when reliable responses are still unacknowledged, it SHOULD NOT continue to retransmit the unacknowledged reliable provisional responses, but it MUST be prepared to process PRACK requests for those outstanding responses." I'm attempting to find out if it is acceptable to send 481 response for unacknowledged reliable response's PRACK when the dialog still exists. However the answer likely falls within the typical 200 response debate. Those that think the 200 typically needs to be sent would say that the 200 needs to be sent for the late PRACK if received within 64*T1 (or even not apply the 64*T1 limit). Those that don't think 200 is typically needed would say that a 481 can be sent since a 200 is misleading if unwilling to fully update things per late PRACK's headers/content. > > The relevance is mainly associated with somehow trying to communicate > > unwillingness to fully update the dialog per PRACK's headers/content > > because of race condition. > > From RFC 3261: "If the PRACK contained a session description, it is > processed as described in Section 5 of this document. If the PRACK > instead contained any other type of body, the body is treated in > the same way that body in an ACK would be treated.". > > So, 481 cannot be the response in your case. I'm not sure that I understand the relevance of your RFC 3261 (actually RFC 3262) quote in supporting opinion that 481 can't be sent. _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
