Hello,
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 ?
Do I need to call t_release() when I call t_relay () ?
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 ). So when do I release the transaction ? In the reply route ? In the same run as I call t_newtran() ?
Does t_checktrans() absorb retransmissions that were started with t_relay and t_newtran?
If you have any material that I could read that would help me better understand the TM module, please say so.
Thanks,
David
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
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
2010/6/18 David kamailio.org@spam.lublink.net:
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?
Yes.
'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.
This text is about client side. An UAC shouldn't send a CANCEL if it has received no provisional response from the proxy/UAS. This is to avoid race conditions: In UDP the UAC could send the INVITE, followed by a CANCEL, and the CANCEL could arrive to the proxy before the INVITE (race condition), so the UAC must wait until having a provisiona response in order to send a CANCEL.
But from the server/proxy point of view it doesn't matter. This is, if the proxy has received an INVITE it doesn't matter if it has replied a provisional response or not, it already *can* handle a CANCEL from the client. The only requeriment is having a transaction created for such INVITE (which occurs when calling t_relay or t_newtran).
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?
Yes, but usually it's done after loose_route section because such section consumes very few resources (just pure routing). But in my case I check for retransmissions at the beginning of the script.
I read that loose_route() should be secured, would it be correct to request a proxy authentication before calling loose_route() ?
The dialog mechanism (call-id, from-tag and to-tag) should be secure enough. Anyhow you can ask for auth in the proxy but take into account that some UA's out there don't re-send an in-dialog request with credentials. Also, when asking for auth take into account that the From URI of the sender could be different than the username of its credentials (i.e: alice calls to 200 which is an alias to bob, bob later sends a BYE with original From: "sip:200@domain", so it wouldn't match the credentials username "bob").
Can a CANCEL request ever be routed using loose_route().
No, CANCEL is a hop-by-hop request, an UAC sends a CANCEL to the inmediate proxy, and the proxy inmediately replies 200 to the UAC. Later the proxy generates its ***own*** outgoing CANCEL's in order to terminate pending branches (if they exist). Also, CANCEL is not an in-dialog request (no To-tag, no route-set). But you would do better by reading the CANCEL section in RFC 3261 in which this subjet is very well explained.
Regards.
Iñaki,
On 06/21/2010 03:35 AM, Iñaki Baz Castillo wrote:
But from the server/proxy point of view it doesn't matter. This is, if the proxy has received an INVITE it doesn't matter if it has replied a provisional response or not, it already *can* handle a CANCEL from the client. The only requeriment is having a transaction created for such INVITE (which occurs when calling t_relay or t_newtran).
If the proxy has created a transaction for the INVITE and receives a CANCEL from initiating UAC before any provisional response has been received from UAS, will it forward the CANCEL to the UAS, or just quietly discard it while returning 200 to the UAC because it has a transaction for the INVITE that is being canceled?
I assume it will not forward CANCEL without having received a reply of some kind, but since it is not a UA and is not subject to the same rules, I wonder.
Thanks!
2010/6/21 Alex Balashov abalashov@evaristesys.com:
Iñaki,
On 06/21/2010 03:35 AM, Iñaki Baz Castillo wrote:
But from the server/proxy point of view it doesn't matter. This is, if the proxy has received an INVITE it doesn't matter if it has replied a provisional response or not, it already *can* handle a CANCEL from the client. The only requeriment is having a transaction created for such INVITE (which occurs when calling t_relay or t_newtran).
If the proxy has created a transaction for the INVITE and receives a CANCEL from initiating UAC before any provisional response has been received from UAS, will it forward the CANCEL to the UAS, or just quietly discard it while returning 200 to the UAC because it has a transaction for the INVITE that is being canceled?
It the same as when UAC to proxy, as here we are speaking about transaction clients which exist in the UAC and the proxy. This is, if the proxy receives a CANCEL for an INVITE (without having yet provisional responses from the destination UAS) then the proxy's transaction client *cannot* send a CANCEL as a race condition could occur (such CANCEL arriving to the UAS before the INVITE). The proxy must wait until a 1XX is received (or release the outgoing transaction after 64xT1 as usual by generating a local 408).
And yes, the proxy in this case must also reply 200 to the UAC. In fact, the proxy must reply 200 for the CANCEL inmediately (CANCEL is hop by hop) if such transaction exists. Later, the proxy must terminate all the possible branches it has generated by sending a CANCEL to those for which it has a 1xx response.
I assume it will not forward CANCEL without having received a reply of some kind, but since it is not a UA and is not subject to the same rules, I wonder.
The proxy is subject to the same rules as here we are speaking about transaction client, present in UAC and proxy when creating an outgoing transaction :)
Regards.
On 06/21/2010 03:53 AM, Iñaki Baz Castillo wrote:
It the same as when UAC to proxy, as here we are speaking about transaction clients which exist in the UAC and the proxy.
Thank you for the clarification.
This is what I thought, but I wondered because philosophically it seems to slightly conflict with the requirement that the proxy - even a stateful proxy - forward what it receives more or less straightforwardly, setting aside the question of forking for the moment.
Thank you, though. Very helpful.
2010/6/21 Alex Balashov abalashov@evaristesys.com:
Thank you for the clarification.
This is what I thought, but I wondered because philosophically it seems to slightly conflict with the requirement that the proxy - even a stateful proxy - forward what it receives more or less straightforwardly
Well, the proxy did already forward the INVITE request, but such action implies an outgoing transaction generated by the proxy, with same rules as any client transaction, including the CANCEL processing (no CANCEL can be sent if no 1xx has been received for the outgoing transaction).
Also note that CANCEL is hop-by-hop (in stateful mode), this is: a CANCEL is not relayed/forwarded by a proxy, but consumed/accepted by the proxy (so it immediately replies 200) and then the proxy must terminate *its* pending outgoing transactions (which would involve *generating* CANCEL requests for those transactions which already replied a 1xx).
On 06/21/2010 04:07 AM, Iñaki Baz Castillo wrote:
Also note that CANCEL is hop-by-hop (in stateful mode), this is: a CANCEL is not relayed/forwarded by a proxy, but consumed/accepted by the proxy (so it immediately replies 200) and then the proxy must terminate *its* pending outgoing transactions (which would involve *generating* CANCEL requests for those transactions which already replied a 1xx).
Sure, but from a conceptual point of view this sounds like more like a UAS and less like a proxy, because the proxy is in this case is (a) the logical target of the CANCEL request from the UAC and (b) provides an encapsulating layer of abstraction in which the management of one or more branches is contained.
2010/6/21 Alex Balashov abalashov@evaristesys.com:
On 06/21/2010 04:07 AM, Iñaki Baz Castillo wrote:
Also note that CANCEL is hop-by-hop (in stateful mode), this is: a CANCEL is not relayed/forwarded by a proxy, but consumed/accepted by the proxy (so it immediately replies 200) and then the proxy must terminate *its* pending outgoing transactions (which would involve *generating* CANCEL requests for those transactions which already replied a 1xx).
Sure, but from a conceptual point of view this sounds like more like a UAS and less like a proxy, because the proxy is in this case is (a) the logical target of the CANCEL request from the UAC and (b) provides an encapsulating layer of abstraction in which the management of one or more branches is contained.
Yes, I agree, but it is normal IMHO as:
- From a dialog's point of view there are just UA's (UAC+UAS).
- From a transaction's point of view there are UAC's, UAS's and stateful proxies.
2010/6/18 Henning Westerholt henning.westerholt@1und1.de:
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 ?
this is my understanding of the function.
This is true because t_relay() creates a server transaction in case it doesn't exist yet.
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.)
But take into account that after calling t_newtran() new data being created in the script is not stored within the transaction information (flags, AVP's...). It produces really unexpected behavior if you don't take it into account.
Does t_checktrans() absorb retransmissions that were started with t_relay and t_newtran?
Read carefully the documentation for t_checktrans() function as it behaves different depending on the message type (CANCEL, ACK, other request, response...).
Best regards.
On Monday 21 June 2010, Iñaki Baz Castillo wrote:
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.)
But take into account that after calling t_newtran() new data being created in the script is not stored within the transaction information (flags, AVP's...). It produces really unexpected behavior if you don't take it into account.
Hi Iñaki,
yes, this is one of the reasons that it IMHO not that useful in proxy configurations, where one need to rewrite a lot.
Cheers,
Henning
2010/6/21 Henning Westerholt henning.westerholt@1und1.de:
But take into account that after calling t_newtran() new data being created in the script is not stored within the transaction information (flags, AVP's...). It produces really unexpected behavior if you don't take it into account.
Hi Iñaki,
yes, this is one of the reasons that it IMHO not that useful in proxy configurations, where one need to rewrite a lot.
I've tryed to use it in some scenarios and finally left it as it's unfeasible. IMHO new transaction data created after t_newtran() should be appended to the transaction memory when t_relay is invoked.
On Jun 21, 2010 at 11:58, Iñaki Baz Castillo ibc@aliax.net wrote:
2010/6/21 Henning Westerholt henning.westerholt@1und1.de:
But take into account that after calling t_newtran() new data being created in the script is not stored within the transaction information (flags, AVP's...). It produces really unexpected behavior if you don't take it into account.
Hi Iñaki,
yes, this is one of the reasons that it IMHO not that useful in proxy configurations, where one need to rewrite a lot.
I've tryed to use it in some scenarios and finally left it as it's unfeasible. IMHO new transaction data created after t_newtran() should be appended to the transaction memory when t_relay is invoked.
flags & lumps are appended on t_relay() (ser 2.1, sr 3.*). You can do things like: t_newtran(); append_hf("FOO: bar\r\n"); t_relay(); and it will work as expected.
Andrei
2010/6/21 Andrei Pelinescu-Onciul andrei@iptel.org:
I've tryed to use it in some scenarios and finally left it as it's unfeasible. IMHO new transaction data created after t_newtran() should be appended to the transaction memory when t_relay is invoked.
flags & lumps are appended on t_relay() (ser 2.1, sr 3.*). You can do things like: t_newtran(); append_hf("FOO: bar\r\n"); t_relay(); and it will work as expected.
In K <= 1.5 the above code would append such new header in the first branch, but not in a new branch (serial forking). I understand that this is solved in SR 3.* as you have explained. However, what about AVP's?
Thanks.
On Monday 21 June 2010, Andrei Pelinescu-Onciul wrote:
flags & lumps are appended on t_relay() (ser 2.1, sr 3.*). You can do things like: t_newtran(); append_hf("FOO: bar\r\n"); t_relay(); and it will work as expected.
Hi Andrei,
ah! This is good to know, thanks for the information.
Cheers,
Henning
-
Alex Balashov -
Andrei Pelinescu-Onciul -
David -
Henning Westerholt -
Iñaki Baz Castillo