Hi Brett, From RFC 3262 section 3 snippets that you have quoted: "If the PRACK does match an unacknowledged reliable provisional response, it MUST be responded to with a 2xx response." and "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."
Also, UAS is not supposed to send final response to initial INVITE, unless it receives PRACK. 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. <<Brett>> 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. Thanks, Aneesh On Tue, Feb 16, 2010 at 12:46 AM, Brett Tate <[email protected]> wrote: > Howdy, > > RFC 3262 allows the UAS to send a final response (such as 200 OK) to INVITE > within some situations while there are still outstanding unacknowledged > reliable provisional response. Is it acceptable to send 481 response for > unacknowledged reliable response's PRACK when the dialog still exists? 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. > > RFC 3262 section 3 snippets: > > "If a PRACK request is received by the UA core that does not match any > unacknowledged reliable provisional response, the UAS MUST respond to the > PRACK with a 481 response. If the PRACK does match an unacknowledged > reliable provisional response, it MUST be responded to with a 2xx response." > > "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." > > > _______________________________________________ > 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
