Yes, this ACK is to seize retransmission of non-2xx response by INV transaction and hence the ACK for non-2xx response MUST be processed by transaction layer and not to be delivered to TU.
Regards, Manjunath -----Original Message----- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Andrea Sent: Friday, 3 April, 2015 7:03 PM To: sip-implementors Subject: Re: [Sip-implementors] replies to ACK Thanks! And there is also this >> Similarly, the purpose of the server transaction is to receive requests from the transport layer and deliver them to the TU. The server transaction filters any request retransmissions from the network. The server transaction accepts responses from the TU and delivers them to the transport layer for transmission over the network. In the case of an INVITE transaction, it absorbs the ACK request for any final response excepting a 2xx response. Does it mean that the server should filter out (absorb, so ignore) the ACK for non 2xx response? Andrea 2015-04-03 12:04 GMT+02:00 WARAD, MANJUNATH (MANJUNATH) < manjunath.wa...@alcatel-lucent.com>: > Andrea, > > ACK requests shouldn't be responded even if its malformed. Either it > should be processed or silently ignored. > > Further, clients are also not supposed to handle responses to ACK. > > Though it is not explicitly mentioned, here are some excerpts which is > implicit to say that ACK shouldn't be responded. > > >> 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). > > > >> While a server can legitimately challenge most SIP requests, there > are two requests defined by this document that require special > handling for authentication: ACK and CANCEL. > > Under an authentication scheme that uses responses to carry values > used to compute nonces (such as Digest), some problems come up for > any requests that take no response, including ACK. > > > Regards, > Manjunath > > > -----Original Message----- > From: sip-implementors-boun...@lists.cs.columbia.edu [mailto: > sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Andrea > Sent: Friday, 3 April, 2015 5:11 PM > To: sip-implementors > Subject: Re: [Sip-implementors] replies to ACK > > Thanks for your fast answers! > Is there any RFC statements regarding the fact that UAS should ignore > the malformed ACK? > I have to persuade the UAS implementor! > Thanks > > Andrea > > > 2015-04-03 11:04 GMT+02:00 Alok Tiwari <alo...@globallogic.com>: > > > Hi Andrea, > > UAS should simply ignore the malformed ACK messages. Since the ACK > > message is malformed, UAS will re-transmit the 400 response of > > INVITE for 32 seconds. > > > > Thanks, > > Alok Tiwari > > > > On Fri, Apr 3, 2015 at 2:29 PM, Andrea <fuffa...@gmail.com> wrote: > > > >> Hi, > >> we are facing an issue where a malformed INVITE generate a message > >> storm (loop). > >> UAC send a malformed INVITE to UAS (from and contact header > >> invalid) UAS replies with error 400 bad request UAC send a > >> malformed ACK to UAS (from and contact header invalid) UAS replies > >> with error 400 bad request in response to the malformed ACK UAC > >> send a malformed ACK to UAS in response to the latest 400 bad req and the > >> loop continues.... > >> > >> this generate a message storm that is consuming cpu resources for > >> 32 seconds. > >> > >> > >> 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? > >> > >> > >> Thanks in advance > >> > >> > >> Andrea > >> _______________________________________________ > >> Sip-implementors mailing list > >> Sip-implementors@lists.cs.columbia.edu > >> https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > >> > > > > > > > > -- > > Alok Tiwari | Consultant > > GlobalLogic > > P +91.120.406.2000 x 2477 M +91.991.034.7139 S > > alo...@globallogic.com <http://alok.t_globallogic.com/> > > www.globallogic.com <http://www.globallogic.com/> > > http://www.globallogic.com/email_disclaimer.txt > > > _______________________________________________ > Sip-implementors mailing list > Sip-implementors@lists.cs.columbia.edu > https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
