-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
On 27-02 10:20, Greg Fausak wrote:
I'm trying to understand stateful vs. stateless transactions.
A stateless 'transaction' simply lasts as long as it takes to process the current sip request. It is then forgotten.
Yes, if you do not use tm module, the server will be stateless. Upon a message reception the server executes the route section of the configuration script. After that the server forgets everything and is ready to process next requests. Stateless servers process all requests and responses independently, they do not keep any state associated with them.
However, a stateful transaction I'm having a little problem grasping. For instance, if I t_relay() an INVITE, logically the transaction is started....so when the response comes it isn't delivered to the main route {} block, but instead it is delivered to the awaiting stateful t_relay(), probably keyed by callid. So, for instance:
t_relay is a stateful version of forward function. If you use t_relay, the server will forward the request _AND_ create an internal structure. The structure persists in the memory for some time (even if the original request has already been forwarded).
When a response to the request comes, the server tries to lookup the structure it previously created for the request. If there is a RFC3261 compatible branch in the topmost via, it serves as a key to the array of all the structures, if there is no such branch parametr, hash of various message headers is used as the key.
It is important to understand that the route script is executed for requests only, responses do not trigger execution of the script. (Although there are so called reply-route blocks which can be called from tm module for responses).
INVITE <- 401 Unauthorized ->
Is this entire sequence a transaction? Right after this the UA sends an ACK, this is a transaction unto itself?
When a 2xx response (to the original INVITE) comes, the INVITE transaction is destroyed immediately, that implies that ACK creates a new transaction.
When a 3xx-699 response come, the original transaction is not destroyed and ACK is part of the original transaction.
INVITE-100-200 belong to the same transaction (ACK is not part of the transaction) INVITE-300-ACK belong to the same transaction
ACK <-
The UA then sends :
INVITE <- 100 Trying -> 180 Ringing -> 200 OK ->
All of these messages are a 'transaction' handled by t_relay()? The next transaction is:
ACK <-
Finally, the last transaction would be (as an example):
BYE <- 200 OK ->
Yes.
So the ser route{} block would need to recognize and handle
INVITE ACK BYE
in this context. Is that correct? If I was running 'statelessly' I would need to handle and send every single message listed?
The only difference in the route script will be forward() instead of t_relay().
regards, Jan.