|
Page 7 of 8
17.2 Server Transaction
The server transaction is responsible for the delivery of requests to
the TU and the reliable transmission of responses. It accomplishes
this through a state machine. Server transactions are created by the
core when a request is received, and transaction handling is desired
for that request (this is not always the case).
As with the client transactions, the state machine depends on whether
the received request is an INVITE request.
17.2.1 INVITE Server Transaction
The state diagram for the INVITE server transaction is shown in
Figure 7.
When a server transaction is constructed for a request, it enters the
"Proceeding" state. The server transaction MUST generate a 100
(Trying) response unless it knows that the TU will generate a
provisional or final response within 200 ms, in which case it MAY
generate a 100 (Trying) response. This provisional response is
needed to quench request retransmissions rapidly in order to avoid
network congestion. The 100 (Trying) response is constructed
according to the procedures in Section 8.2.6, except that the
insertion of tags in the To header field of the response (when none
was present in the request) is downgraded from MAY to SHOULD NOT.
The request MUST be passed to the TU.
The TU passes any number of provisional responses to the server
transaction. So long as the server transaction is in the
"Proceeding" state, each of these MUST be passed to the transport
layer for transmission. They are not sent reliably by the
transaction layer (they are not retransmitted by it) and do not cause
a change in the state of the server transaction. If a request
retransmission is received while in the "Proceeding" state, the most
recent provisional response that was received from the TU MUST be
passed to the transport layer for retransmission. A request is a
retransmission if it matches the same server transaction based on the
rules of Section 17.2.3.
If, while in the "Proceeding" state, the TU passes a 2xx response to
the server transaction, the server transaction MUST pass this
response to the transport layer for transmission. It is not
retransmitted by the server transaction; retransmissions of 2xx
responses are handled by the TU. The server transaction MUST then
transition to the "Terminated" state.
While in the "Proceeding" state, if the TU passes a response with
status code from 300 to 699 to the server transaction, the response
MUST be passed to the transport layer for transmission, and the state
machine MUST enter the "Completed" state. For unreliable transports,
timer G is set to fire in T1 seconds, and is not set to fire for
reliable transports.
This is a change from RFC 2543, where responses were always
retransmitted, even over reliable transports.
When the "Completed" state is entered, timer H MUST be set to fire in
64*T1 seconds for all transports. Timer H determines when the server
transaction abandons retransmitting the response. Its value is
chosen to equal Timer B, the amount of time a client transaction will
continue to retry sending a request. If timer G fires, the response
is passed to the transport layer once more for retransmission, and
timer G is set to fire in MIN(2*T1, T2) seconds. From then on, when
timer G fires, the response is passed to the transport again for
transmission, and timer G is reset with a value that doubles, unless
that value exceeds T2, in which case it is reset with the value of
T2. This is identical to the retransmit behavior for requests in the
"Trying" state of the non-INVITE client transaction. Furthermore,
while in the "Completed" state, if a request retransmission is
received, the server SHOULD pass the response to the transport for
retransmission.
If an ACK is received while the server transaction is in the
"Completed" state, the server transaction MUST transition to the
"Confirmed" state. As Timer G is ignored in this state, any
retransmissions of the response will cease.
If timer H fires while in the "Completed" state, it implies that the
ACK was never received. In this case, the server transaction MUST
transition to the "Terminated" state, and MUST indicate to the TU
that a transaction failure has occurred.
|INVITE
|pass INV to TU
INVITE V send 100 if TU won't in 200ms
send response+-----------+
+--------| |--------+101-199 from TU
| | Proceeding| |send response
+------->| |<-------+
| | Transport Err.
| | Inform TU
| |--------------->+
+-----------+ |
300-699 from TU | |2xx from TU |
send response | |send response |
| +------------------>+
| |
INVITE V Timer G fires |
send response+-----------+ send response |
+--------| |--------+ |
| | Completed | | |
+------->| |<-------+ |
+-----------+ |
| | |
ACK | | |
- | +------------------>+
| Timer H fires |
V or Transport Err.|
+-----------+ Inform TU |
| | |
| Confirmed | |
| | |
+-----------+ |
| |
|Timer I fires |
|- |
| |
V |
+-----------+ |
| | |
| Terminated|<---------------+
| |
+-----------+
Figure 7: INVITE server transaction
The purpose of the "Confirmed" state is to absorb any additional ACK
messages that arrive, triggered from retransmissions of the final
response. When this state is entered, timer I is set to fire in T4
seconds for unreliable transports, and zero seconds for reliable
transports. Once timer I fires, the server MUST transition to the
"Terminated" state.
Once the transaction is in the "Terminated" state, it MUST be
destroyed immediately. As with client transactions, this is needed
to ensure reliability of the 2xx responses to INVITE.
|
