[Serusers] what makes a transaction?

Jiri Kuthan jiri at iptel.org
Thu Feb 27 19:47:05 CET 2003


At 05:20 PM 2/27/2003, 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

>However, a stateful transaction I'm having a little problem grasping.

it holds the original requests and for a while the received replies
too. That's good when you wish to correlate these, for example for
purpose of accounting, serial forking to somewhere else or parallel
forking. none of these things works with "forward", you need
"t_relay". Stateful proxy also carries out the retransmission job on 
behalf of the sender. See also
http://www.iptel.org/ser/doc/seruser-html/x740.html#AEN839

>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:

Roughly like that. t_relay establishes a transaction, but it does not
block. Replies are keyed through via/branch parameter.

>INVITE <-
>401 Unauthorized ->
>
>Is this entire sequence a transaction?  Right after this the UA sends
>an ACK, this is a transaction unto itself?
>ACK <-

If ser challenges, it does so statelessly to scale better.  It would
have to remember all unathenticated requests for some time (not good
for your memory). When the 401 reply is lost and INVITE is retransmitted, 
ser challenges  newly from scratch -- that costs more effort but less
memory. If it was stateful, it would just resend the cached reply.

 INV-->
        compute and forget
 407<--
 ACK-->

The stateful case occurs when ser acts as proxy server and relays
the replies coming from downstream for requests previously processed
using the t_relay family. ACK for negative replies is part of 
transaction (unlike ACK for 200). Its purpose is tranport confirmation 
of negative replies, which are retranmitted until ACK is received. 
They are local -- proxy confirms on behalf of client. 

  UAC     SER/proxy    UAS
  INV-->   t_relay -->
                  <--407
                  ACK--> (generated by ser to stop 407 retransmissions from downstream)
  <--407
  ACK--> (generated by UAC to stop 407 retranmissions from ser in the middle)
  

>The UA then sends :
>
>INVITE <-
>100 Trying ->
>180 Ringing ->
>200 OK ->
>
>All of these messages are a 'transaction' handled by t_relay()?  

yes

>The next
>transaction is:
>
>ACK <-

Yes. ACK for 200 is an interesting thing -- it does not belong to a transaction
per specification. It is a request which is always processed statelessly.

>Finally, the last transaction would be (as an example):
>
>BYE <-
>200 OK ->
>
>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?

You need to handle all of these messages if you plan to deploy
VoIP services, and you should not forget CANCEL either. It does
not matter whether statelessly, or statefuly unless you need 
some of the things above (accounting, forking, ...) 

-Jiri 




More information about the sr-users mailing list