Stateful Vs Stateless

very good explaining:

— Stateless. This mode is defined by RFC 3261 to be fully stateless, even for individual transactions. This means that the session router simply passes messages from inbound to outbound interfaces according to policy. Destinations for stateless routers should be time invariant according to RFC 3261. All retransmissions are handled by source/destination, which makes transport interworking impractical for a stateless session router. Limited applicability.

— Transaction stateful. The SR does not store information about the session or dialog for future use. This minimizes impact on memory but does not allow the SR to store and forward information related to accounting. Memory allocation and use is much lower than session/dialog modes, however, allowing a higher CPS with an arbitrary call hold time. According to RFC 3261, once the dialog is established, a transaction stateful SR is not required to stay in the path, however it may do so with the use of Record Route. This means a transaction stateful SR may relay only INVITE, 100 Trying, 18x and 200OK messages, with ACK, in-dialog (including PRACK) and BYE requests bypassing the session router for maximum performance.

— Session Stateful. The SR stores information about sessions as an RFC 3261 session stateful proxy, but does not act as a B2BUA to implement full topology hiding. Rather, the SR incorporates Record Route and manages session state, passing Contact and Via information intact. The SR does store session information, but there is no media management and therefore no information related to media flows within abbreviated call detail records. Aside from CPU, a limiting factor in the SR session stateful mode may include memory, so RAM, call hold times and session counts are important sizing factors.

— Dialog Stateful. The SR acts as a B2BUA in the same manner as a full SBC, though there is no media management. Call detail records reflect the B2BUA and do have some additional media information in CDRs. Full topology hiding is implemented and additional dialog information is stored as a result. Full header processing impacts overall performance, though memory may still be an important sizing consideration. Therefore call hold times and dialog counts must be considered for sizing.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License