Sorry about the resend; however for completeness, I should also mention the following 2 quotes since some vendors (those that ignore the first quote) only apply the 481 snippet from RFC 3262 when deciding if 481 should be returned for PRACK.
RFC 3262 section 3: "PRACK is like any other request within a dialog, and the UAS core processes it according to the procedures of Sections 8.2 and 12.2.2 of RFC 3261." "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." > -----Original Message----- > From: Brett Tate [mailto:br...@broadsoft.com] > Sent: Friday, August 19, 2016 9:54 AM > To: 'Sourav Dhar Chaudhuri'; 'Sip-implementors' > Subject: RE: [Sip-implementors] UAS behavior on receiving PRACK request > after > failed final response for INVITE > > > So what should be the expected behavior of UAS? > > As you noticed, RFC 3262 section 3 indicates "it MUST be prepared to > process > PRACK requests for those outstanding responses". > > With that said, vendors likely vary concerning how they handle the race > condition. For instance, some might return 481; others might return 200 > (even if PRACK contains an offer SDP). If the PRACK is extremely late, I > assume that all would return 481 if they comply with the following RFC > 3261 > snippet. > > RFC 3261 section 12.2.2: > > "If the UAS wishes to reject the request because it does not wish to > recreate > the dialog, it MUST respond to the request with a 481 (Call/Transaction > Does > Not Exist) status code and pass that to the server transaction." _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
