Thanks Brett for the detail explanation. So retransmission is needed in any transport layer.
Related question, how about PRACK-response on TCP? if UA sends PRACK on TCP does not receive 200 OK for prack? should it retransmit? if so what is the Timer On Thursday, April 17, 2014 12:39 PM, Brett Tate <br...@broadsoft.com> wrote: Hi, It doesn't sound like you are interpreting section 13.3.1.4 correctly. Using default values, retransmissions occur .5, 1, 2, 4, 4, 4, ... until the 64*T1 timer pops. Also notice that 2xx is retransmitted over TCP. "Once the response has been constructed, it is passed to the INVITE server transaction. Note, however, that the INVITE server transaction will be destroyed as soon as it receives this final response and passes it to the transport. Therefore, it is necessary to periodically pass the response directly to the transport until the ACK arrives. The 2xx response is passed to the transport with an interval that starts at T1 seconds and doubles for each retransmission until it reaches T2 seconds (T1 and T2 are defined in Section 17). Response retransmissions cease when an ACK request for the response is received. This is independent of whatever transport protocols are used to send the response. Since 2xx is retransmitted end-to-end, there may be hops between UAS and UAC that are UDP. To ensure reliable delivery across these hops, the response is retransmitted periodically even if the transport at the UAS is reliable. If the server retransmits the 2xx response for 64*T1 seconds without receiving an ACK, the dialog is confirmed, but the session SHOULD be terminated. This is accomplished with a BYE, as described in Section 15." And for completeness, you might want to look at RFC 6026 since it introduced more INVITE related timers to the transaction state machine. -brett -- This email is intended solely for the person or entity to which it is addressed and may contain confidential and/or privileged information. If you are not the intended recipient and have received this email in error, please notify BroadSoft, Inc. immediately by replying to this message, and destroy all copies of this message, along with any attachment, prior to reading, distributing or copying it. _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/mailman/listinfo/sip-implementors