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

Reply via email to