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

Working with Transactions 101
Transaction State Machine
For UA applications, the callback is called only for initial REFER/SUBSCRIBE
methods. Applications that do not want the SIP Stack implementation for
REFER and SUBSCRIBE that opens a new dialog should implement this
callback.
This callback will be called for the INVITE method as well only if the
bDynamicInviteHandling configuration parameter is set to RV_TRUE. In this
case, the application will be able to handle incoming INVITE requests above the
Transaction layer.
RvSipTransactionFinalDestResolvedEv()
This event indicates that the transaction is about to send a message after the
destination address was resolved. This event supplies the final message.
Changes in the message at this stage will not effect the destination address.
When this event is called, the application can query the transaction about the
destination address using the RvSipTransactionGetCurrentDestAddress() API
function. If the application wishes, it can update the “sent-by” part of the top-
most Via header. The application must not update the branch parameter. To
change the destination address resolved from the message, the application must
use the Transmitter API. The application should first get the transmitter from
the transaction using the RvSipTransactionGetTransmitter() API function. It
can then manipulate the DNS list and current destination address of the
transmitter before the message is sent. For more information see the Working
with Transmitters chapter.
TRANSACTION
S
TATE MACHINE
The Transaction state machine represents the state of the transaction between
the client and the server. The state machine is divided into the following parts:
 Client General transaction
 Server General transaction
 Client INVITE transaction
 Server INVITE transaction
 Client CANCEL transaction
 Server CANCEL transaction
The RvSipTransactionStateChangedEv() callback reports transaction state
changes and state change reasons. The state change reason indicates why the
transaction reached the new state.
A transaction will assume either of the following two states, which are common
to all state machines: