SHIV SINGH wrote: > Hi All, > Now I am clear about the handling of ACK. > Mime-Version: 1.0 > Content-Transfer-Encoding: 7bit > Content-Type: text/plain; charset=us-ascii > > Please can you put some light on the issue of 200OK: > Should I stop the re-transmission of 200OK after getting Wrong ACK or I need > to continue? >
IMO, if the ACK has correctly formed headers and matches your retransmission correctly, then you should STOP. It is highly unlikely that retransmitting further would solicit a correctly formed ACK. If proper function of the call relies on the body of the ACK message, then it is up to the application to decide whether to continue with the call or termiante it with a BYE. Probably with a Reason: SIP; cause=400; text="Bad Request" in the headers. > Because after getting ACK even with wrong content-length, state of call is > getting changed from completed to confirmed and later we are deleting the > transaction because it is wrong ACK. > > Your transaction should have been deleted upon sending the 200 OK. Receipt or none-receipt of ACK is irrelevant. > Thanks & Regards, > Shiv > > --- On Wed, 18/6/08, Paul Kyzivat <[EMAIL PROTECTED]> wrote: > From: Paul Kyzivat <[EMAIL PROTECTED]> > Subject: Re: [Sip-implementors] Call does not go through if ACK is received > withContent-Length more than the actual body size > To: "Brett Tate" <[EMAIL PROTECTED]> > Cc: [email protected] > Date: Wednesday, 18 June, 2008, 5:54 PM > > While you could simply ingore the ACK, that probably isn't helpful in > getting things working. > > I'd be inclined to just pad out the message to the specified length. > That then may result in a body that is incorrectly formatted. But for > ACK that will only be the case if there is an ansswer in the ACK. If so, > you can then cope with the errors found in the body. > > But generally this is an error case that you can cope with as find works > best for you. > > Paul > > Brett Tate wrote: > >>> Please can you tell me the behavior of UAS in >>> the following case: >>> If UAS is getting the ACK with content-length more >>> than the actual body length and all the headers >>> are correct? >>> >> See rfc3261 section 18.3. However since there is no response for ACK, >> the "SHOULD generate a 400" does not apply. The ACK should be >> > discarded > >> similar to what occurs for 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 > > > Bring your gang together. Do your thing. Find your favourite Yahoo! > group at http://in.promos.yahoo.com/groups/ > _______________________________________________ > 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
