An often misunderstood concept is stateful vs. stateless processing. The description of the INVITE SIP transaction above is an example of stateful processing. This means that SER will know that the OK belongs to the initial INVITE and you will be able to handle the OK in an onreply_route[x] block. With stateless processing (or simply forwarding), each message in the dialogue is handled with no context. Stateless forwarding is used for simple processing of SIP messages like load distribution.

In order to implement any advanced functionality like call accounting, forward on busy, voicemail, and other functionality in this documents reference setup, you will need to use stateful processing. Each SIP transaction will be kept in SERs memory so that any replies, failures, or retransmissions can be recognized. One consequence is that when using t_relay() for a SIP message, SER will recognize if a new INVITE message is a resend and will act accordingly. If stateless processing is used, the resent INVITE will just be forwarded as if it was the first.

The confusion arises because this stateful processing is per SIP transaction, not per SIP dialog (or an actual phone call)! A phone call (SIP dialog) consists of several transactions, and SER does not keep information about transactions throughout a particular phone call. The consequence is that SER cannot terminate an on-going call (it doesnt know that the call is on-going), nor can SER calculate the length of an ended call (accounting). However, SER can store when an INVITE (or ACK) and a BYE message are received and record this info together with the Call-Id. A billing application can then match the INVITE with the BYE and calculate the length of the call.