On Friday 18 June 2010, David wrote:
I am using Kamailio 1.5.4.
I read RFC3261 section 17 and the TM doc, I had a few questions :
Does t_relay() manage both the client and server transactions for the
packet being forwarded ? Meaning it would absorb retransmissions it
receives and would retransmit the relayed message when needed ?
Hi,
this is my understanding of the function.
Do I need to call t_release() when I call t_relay () ?
When the transaction will be ended by means of the message transmission, e.g.
for a normal INVITE transactions, i think its not necessary.
Where would I use t_checktrans(), t_release() and
t_newtran() ? My
understanding is that if I want to receive a packet and process it
locally without forwarding it, I should use t_newtran(). This would be
good for things such as PUBLISH, PRESENCE and REGISTER ( even though
it's not a good idea ).
The t_newtran() just creates a new transaction. If you then process the msg
locally without forwarding you should release it. I think one reason for
providing this as dedicated function (after all t_relay does it as well) is
that you could use it before some time consuming operations, in order to be
able to absorb retransmissions. Another reason is that you can then take care
of the error condition that the server can't create new transactions any more,
and send a stateless error reply. (Even this probably happens today rarely,
with the increases in available memory.)
So when do I release the transaction ? In the
reply route ? In the same run as I call t_newtran() ?
For the msg that needs it you just do it after processing it. This function is
only available in REQUEST_ROUTE according the docs.
Does t_checktrans() absorb retransmissions that were
started with
t_relay and t_newtran?
The t_checktrans absorb retransmissions for transactions that were created by
t_relay or t_newtran.
If you have any material that I could read that would
help me better
understand the TM module, please say so.
You already mentioned it, the RFC 3261 should be helpful to understand special
functionality bits about tm, like reply code aggregation, branching and so on.
Regards,
Henning