have been met and that the user may now be alerted, and the 180 Ringing
response sent. The call then continues as per normal. Note that the need for
QoS was indicated in the last line of the SDP of the initial INVITErequest, as
shown here with the attribute qos:mandatory:INVITE with mandatory QoS request
INVITE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 100.101.102.103:5060;branch=z9hG4bK765d
To: <sip:[email protected]>
From: User A <sip:[email protected]>
Call-ID: 5448kewl13981304oierek
Max-Forwards: 0
CSeq: 1 INVITE
Contact: sip:[email protected]
Content-Length: ...v=0
c=IN IP4 100.101.102.102
m=audio 47172 RTP/AVP 0
a=rtpmap:0 PCMU/8000
a=qos:mandatory122 Chapter 6
MESSAGE RETRANSMISSIONS IN SIP
The base SIP specification allows almost any lost request or response method
to be automatically retransmitted. The sender of a SIP request using
nonreliable transport starts a timer, called T1 (default value is 500ms). If a
response is not received before the expiration of the timer, the request is
retransmitted. If a provisional (1xx) response is received, the sender switches
to a second longer timer, called T2 (default value 4 seconds). If the request
itself is lost, the recipient will not have received it and will never generate a
response. After the expiration of T1, the sender will resend the request. If
the response to the request is lost, the sender will again resend the request.
The recipient will recognize the request as a retransmission and retransmit its
own response.
Handling of INVITErequests is slightly different than all other request types,
since it may take a long time for the call to be answered by a person. The
receipt of a provisional response to an INVITEdoes not switch to timer T2 but
stops all retransmissions of the INVITE. A responder to an INVITEstarts timer
T1 when it sends a final response. If an ACKis not received, the responder
resends the final response. This allows a lost INVITE, final response, or ACKto
be detected and retransmitted.
The exceptions to this retransmission rule are provisional responses. Since
provisional responses do not receive an ACK, there is no way for either party to
know if one has been lost. The Reliable Provisional Response [23] extension to
SIP was developed to allow a provisional response to be acknowledged with a
PRACK, thus providing reliability for all requests and responses in SIP.