John Williams wrote: > Thank you for your responses Vikram and Sanjay. > > I was asking to myself a wrong question... > > Now I know and I will remember that ACK is not retransmitted, but that a > new ACK is sent for each final response, would it be from transaction > layer or an upper layer. > > >
ACK for a 200 final response is sent by the UA Core. ACK for error final responses is handled by the transaction layer. > john > > Le mardi 27 février 2007 à 12:22 +0530, Vikram Chhibber a écrit : > >> There are two types of ACK which has different handling mechanism. >> There is no retransmissions for ACK. ACK is always sent in response to >> "response". >> ACK for 200 OK is end-to-end and is sent whenever 200 OK is received >> by the application. This is Route constructed from Record-Route of 200 >> OK and request-uri modified to the Contact. >> ACK for final failure response is hop-to-hop and is sent whenever >> retransmitted final failure response is received for the interval of >> Timer-D (Usually 64*T1). The later case is usually handled by the >> transaction layer and not by the application as the first final >> response received terminates the dialog in the application. >> On 2/27/07, John Williams <[EMAIL PROTECTED]> wrote: >> >>> Hello, >>> >>> I have several questions about retransmissions in a UAC, especially ACK >>> retransmission : >>> >>> 1. When an ACK request must be retransmitted ? and how ? >>> >>> I've been looking in RFC 3261 in 17.1.1.3 for 3xx/6xx ACK and in >>> 13.2.2.4 for 2xx ACK. ACK construction is detailed but I did not found >>> the retransmission process. In 13.2.2.4 : >>> >>> The ACK MUST be passed to the client transport every time a >>> retransmission of the 2xx final response that triggered the ACK >>> arrives. >>> >>> Ok, but this is not really an ACK retransmission as it is triggered by >>> the arrival of another 2xx response. >>> >>> The UAC core considers the INVITE transaction completed 64*T1 seconds >>> after the reception of the first 2xx response. At this point all the >>> early dialogs that have not transitioned to established dialogs are >>> terminated. Once the INVITE transaction is considered completed by >>> the UAC core, no more new 2xx responses are expected to arrive. >>> >>> Ok, that says when ACK retransmissions must be stopped, but not when >>> (and how) retransmissions are triggered. I think they can be triggered >>> like regular requests (exponential T1 timer), but there is no response >>> to stop ACK retransmission... There must be something I misunderstood. >>> >>> 2. Is it necessary to retransmit an ACK if a transport error occured >>> while sending the first ACK ? >>> >>> That would be the trigger I am looking for. >>> >>> 3. More generally, is it necessary to retransmit a request if a >>> transport error occured (creating a new transport) ? >>> >>> I think it is not necessary, but I am not sure. >>> >>> >>> Thanks, >>> >>> john >>> >>> _______________________________________________ >>> 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 > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
