Hello,

Thanks for the answer. This answers some of my questions, but I still have a few more.

With regards to the thread "Re: [SR-Users] CANCEL before INVITE". I added a t_newtran(); call after t_checktrans() and before t_relay(), this prevented t_relay() from sending a 100 Trying to the calling user. Why would the functionality of t_relay() change like this ? Is t_relay() assuming that I have already send the 100 Trying if the transaction exists?

'Once the CANCEL is constructed, the client SHOULD check whether it has received any response (provisional or final) for the request being cancelled (herein referred to as the "original request"). ' - RFC3261 Section 9.

So is this the check that tm 1.4.11 t_checktrans() is doing ? If not, how should I be doing this check.

It looks like I should be be absorbing transactions pretty much at the beginning of my routing script after the sanity checks, is that right? Should the transactions be checked before I call the loose_route() method?

I read that loose_route() should be secured, would it be correct to request a proxy authentication before calling loose_route() ?

Can a CANCEL request ever be routed using loose_route().

Thanks,

David






On 10-06-18 11:40 AM, Henning Westerholt wrote: 
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