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
