19 Jun
2010
19 Jun
'10
12:48 a.m.
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