Hi, As far as I understand section 17 from RFC 3261, the invite client transaction must to send an ACK for any final response received after sending the INVITE. This client transaction still stays alive for 64*T1 and it should re-send with an ACK for any final response retransmited by UAS. After 64*T1, with timeout, this client transaction should be setted to TERMINATED state.
Into an ideal environment, no final response will be received. Into a pratical one, once receiving some final response referenced for an transaction already terminated, the response shall be sent by core. The core, by the way, shall check if the dialog exists and decides what to do. For example, only sends an ACK, send an ACK followed by a BYE, send an ACK and modify the RTP connection, or any other implemmentation issue. Please, understand "final response" as any response from 2xx to 6xx. Leonardo ________________________________ De: yan wang <[email protected]> Para: [email protected] Enviadas: Sexta-feira, 27 de Maio de 2011 5:01 Assunto: [Sip-implementors] Is it a wrong statement about SIP client transaction in RFC 3261? Hi, Recently, I was reading the SIP fundamental RFC 3261. Regarding “Chapter 17 Transactions”, I found there may be a wrong statement for client transaction in the following excerpt: 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). Additionally, in the case of an INVITE request, the client transaction is responsible for generating the ACK request for any final response accepting a 2xx response. I highlight it with RED and GREEN. With my understanding, it should be: the client transaction is responsible for generating the ACK request for any final response “EXCEPTING” (not accepting) a 2xx response since the generation of the ACK for the 2xx is handled by the UA core but not the client transaction. Is it a wrong statement for SIP client transaction definition in RFC 3261? Thanks,Spencer Wang _______________________________________________ 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
