HP-UX C SIP Stack Programmer's Guide (Novembery 2007)

Working with Transactions 115
Transaction State Machine
RVSIP_TRANSC_STATE_SERVER_CANCEL_REQUEST_RCVD
Upon receipt of a CANCEL request that is not a retransmission by a server
transaction, the transaction assumes the
SERVER_CANCEL_REQUEST_RECEIVED state. In this state, it is up to you
to respond to the request with the Transaction API functions. You may begin
with sending provisional responses. You must end with sending a final response,
or terminating the transaction. This state is used only if the SIP Stack is
configured as a proxy. Otherwise, the CANCEL is responded to automatically.
RVSIP_TRANSC_STATE_SERVER_CANCEL_FINAL_RESPONSE_SENT
If your application is not a Proxy implementation, when a CANCEL request is
received, it is automatically handled by the Transaction layer. The transaction
will initiate the response to the CANCEL by itself and the transaction will
assume the SERVER_CANCEL_FINAL_RESPONSE_SENT state. If your
application is a Proxy implementation it is your responsibility to send a final
response for the CANCEL request. When you send a final response, the
transaction will move to this state.
In any application (Proxy or not) when entering this state, a transaction timer is
set to generalLingerTimer if the transport is an unreliable transport. When this
timer expires, the transaction is terminated and assumes the TERMINATED
state. If the transport is a reliable transport the transaction is terminated and
assumes the TERMINATED state immediately when it reaches this state. (Timer
J as defined in RFC 3261).