SIP Message retransmission
SIP Message retransmission
If a request is lost, then timeout T1 will generate a retransmission of the request.
If a request is received and a provisional response is received, then sender switches to timeout T2 (to wait for the final response).
Timer |
default |
Purpose |
---|---|---|
T1 |
500 ms |
Set when SIP request is first sent |
T2 |
4 sec. |
Longer timeout when a provisional response has been received |
INVITE is different:
- receiving a provisional response stops all re-transmissions of the INVITE;
- however, the sender of the provisional response starts a T1 timer when it sends its final response and if it does not get an ACK in time it retransmits the final response.
If you want/need acknowledgement of provisional responses use PRACK. {For some problems with timeouts for non-INVITE transactions see RFCs 4320 and 4321.}
Slide Notes
R. Sparks, “Problems Identified Associated with the Session Initiation Protocol’s (SIP) Non-INVITE Transaction”, IETF, Network Working Group, RFC 4321,January 2006, http://datatracker.ietf.org/doc/rfc4321/ Links to an external site.
Sparks, “Actions Addressing Identified Issues with the Session Initiation Protocol’s (SIP) Non-INVITE Transaction”, IETF, Network Working Group, RFC 4320, January 2006, Updates RFC 3261, http://datatracker.ietf.org/doc/rfc4320/ Links to an external site.
Transcript
[slide166] Now, we said we need to deal with retransmission, because the messages weren't reliable. Even though we might be sending them over TCP, we could also be sending them over UDP. This means we use two timers, and the first one of these is set to 500 milliseconds. So when we send the first SIP message, we start our T1 timer. If we haven't received at least a provisional response before 500 milliseconds, what do we do? We resend that request again. But once we've gotten the provisional response, we set a new timer, T2, which is set to four seconds, which means we'll wait up to four seconds for the INVITE to get there and all of the other things to happen before we would retransmit the INVITE again. And this is, of course, to reduce the load on all the servers.