Transaction Creation And Maintenance

The stack scans the transaction hash table for an existing transaction when the stack receives incoming requests and responses. If a transaction that matches an incoming response does not exist, the stack handles the transaction statelessly. When an incoming request requires the stack to create a transaction, the application notifies the stack of the need to create a transaction when the application sends the response. In both cases, the stack passes the message to the application. If a request matches a transaction, the stack considers the request a retransmission and the transaction layer retransmits the last response. The stack drops the incoming request and does not pass the request to the application. The CANCEL request and an ACK for a non-2xx response are exceptions to this behavior. A CANCEL request matches the INVITE transaction that it is cancelling. An ACK for a non-2xx response also matches the INVITE request whose response the ACK is acknowledging. In these two cases, the request is not a retransmission and the stack sends the request sent to the application. If a response matches a transaction, the stack processes the response and statefully passes the message to the application.

The stack only creates a transaction for an outgoing response when the application requests the transaction creation by using the sip_sendmsg() function. The stack only creates a transaction for outgoing requests if the application requests the transaction creation by using the sip_sendmsg() function. The stack caches the transaction creating message and the last message that was sent on a transaction. This cache facilitates retransmissions and the processing of retransmitted requests. The stack initializes timers A, B, D, E, F, G, H, I, J and K for new transactions. See Appendix A for more information about timers.

When a message causes a transaction to change states, the stack invokes a callback function if the application registered a callback function with the stack.