16 May
2010
16 May
'10
4:27 p.m.
if t_relay() fails in route block so that failure route is not executed,
is request uri "consumed" so that if a new branch is added by in the
route block, that branch will be the only remaining one?
in the test that i made, two lcr gws match the request uri. in route
block i have:
load_gws();
next_gw(); /* sets request-uri to uri of first gw */
while ($true) {
t_on_branch("BRANCHES");
if (t_relay()) {
xlog("Relaying succeeded with result $rc\n");
exit;
} else {
xlog("Relaying failed with result $rc\n");
};
if (!next_gw()) { /* tries to append the next gw as a new branch */
xlog("L_WARN", "No more gws\n");
send_reply("503", "Service not available");
exit;
};
xlog("found next gw <$ds>\n")
};
and in branch route block BRANCHES i have
branch_route [BRANCHES] {
xlog("L_INFO", "Relaying $rm <$ru>\n");
return;
};
when proxy receives a request, i get to syslog (some lcr DBGs are
changed to INFOs):
May 16 15:58:49 localhost /usr/sbin/sip-proxy[11412]: INFO: lcr [lcr_mod.c:1532]: added
gw_uri_avp <1|1|00||lohi.tutpro.com|5060||1|4096> with weight <8192865>
May 16 15:58:49 localhost /usr/sbin/sip-proxy[11412]: INFO: lcr [lcr_mod.c:1532]: added
gw_uri_avp <1|1|00||sars.tutpro.com|||2|64> with weight <3725453>
May 16 15:58:49 localhost /usr/sbin/sip-proxy[11412]: INFO: Relaying INVITE
<sip:00358407058055@sars.tutpro.com;transport=tcp>
May 16 15:58:49 localhost /usr/sbin/sip-proxy[11412]: ERROR: tm [ut.h:295]: ERROR:
uri2dst: failed to resolve "sars.tutpro.com" :unresolvable A or AAAA request
(-7)
May 16 15:58:49 localhost /usr/sbin/sip-proxy[11412]: ERROR: tm [t_fwd.c:1391]: ERROR:
t_forward_nonack: failure to add branches
May 16 15:58:49 localhost /usr/sbin/sip-proxy[11412]: ERROR: Relaying failed with result
-478
May 16 15:58:49 localhost /usr/sbin/sip-proxy[11412]: INFO: lcr [lcr_mod.c:1949]:
appending branch <sip:00358407058055@lohi.tutpro.com:5060>
May 16 15:58:49 localhost /usr/sbin/sip-proxy[11412]: ERROR: found next gw <Contact:
sip:00358407058055@sars.tutpro.com;transport=tcp,
sip:00358407058055@lohi.tutpro.com:5060>
May 16 15:58:49 localhost /usr/sbin/sip-proxy[11412]: ERROR: tm [ut.h:295]: ERROR:
uri2dst: failed to resolve "sars.tutpro.com" :unresolvable A or AAAA request
(-7)
May 16 15:58:49 localhost /usr/sbin/sip-proxy[11412]: ERROR: Relaying succeeded with
result 1
May 16 15:58:54 localhost /usr/sbin/sip-proxy[11459]: WARNING: No more gws
the first gw domain name sars.tutpro.com does not exist and the tm
errors are as they should. then next_gw() appends a new branch, but
based on the "found next gw" log message it looks like sars.tutpro.com
is still in the destination set.
is this how it is supposed to be? if so, looks like i there is a bug in
next_gw() in that it should clear the previous branch before adding a
new one in case the previous branch was not consumed by t_relay?
another strange thing is, why the branch route is executed only once
(for the first t_relay) although the script is calling t_relay() two
times and t_on_branch() is called before each call?
-- juha
16 May
16 May
4:47 p.m.
Juha Heinanen writes:
is this how it is supposed to be? if so, looks like i
there is a bug in
next_gw() in that it should clear the previous branch before adding a
new one in case the previous branch was not consumed by t_relay?
i tried that by adding clear_branches() call before append_branch():
static int next_gw(...
...
/* Subsequent invocation in route block or any invocation in
* failure route block => clear possible unconsumed branches and
* append a new one. */
clear_branches();
uri_str.s = r_uri;
uri_str.len = r_uri_len;
LM_INFO("appending branch <%.*s>\n", uri_str.len, uri_str.s);
if (append_branch(_m, &uri_str, 0, 0, Q_UNSPECIFIED, 0, 0) == -1) {
LM_ERR("when appending branch <%.*s>\n", uri_str.len, uri_str.s);
return -1;
}
but still, syslog shows that the first branch is still in the
destination set:
if (!next_gw()) { /* tries to append the next gw as a new branch */
xlog("L_WARN", "No more gws\n");
send_reply("503", "Service not available");
exit;
};
xlog("found next gw <$ds>\n")
May 16 16:40:24 localhost /usr/sbin/sip-proxy[12343]: INFO: lcr [lcr_mod.c:1951]:
appending branch <sip:00358407058055@lohi.tutpro.com:5060>
May 16 16:40:24 localhost /usr/sbin/sip-proxy[12343]: ERROR: found next gw <Contact:
sip:00358407058055@sars.tutpro.com;transport=tcp,sip:00358407058055@lohi.tutpro.com:5060>
what it is that i'm missing here?
-- juha
17 May
17 May
8:49 a.m.
Juha Heinanen writes:
another strange thing is, why the branch route is
executed only once
(for the first t_relay) although the script is calling t_relay() two
times and t_on_branch() is called before each call?
this was my mistake in the script (there was condition that prevented
the log message to be printed). branch route is correctly called both
times.
still the main issue persists, i.e., how to get rid of the first branch
to which relaying had failed. even if i add clear_branches() call to
next_gw() call, the first branch is still there. as result the first gw
to which relaying fails tried twice (first time when it is alone in the
destination set and second time when it in the destination set together
with the second gw).
below is new syslog output, where log in branch route is now always
active.
-- juha
May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: INFO: lcr [lcr_mod.c:1532]: added
gw_uri_avp <1|1|00||lohi.tutpro.com|5060||1|320> with weight <3765048>
May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: INFO: lcr [lcr_mod.c:1532]: added
gw_uri_avp <1|1|00||sars.tutpro.com|||2|64> with weight <2645835>
May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: INFO: Relaying INVITE
<sip:00358407058055@sars.tutpro.com;transport=tcp> to gw
May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: ERROR: tm [ut.h:295]: ERROR:
uri2dst: failed to resolve "sars.tutpro.com" :unresolvable A or AAAA request
(-7)
May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: ERROR: tm [t_fwd.c:1391]: ERROR:
t_forward_nonack: failure to add branches
May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: ERROR: Relaying failed with result
-478
May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: INFO: lcr [lcr_mod.c:1951]:
appending branch <sip:00358407058055@lohi.tutpro.com:5060>
May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: ERROR: found next gw <Contact:
sip:00358407058055@sars.tutpro.com;transport=tcp,
sip:00358407058055@lohi.tutpro.com:5060>
May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: INFO: Relaying INVITE
<sip:00358407058055@sars.tutpro.com;transport=tcp> to gw
May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: ERROR: tm [ut.h:295]: ERROR:
uri2dst: failed to resolve "sars.tutpro.com" :unresolvable A or AAAA request
(-7)
May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: INFO: Relaying INVITE
<sip:00358407058055@lohi.tutpro.com:5060> to gw
May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: ERROR: Relaying succeeded with
result 1
May 17 08:37:32 localhost /usr/sbin/sip-proxy[14394]: WARNING: No more gws for INVITE
<sip:00358407058055@sars.tutpro.com;transport=tcp> from <sip:test@test.fi>
12:45 p.m.
Hello,
On 5/17/10 7:49 AM, Juha Heinanen wrote:
Juha Heinanen writes:
is a second call of next_gw() in route block always appending a branch?
or is updating the r-uri/dst-uri?
In this case when t_relay failed, transaction is created, probably the
first branch is set in transaction structure, but to see what is its
states, need to get into sources...
Cheers,
Daniel
another strange thing is, why the branch route is
executed only once
(for the first t_relay) although the script is calling t_relay() two
times and t_on_branch() is called before each call?
this was my mistake in the script (there was condition that prevented
the log message to be printed). branch route is correctly called both
times.
still the main issue persists, i.e., how to get rid of the first branch
to which relaying had failed. even if i add clear_branches() call to
next_gw() call, the first branch is still there. as result the first gw
to which relaying fails tried twice (first time when it is alone in the
destination set and second time when it in the destination set together
with the second gw).
below is new syslog output, where log in branch route
is now always
active.
-- juha
May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: INFO: lcr [lcr_mod.c:1532]: added
gw_uri_avp<1|1|00||lohi.tutpro.com|5060||1|320> with weight<3765048>
May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: INFO: lcr [lcr_mod.c:1532]: added
gw_uri_avp<1|1|00||sars.tutpro.com|||2|64> with weight<2645835>
May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: INFO: Relaying
INVITE<sip:00358407058055@sars.tutpro.com;transport=tcp> to gw
May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: ERROR: tm [ut.h:295]: ERROR:
uri2dst: failed to resolve "sars.tutpro.com" :unresolvable A or AAAA request
(-7)
May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: ERROR: tm [t_fwd.c:1391]: ERROR:
t_forward_nonack: failure to add branches
May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: ERROR: Relaying failed with result
-478
May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: INFO: lcr [lcr_mod.c:1951]:
appending branch<sip:00358407058055@lohi.tutpro.com:5060>
May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: ERROR: found next gw<Contact:
sip:00358407058055@sars.tutpro.com;transport=tcp,
sip:00358407058055@lohi.tutpro.com:5060>
May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: INFO: Relaying
INVITE<sip:00358407058055@sars.tutpro.com;transport=tcp> to gw
May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: ERROR: tm [ut.h:295]: ERROR:
uri2dst: failed to resolve "sars.tutpro.com" :unresolvable A or AAAA request
(-7)
May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: INFO: Relaying
INVITE<sip:00358407058055@lohi.tutpro.com:5060> to gw
May 17 08:37:27 localhost /usr/sbin/sip-proxy[14350]: ERROR: Relaying succeeded with
result 1
May 17 08:37:32 localhost /usr/sbin/sip-proxy[14394]: WARNING: No more gws for
INVITE<sip:00358407058055@sars.tutpro.com;transport=tcp>
from<sip:test@test.fi>
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
Kamailio (OpenSER) Advanced Training
Miami, Fl, USA - June 21-23, 2010
http://www.asipto.com/index.php/kamailio-advanced-training/
4:09 p.m.
Daniel-Constantin Mierla writes:
is a second call of next_gw() in route block always
appending a branch?
or is updating the r-uri/dst-uri?
daniel,
second and later invocations of next_gw() always append a branch, which
now has turned out to be wrong.
In this case when t_relay failed, transaction is
created, probably the
first branch is set in transaction structure, but to see what is its
states, need to get into sources...
next_gw() is not checking is transaction exists. it knows based on an
avp value if next_gw() call is first or not. it is not first, it always
appends a branch.
i try to figure out an algorithm that works no matter if t_relay()
creates a transaction or not.
this mess could be avoided by implementing the same behavior as
opensips:
2.2 Append_branch() usage
There is no need to call "append_branch()" function in failure_route in
order to use the RURI - you still need to use it only if you want to do
parallel forking.
Ex:
# in 1.4.x
failure_route[2]
if (t_check_status("408")) {
# set new RURI
rewritehostport("my_voicemail.com:5060");
append_branch();
t_relay();
}
}
->
# in 1.5.x
failure_route[2]
if (t_check_status("408")) {
# set new RURI
rewritehostport("my_voicemail.com:5060");
t_relay();
}
}
after that, life would be much simpler.
-- juha
5:12 p.m.
daniel,
when i implemented serial forking next_contacts() function as part of tm
module, i was able to simply do
struct cell *t;
t = get_t();
and then find out with test
if (!t || (t == T_UNDEFINED)) {
if transaction exists.
any pointer on how to do the same from lcr module? i guess i need to
load tm api and call some tm function?
-- juha
6:47 p.m.
Juha Heinanen writes:
any pointer on how to do the same from lcr module? i
guess i need to
load tm api and call some tm function?
i think i was able to figure this out. the corresponding tm api
function is t_gett().
so i went and changed next_gw() implementation so that if no transaction
exists, it rewrites request uri and if it exists, it clears possible old
branches and appends a new one.
still next_gw() does not work as it should, i.e., second next_gw() call
after failing t_relay() results in destination set with two sip uris
(the first one and the second one).
then i went and added some more debug to script:
# relay the request
if (t_relay()) {
xlog("Relaying succeeded with result $rc\n");
exit;
} else {
xlog("Relaying failed with result $rc\n");
if (t_check_trans()) {
xlog("Transaction exists\n");
} else {
xlog("Transaction does not exist\n");
};
};
what happens now is that execution of the script stops at
t_check_trans() test, i.e., nothing gets printed to syslog after this:
May 17 18:26:09 localhost /usr/sbin/sip-proxy[30400]: ERROR: Relaying failed with result
-478
even if t_check_trans() would not be a proper function to call at this
point, i don't understand why it does not return.
anyway, then i then went and changed in above t_check_trans() to
t_lookup_request() and execution of the script went on and printed this:
May 17 18:36:35 localhost /usr/sbin/sip-proxy[30693]: INFO: Relaying
INVITE <sip:00358407058055@sars.tutpro.com;transport=tcp> to gw
May 17 18:36:35 localhost /usr/sbin/sip-proxy[30693]: ERROR: tm [ut.h:295]: ERROR:
uri2dst: failed to resolve "sars.tutpro.com" :unresolvable A or AAAA request
(-7)
May 17 18:36:35 localhost /usr/sbin/sip-proxy[30693]: ERROR: tm [t_fwd.c:1391]: ERROR:
t_forward_nonack: failure to add branches
May 17 18:36:35 localhost /usr/sbin/sip-proxy[30693]: ERROR: Relaying failed with result
-478
May 17 18:36:35 localhost /usr/sbin/sip-proxy[30693]: ERROR: Transaction exists
May 17 18:36:36 localhost /usr/sbin/sip-proxy[30693]: ERROR: Calling next_gw()
May 17 18:36:36 localhost /usr/sbin/sip-proxy[30693]: ERROR: found next
gw <Contact: sip:00358407058055@sars.tutpro.com;transport=tcp,
sip:00358407058055@lohi.tutpro.com:5060>
May 17 18:36:36 localhost /usr/sbin/sip-proxy[30693]: INFO: Relaying
INVITE <sip:00358407058055@sars.tutpro.com;transport=tcp> to gw
...
so even if t_relay() failed with result -478, transaction was created.
as result, next_gw() thought that it must now append a new branch
instead of rewriting request uri, which resulted in trying the first gw
the second time.
i don't understand, how it is possible that transaction was created, but
request uri was not marked as used. also, i don't understand how i can
ever get this to work, because i don't have no way to know if i should
rewrite request uri or append a branch.
andrei, are you around? perhaps you can shed some light on this or
better yet implement opensips behavior about which i posted a request
to the tracker, which would allow me always just to rewrite request uri
and be done with it.
-- juha
18 May
18 May
11:09 a.m.
On 5/17/10 5:47 PM, Juha Heinanen wrote:
Juha Heinanen writes:
yes, t_gett() is the way. For the reference, if someone needs to play
with tm api, looking at tmx module is a good example, since it uses
couple of them. also k sl module uses transaction detection for
send_reply().
any pointer on how to do the same from lcr
module? i guess i need to
load tm api and call some tm function?
i think i was able to figure this out. the corresponding tm api
function is t_gett().
so i went and changed next_gw() implementation so that
if no transaction
exists, it rewrites request uri and if it exists, it clears possible old
branches and appends a new one.
still next_gw() does not work as it should, i.e., second next_gw() call
after failing t_relay() results in destination set with two sip uris
(the first one and the second one).
then i went and added some more debug to script:
# relay the request
if (t_relay()) {
xlog("Relaying succeeded with result $rc\n");
exit;
} else {
xlog("Relaying failed with result $rc\n");
if (t_check_trans()) {
xlog("Transaction exists\n");
} else {
xlog("Transaction does not exist\n");
};
};
what happens now is that execution of the script stops at
t_check_trans() test, i.e., nothing gets printed to syslog after this:
May 17 18:26:09 localhost /usr/sbin/sip-proxy[30400]: ERROR: Relaying failed with result
-478
even if t_check_trans() would not be a proper function to call at this
point, i don't understand why it does not return.
t_check_trans() returns 0 if transaction exists, iirc, to absorb
retransmission.
anyway, then i then went and changed in above
t_check_trans() to
t_lookup_request() and execution of the script went on and printed this:
May 17 18:36:35 localhost /usr/sbin/sip-proxy[30693]: INFO: Relaying
INVITE<sip:00358407058055@sars.tutpro.com;transport=tcp> to gw
May 17 18:36:35 localhost /usr/sbin/sip-proxy[30693]: ERROR: tm [ut.h:295]: ERROR:
uri2dst: failed to resolve "sars.tutpro.com" :unresolvable A or AAAA request
(-7)
May 17 18:36:35 localhost /usr/sbin/sip-proxy[30693]: ERROR: tm [t_fwd.c:1391]: ERROR:
t_forward_nonack: failure to add branches
May 17 18:36:35 localhost /usr/sbin/sip-proxy[30693]: ERROR: Relaying failed with result
-478
May 17 18:36:35 localhost /usr/sbin/sip-proxy[30693]: ERROR: Transaction exists
May 17 18:36:36 localhost /usr/sbin/sip-proxy[30693]: ERROR: Calling next_gw()
May 17 18:36:36 localhost /usr/sbin/sip-proxy[30693]: ERROR: found next
gw<Contact: sip:00358407058055@sars.tutpro.com;transport=tcp,
sip:00358407058055@lohi.tutpro.com:5060>
May 17 18:36:36 localhost /usr/sbin/sip-proxy[30693]: INFO: Relaying
INVITE<sip:00358407058055@sars.tutpro.com;transport=tcp> to gw
...
so even if t_relay() failed with result -478, transaction was created.
as result, next_gw() thought that it must now append a new branch
instead of rewriting request uri, which resulted in trying the first gw
the second time.
i don't understand, how it is possible that transaction was created, but
request uri was not marked as used. also, i don't understand how i can
ever get this to work, because i don't have no way to know if i should
rewrite request uri or append a branch.
I haven't got into this config situation yet. I will try to look into
sources, but might take a bit since I travel. I will ping Andrei, maybe
he can give a hint faster.
Cheers,
Daniel
andrei, are you around? perhaps you can shed some
light on this or
better yet implement opensips behavior about which i posted a request
to the tracker, which would allow me always just to rewrite request uri
and be done with it.
-- juha
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
Kamailio (OpenSER) Advanced Training
Miami, Fl, USA - June 21-23, 2010
http://www.asipto.com/index.php/kamailio-advanced-training/
21 May
21 May
2:35 p.m.
On May 17, 2010 at 18:47, Juha Heinanen <jh(a)tutpro.com> wrote:
Juha Heinanen writes:
Note that if you call next_gw() after t_relay() and no transaction
exists, it means that no transaction could be created (out of mem, parse
error, bad via) and it makes no sense to re-try with a different uri or
branch.
The easiest way to check for this is to look at T (t_gett() ) after
t_relay(). If is T_UNDEFINED or 0 => no transaction could be created.
any pointer on how to do the same from lcr
module? i guess i need to
load tm api and call some tm function?
i think i was able to figure this out. the corresponding tm api
function is t_gett().
so i went and changed next_gw() implementation so that if no transaction
exists, it rewrites request uri and if it exists, it clears possible old
branches and appends a new one. From the script you can use t_lookup_request()
(if (!t_lookup_request()) error; drop).
You could also look at the t_relay() return code, but there are some
codes which are used both when no transaction was created and when a
transaction was created but forwarding on some branch failed (e.g.
E_OUT_OF_MEM).
still next_gw() does not work as it should, i.e., second next_gw() call
after failing t_relay() results in destination set with two sip uris
(the first one and the second one).
[...]
so even if t_relay() failed with result -478, transaction was created.
as result, next_gw() thought that it must now append a new branch
instead of rewriting request uri, which resulted in trying the first gw
the second time.
Yes, this is a special case. If there are no parse errors or out-of-mem
the transaction will always be created.
It can still fail at 2 points: when adding a branch (e.g. unresolvable
or bad uri, to many branches, out-of-mem again) and when a message is
sent on the branch (e.g. out-of-mem, blacklisted destination,
destination denied via the on_send_route, dns failover failure,
immediate send error).
In the first case you'll get a return code of E_BAD_ADDRESS (-478),
E_TOO_MANY_BRANCHES (-12), E_NO_SOCKET (-7) or E_OUT_OF_MEM (-2).
In the second case you'll always get E_SEND (-477).
Other return codes you should watch for are E_CANCELED (-487) and E_BUG
(-5).
i don't understand, how it is possible that transaction was created, but
request uri was not marked as used. also, i don't understand how i can
ever get this to work, because i don't have no way to know if i should
rewrite request uri or append a branch.
This happens because the request uri was not really used (adding a
branch with it failed).
You could either check the return code and if
1. $? is E_BAD_ADDRESS or E_NO_SOCKET rewrite the uri
2. $? is E_SEND append a branch
3. all other cases for $? <0 exit.
or see below.
andrei, are you around? perhaps you can shed some light on this or
better yet implement opensips behavior about which i posted a request
to the tracker, which would allow me always just to rewrite request uri
and be done with it.
As far as I understood the osips behaviour was only for failure route.
Anyway there is a simple change that would allow rewriting only the
request uri and having t_relay() add new branches. However it will work
only if append_branch() is not used in the same time (if append_branch()
is used and this is not the first t_relay() call, only the branches added by
append_branch() will be used) and will hide mistakes like calling
t_relay() twice without changing anything (e.g. t_relay(); t_relay()
will result in 2 branches with the same uri and destination, instead of
the current behaviour which is 1 branch and an error logged).
The change is modifying t_forward_non_ack():
t_fwd.c line 1323:
if (first_branch==0) {
changed to:
if (first_branch==0 || nr_branches==0) {
and t_fwd.c line 1326:
if ((is_route_type(REQUEST_ROUTE)) &&
save_msg_lumps(t->uas.request, p_msg)) {
changed to:
if (first_branch==0 && (is_route_type(REQUEST_ROUTE)) &&
save_msg_lumps(t->uas.request, p_msg)) {
If you make this changes then for serial forking it would be enough to
re-write the uri. If you test it and nobody has anything against it
(calling t_relay() multiple times without changing the uri or appending
branches would now result in multiple branches with the same uri & dst
instead of logged error messages) we can add it to master.
Andrei
2:23 p.m.
Andrei Pelinescu-Onciul writes:
andrei,
i want to do that inside next_gw()/next_contacts() functions, not in the
script. could it be somehow possible to check from the branch structure
(dset.h/c) if request-uri is still unused? would
get_branch_iterator(void) and next_branch() or get_branch() work
although they seem to be very heavy means.
i don't
understand, how it is possible that transaction was created, but
request uri was not marked as used. also, i don't understand how i can
ever get this to work, because i don't have no way to know if i should
rewrite request uri or append a branch.
This happens because the request uri was not really used (adding a
branch with it failed).
You could either check the return code and if
1. $? is E_BAD_ADDRESS or E_NO_SOCKET rewrite the uri
2. $? is E_SEND append a branch
3. all other cases for $? <0 exit.
or see below. As far as I understood the osips behaviour was only
for failure route.
may be, but it would be simpler still if i could set request-uri in any
block, i.e., setting of request-uri always clears possible existing
request uri and possibly existing branches. after that, more branches
can be added by append_branch() before calling t_relay(), which always
operates on request-uri and the possible branches.
Anyway there is a simple change that would allow
rewriting only the
request uri and having t_relay() add new branches. However it will work
only if append_branch() is not used in the same time (if append_branch()
is used and this is not the first t_relay() call, only the branches added by
append_branch() will be used) and will hide mistakes like calling
t_relay() twice without changing anything (e.g. t_relay(); t_relay()
will result in 2 branches with the same uri and destination, instead of
the current behaviour which is 1 branch and an error logged).
that sounds too complicated and risky. would the change that i suggest
in above be more difficult to implement?
-- juha
2:35 p.m.
i want to do that inside next_gw()/next_contacts()
functions, not in the
script. could it be somehow possible to check from the branch structure
(dset.h/c) if request-uri is still unused? would
get_branch_iterator(void) and next_branch() or get_branch() work
although they seem to be very heavy means.
looking at print_dset() implementation, it checks existence of
request-uri branch by testing
if (msg->new_uri.s) {
based on that, would this algorithm be correct:
IF transaction does not exist OR
(transaction exists AND msg->new_uri.s != null)
THEN
next_gw() sets request uri
ELSE
next_gw() appends branch
FI
-- juha
4:23 p.m.
On May 21, 2010 at 14:23, Juha Heinanen <jh(a)tutpro.com> wrote:
It would be slightly more difficult (definitely not only 1 changed
line). Basically we would need to remember if ruri is can be used for
branches or not. On new message set ruri_is_new=1 (ruri_is_new being a
new static var inside dset.c) and on clear_branches() set it to 0. Then
change t_forward_non_ack() and use ruri_is_new instead of
first_branch==0 for the first add_uac().
For failure route ruri_is_new should be set to 0.
Each time a new uri is set, ruri_is_new should also be set to 1.
Probably the same should be done if dst_uri is changed.
Andrei
Andrei Pelinescu-Onciul writes:
andrei,
i want to do that inside next_gw()/next_contacts() functions, not in the
script. could it be somehow possible to check from the branch structure
(dset.h/c) if request-uri is still unused? would
get_branch_iterator(void) and next_branch() or get_branch() work
although they seem to be very heavy means.
No, they won't work. t_relay() will clear all the branches if it
creates a transaction (even if it fails). Even if this wouldn't be the
case it would still not possible to do the ruri check with the current
code.
The only way would be either to get the transaction number of branches
(t->nr_of_outgoings) previous to calling t_relay() and compare with the
same number after that (if different you need to use append_branch(),
else set new uri), or relay on checking ser_error (this is $rc or $? in
the code).
i
don't understand, how it is possible that transaction was created, but
request uri was not marked as used. also, i don't understand how i can
ever get this to work, because i don't have no way to know if i should
rewrite request uri or append a branch.
This happens because the request uri was not really used (adding a
branch with it failed).
You could either check the return code and if
1. $? is E_BAD_ADDRESS or E_NO_SOCKET rewrite the uri
2. $? is E_SEND append a branch
3. all other cases for $? <0 exit.
or see below. As far as I understood the osips behaviour was
only for failure route.
may be, but it would be simpler still if i could set request-uri in any
block, i.e., setting of request-uri always clears possible existing
request uri and possibly existing branches. after that, more branches
can be added by append_branch() before calling t_relay(), which always
operates on request-uri and the possible branches.
Anyway there is a simple change that would allow
rewriting only the
request uri and having t_relay() add new branches. However it will work
only if append_branch() is not used in the same time (if append_branch()
is used and this is not the first t_relay() call, only the branches added by
append_branch() will be used) and will hide mistakes like calling
t_relay() twice without changing anything (e.g. t_relay(); t_relay()
will result in 2 branches with the same uri and destination, instead of
the current behaviour which is 1 branch and an error logged).
that sounds too complicated and risky. would the change that i suggest
in above be more difficult to implement?
4:39 p.m.
Andrei Pelinescu-Onciul writes:
sounds ok except the last point. i would think that every time
ruri_is_new is set to 1, dst_uri should be cleared. once new
request-uri is set, dst uri must be set too if it is going to be
needed.
some solution to this problem is needed since it is currently impossible
to make next_gw() and next_branches() work correctly and if the above is
the simplest one, then it would make sense to implement it.
-- juha
that sounds
too complicated and risky. would the change that i suggest
in above be more difficult to implement?
It would be slightly more difficult (definitely not only 1 changed
line). Basically we would need to remember if ruri is can be used for
branches or not. On new message set ruri_is_new=1 (ruri_is_new being a
new static var inside dset.c) and on clear_branches() set it to 0. Then
change t_forward_non_ack() and use ruri_is_new instead of
first_branch==0 for the first add_uac().
For failure route ruri_is_new should be set to 0.
Each time a new uri is set, ruri_is_new should also be set to 1.
Probably the same should be done if dst_uri is changed.
25 May
25 May
7:05 p.m.
andrei,
t_gett() returns pointer to the transaction (struct cell). would it be
somehow possible to dig from that structure if the transaction still
has some contacts in the destination set left unconsumed and if so, if
there is the request uri branch still left?
-- juha
26 May
26 May
7:09 p.m.
On May 25, 2010 at 19:05, Juha Heinanen <jh(a)tutpro.com> wrote:
andrei,
t_gett() returns pointer to the transaction (struct cell). would it be
somehow possible to dig from that structure if the transaction still
has some contacts in the destination set left unconsumed and if so, if
there is the request uri branch still left?
If I understand correctly your use case (next_gw() called after
t_relay() error, always adding only 1 branch and called form
request_route) then yes:
if t!= T_UNDEFINED and t!=0 and t->nr_of_outgoings!=0 =>
uri "consumed", add branch,
else if t==0 or UNDEFINED =>
exit with error (something bad has happend, probably out-of-mem)
else
uri was bad => change ruri.
From failure route, always use append_branch.
Anyway I'll commit some code for the marking consumed ruris on some new
branch soon (but would require extensive testing).
Andrei
27 May
27 May
12:24 p.m.
On May 26, 2010 at 18:09, Andrei Pelinescu-Onciul <andrei(a)iptel.org> wrote:
On May 25, 2010 at 19:05, Juha Heinanen
<jh(a)tutpro.com> wrote:
The branch is tmp/ruri_branch. I did only basic testing (serial forking
from request and failure route).
I tried to update all the modules that change r-uri, dst_uri or path to
re-mark the r-uri as usable for forking (ruri_mark_new()), but it's
possible that I've missed some.
Andrei
andrei,
t_gett() returns pointer to the transaction (struct cell). would it be
somehow possible to dig from that structure if the transaction still
has some contacts in the destination set left unconsumed and if so, if
there is the request uri branch still left?
If I understand correctly your use case (next_gw() called after
t_relay() error, always adding only 1 branch and called form
request_route) then yes:
if t!= T_UNDEFINED and t!=0 and t->nr_of_outgoings!=0 =>
uri "consumed", add branch,
else if t==0 or UNDEFINED =>
exit with error (something bad has happend, probably out-of-mem)
else
uri was bad => change ruri.
From failure route, always use append_branch.
Anyway I'll commit some code for the marking consumed ruris on some new
branch soon (but would require extensive testing).
3:21 p.m.
Andrei Pelinescu-Onciul writes:
andrei,
thanks for the changes. that simplified lcr/next_gw() implementation
great deal. all i need to do now is to call rewrite_uri() without
needing to try to figure out, which route block we are and what happened
to previous t_relay(). i tested all combinations in route and failure
route blocks and all tests worked fine.
please merge ruri_branch to master and i'll commit my changes to lcr
module. i can also take a look at next_contacts() function.
-- juha
Anyway
I'll commit some code for the marking consumed ruris on some new
branch soon (but would require extensive testing).
The branch is tmp/ruri_branch. I did only basic testing (serial forking
from request and failure route).
4:15 p.m.
Juha Heinanen writes:
please merge ruri_branch to master and i'll commit
my changes to lcr
module. i can also take a look at next_contacts() function.
i tried to commit lcr changes to tmp/ruri_branch, but failed to do so.
i made a new branch called uri_branch from origin/tmp/ruri_branch and
then commit the changes there. however, when i try to push the changes,
i get errors:
jh@rautu:/usr/src/orig/sip-router/modules/lcr$ eg push
xxxx(a)git.sip-router.org's password:
error: src refspec tmp/ruri_branch does not match any.
error: failed to push some refs to 'ssh://jh@git.sip-router.org/sip-router'
would be easier for me to commit to master.
-- juha
8:03 p.m.
andrei,
i modified also t_next_contacts() to the new ruri_branch scheme, tested
it, and didn't find any problems. so i would be ready to commit both
lcr and t_serial changes, once ruri_branch has been merged to master.
-- juha
28 May
28 May
2:40 p.m.
On May 27, 2010 at 16:15, Juha Heinanen <jh(a)tutpro.com> wrote:
Juha Heinanen writes:
I don't use eg, but shouldn't you use something like
eg push --branch tmp/ruri_branch ?
With git I use git push origin HEAD:tmp/ruri_branch
Andrei
please merge ruri_branch to master and i'll
commit my changes to lcr
module. i can also take a look at next_contacts() function.
i tried to commit lcr changes to tmp/ruri_branch, but failed to do so.
i made a new branch called uri_branch from origin/tmp/ruri_branch and
then commit the changes there. however, when i try to push the changes,
i get errors:
jh@rautu:/usr/src/orig/sip-router/modules/lcr$ eg push
xxxx(a)git.sip-router.org's password:
error: src refspec tmp/ruri_branch does not match any.
error: failed to push some refs to 'ssh://jh@git.sip-router.org/sip-router'
2:32 p.m.
On May 27, 2010 at 15:21, Juha Heinanen <jh(a)tutpro.com> wrote:
Andrei Pelinescu-Onciul writes:
andrei,
thanks for the changes. that simplified lcr/next_gw() implementation
great deal. all i need to do now is to call rewrite_uri() without
needing to try to figure out, which route block we are and what happened
to previous t_relay(). i tested all combinations in route and failure
route blocks and all tests worked fine.
please merge ruri_branch to master and i'll commit my changes to lcr
module. i can also take a look at next_contacts() function.
Done.
Andrei
Anyway
I'll commit some code for the marking consumed ruris on some new
branch soon (but would require extensive testing).
The branch is tmp/ruri_branch. I did only basic testing (serial forking
from request and failure route).
5322
days inactive
5334
days old
20 comments
3 participants
participants (3)
-
Andrei Pelinescu-Onciul -
Daniel-Constantin Mierla -
Juha Heinanen