| Article Index |
|---|
| Transaction layer operations in SIP |
| Page 2 |
| Page 3 |
| Page 4 |
| Page 5 |
| Page 6 |
| Page 7 |
| Page 8 |
| All Pages |
Page 3 of 8
17.1.1.2 Formal Description
The state machine for the INVITE client transaction is shown in
Figure 5. The initial state, "calling", MUST be entered when the TU
initiates a new client transaction with an INVITE request. The
client transaction MUST pass the request to the transport layer for
transmission (see Section 18). If an unreliable transport is being
used, the client transaction MUST start timer A with a value of T1.
If a reliable transport is being used, the client transaction SHOULD
NOT start timer A (Timer A controls request retransmissions). For
any transport, the client transaction MUST start timer B with a value
of 64*T1 seconds (Timer B controls transaction timeouts).
When timer A fires, the client transaction MUST retransmit the
request by passing it to the transport layer, and MUST reset the
timer with a value of 2*T1. The formal definition of retransmit
within the context of the transaction layer is to take the message
previously sent to the transport layer and pass it to the transport
layer once more.
When timer A fires 2*T1 seconds later, the request MUST be
retransmitted again (assuming the client transaction is still in this
state). This process MUST continue so that the request is
retransmitted with intervals that double after each transmission.
These retransmissions SHOULD only be done while the client
transaction is in the "calling" state.
The default value for T1 is 500 ms. T1 is an estimate of the RTT
between the client and server transactions. Elements MAY (though it
is NOT RECOMMENDED) use smaller values of T1 within closed, private
networks that do not permit general Internet connection. T1 MAY be
chosen larger, and this is RECOMMENDED if it is known in advance
(such as on high latency access links) that the RTT is larger.
Whatever the value of T1, the exponential backoffs on retransmissions
described in this section MUST be used.
If the client transaction is still in the "Calling" state when timer
B fires, the client transaction SHOULD inform the TU that a timeout
has occurred. The client transaction MUST NOT generate an ACK. The
value of 64*T1 is equal to the amount of time required to send seven
requests in the case of an unreliable transport.
If the client transaction receives a provisional response while in
the "Calling" state, it transitions to the "Proceeding" state. In the
"Proceeding" state, the client transaction SHOULD NOT retransmit the
request any longer. Furthermore, the provisional response MUST be
passed to the TU. Any further provisional responses MUST be passed
up to the TU while in the "Proceeding" state.
When in either the "Calling" or "Proceeding" states, reception of a
response with status code from 300-699 MUST cause the client
transaction to transition to "Completed". The client transaction
MUST pass the received response up to the TU, and the client
transaction MUST generate an ACK request, even if the transport is
reliable (guidelines for constructing the ACK from the response are
given in Section 17.1.1.3) and then pass the ACK to the transport
layer for transmission. The ACK MUST be sent to the same address,
port, and transport to which the original request was sent. The
client transaction SHOULD start timer D when it enters the
"Completed" state, with a value of at least 32 seconds for unreliable
transports, and a value of zero seconds for reliable transports.
Timer D reflects the amount of time that the server transaction can
remain in the "Completed" state when unreliable transports are used.
This is equal to Timer H in the INVITE server transaction, whose
default is 64*T1. However, the client transaction does not know the
value of T1 in use by the server transaction, so an absolute minimum
of 32s is used instead of basing Timer D on T1.
Any retransmissions of the final response that are received while in
the "Completed" state MUST cause the ACK to be re-passed to the
transport layer for retransmission, but the newly received response
MUST NOT be passed up to the TU. A retransmission of the response is
defined as any response which would match the same client transaction
based on the rules of Section 17.1.3.
|INVITE from TU
Timer A fires |INVITE sent
Reset A, V Timer B fires
INVITE sent +-----------+ or Transport Err.
+---------| |---------------+inform TU
| | Calling | |
+-------->| |-------------->|
+-----------+ 2xx |
| | 2xx to TU |
| |1xx |
300-699 +---------------+ |1xx to TU |
ACK sent | | |
resp. to TU | 1xx V |
| 1xx to TU -----------+ |
| +---------| | |
| | |Proceeding |-------------->|
| +-------->| | 2xx |
| +-----------+ 2xx to TU |
| 300-699 | |
| ACK sent, | |
| resp. to TU| |
| | | NOTE:
| 300-699 V |
| ACK sent +-----------+Transport Err. | transitions
| +---------| |Inform TU | labeled with
| | | Completed |-------------->| the event
| +-------->| | | over the action
| +-----------+ | to take
| ^ | |
| | | Timer D fires |
+--------------+ | - |
| |
V |
+-----------+ |
| | |
| Terminated|<--------------+
| |
+-----------+
Figure 5: INVITE client transaction
If timer D fires while the client transaction is in the "Completed"
state, the client transaction MUST move to the terminated state.
