18 Jun
2010
18 Jun
'10
6:20 p.m.
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
18 Jun
18 Jun
6:40 p.m.
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
19 Jun
19 Jun
12:48 a.m.
New subject: TM clarifications Re: CANCEL before INVITE + loose_route()
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
21 Jun
21 Jun
10:35 a.m.
New subject: TM clarifications Re: CANCEL before INVITE + loose_route()
2010/6/18 David <kamailio.org(a)spam.lublink.net>et>:
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 Baz Castillo
<ibc(a)aliax.net>
10:40 a.m.
New subject: TM clarifications Re: CANCEL before INVITE + loose_route()
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!
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
10:53 a.m.
New subject: TM clarifications Re: CANCEL before INVITE + loose_route()
2010/6/21 Alex Balashov <abalashov(a)evaristesys.com>om>:
Iñaki,
On 06/21/2010 03:35 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.
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.
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.
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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
10:56 a.m.
New subject: TM clarifications Re: CANCEL before INVITE + loose_route()
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.
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
11:07 a.m.
New subject: TM clarifications Re: CANCEL before INVITE + loose_route()
2010/6/21 Alex Balashov <abalashov(a)evaristesys.com>om>:
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).
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
11:10 a.m.
New subject: TM clarifications Re: CANCEL before INVITE + loose_route()
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.
--
Alex Balashov - Principal
Evariste Systems LLC
1170 Peachtree Street
12th Floor, Suite 1200
Atlanta, GA 30309
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/
11:15 a.m.
New subject: TM clarifications Re: CANCEL before INVITE + loose_route()
2010/6/21 Alex Balashov <abalashov(a)evaristesys.com>om>:
On 06/21/2010 04:07 AM, Iñaki Baz Castillo wrote:
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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
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.
10:22 a.m.
2010/6/18 Henning Westerholt <henning.westerholt(a)1und1.de>de>:
This is true because t_relay() creates a server transaction in case it
doesn't exist yet.
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_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. 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.) > 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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
12:50 p.m.
On Monday 21 June 2010, Iñaki Baz Castillo wrote:
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
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.
12:58 p.m.
2010/6/21 Henning Westerholt <henning.westerholt(a)1und1.de>de>:
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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
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. 
1:19 p.m.
On Jun 21, 2010 at 11:58, Iñaki Baz Castillo <ibc(a)aliax.net> wrote:
2010/6/21 Henning Westerholt
<henning.westerholt(a)1und1.de>de>:
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
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.
2:05 p.m.
2010/6/21 Andrei Pelinescu-Onciul <andrei(a)iptel.org>rg>:
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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>
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.
2:24 p.m.
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
5275
days inactive
5278
days old
15 comments
5 participants
participants (5)
-
Alex Balashov -
Andrei Pelinescu-Onciul -
David -
Henning Westerholt -
Iñaki Baz Castillo