Hi, I assume that it was because some didn't notice that the following RFC 2543 section 10.5.1 text (or similar explicit text) was not included within RFC 3261. Similarly, I assume others thought the implicit text and non-normative text within RFC 3261 (and RFC 3262) was good enough.
RFC 2543 section 10.5.1: "The ACK request MUST NOT be acknowledged to prevent a response-ACK feedback loop." RFC 3262 section 1: "Also like BYE, but unlike ACK, PRACK has its own response." > -----Original Message----- > From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- > implementors-boun...@lists.cs.columbia.edu] On Behalf Of Andrea > Sent: Friday, April 03, 2015 8:56 AM > To: sip-implementors > Subject: Re: [Sip-implementors] replies to ACK > > Thanks you all for the comments that make sense to me. > I'm just wondering why IETF didn't clarify this unclear topic ;-) > > Andrea > > > 2015-04-03 14:17 GMT+02:00 Brett Tate <br...@broadsoft.com>: > > > > I looked for specific RFCs but I cannot find something clear. > > > So, the question: is it admitted that the UAS replies to the ACK > > > with a 400 bad request or it should simply ignore the malformed ACK? > > > > The ACK is a request which does not cause a response to be built/returned. > > > > RFC 3261 might contain more explicit text elsewhere; however the > > following is some of the implicit text indicating that a response > > cannot be generated for ACK. > > > > Section 17: > > > > "The client transaction is also responsible for receiving responses > > and delivering them to the TU, filtering out any response > > retransmissions or disallowed responses (such as a response to ACK)." > > > > Section 17.1: > > > > "The INVITE transaction consists of a three-way handshake. The client > > transaction sends an INVITE, the server transaction sends responses, > > and the client transaction sends an ACK." > > > > "For each final response that is received at the client transaction, > > the client transaction sends an ACK, the purpose of which is to quench > > retransmissions of the response." > > > > Section 17.1.1.3: > > > > "Although any request MAY contain a body, a body in an ACK is special > > since the request cannot be rejected if the body is not understood." _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
