[SR-Users] TM clarifications Re: CANCEL before INVITE + loose_route()

[David]

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
>    

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20100618/3cf23ca5/attachment.htm>