<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<font size="-1"><font face="Courier New, Courier, monospace">Hi
Bogdan, and thanks again for the quick replies!<br>
<br>
I'll try the suggestion below. The downside of that solution(i
think?)<br>
is that cant know if there was a real failure of the
serialize&&next()-<br>
functions, and return an "serialforking-specific" error response
if <br>
it was. <br>
If something causes the serialize&&next_branches() to
fail, that fault <br>
will be caught during t_relay later, which generates a
(general?) failure<br>
response by TM...but no matter. this is a sip-course setup, so
it will do.<br>
<br>
Concerning the timer issue, I know about the avp-concept, and
with your <br>
solution below, I can figure out how to change the timer when
serial <br>
forking starts. <br>
But what I also wanted, was to make sure that the last branch in
the <br>
fork was given a normal timer C.<br>
In other words, as long as there are available branches, I will
<br>
"rollOver" to the next branch fairly quickly, but once i start
the <br>
last branch, normal timer C would apply.<br>
(in other words, what the "fr_inv_timer_next" did in lcr)<br>
So I would need, I think, to figure out in a failure_route(),
that <br>
the branches I am starting with next_branches() are the last
ones.<br>
But how can I know that? I cant find a way to count remaining
branches?<br>
<br>
Btw, my "hack" was never intended as a real fix. I was just
grasping<br>
at straws during troubleshooting. Also, it didnt solve the
scenario<br>
of when there is only ONE contact in the target set. <br>
Then it fails again since there are no branches, just a req-uri.<br>
<br>
Thanks again, <br>
Taisto Qvist<br>
</font></font><br>
Bogdan-Andrei Iancu skrev 2010-09-29 09:45:
<blockquote cite="mid:4CA2EE8D.1020901@voice-system.ro" type="cite">
<pre wrap="">Hi Taisto,
These new functions do replicate the behaviour of the old lcr
functions..the idea was to make this serialize mechanism globally
available for all modules.
Now, if all contacts have the same Q, there is nothing to
serialize.....Probably it will be more logical to return "false" to
script in such a case (if no serialization was done)....But you can do
something like:
--------------------------
lookup("location", "m");
switch ($retcode)
{
case 1:
log(2, "(lab2) - Contact found in location server, rerouting.\n");
if ( serialize_branches(0) && next_branches())
{
log(1, "(lab2) - serial forking in progress\n");
setflag(NN); # remember to resume serial forking in failure route
}
xlog("sending to RURI=$ru ; branches=$(branch(uri)[*])\n");
return(1);
---------------------------
Regarding the timer stuff, see my prev email.
Regards,
Bogdan
Taisto Qvist wrote:
</pre>
<blockquote type="cite">
<pre wrap="">It seems like I cried "yay" to soon.
Serialforking does work even though I cant figure out(trying the
rtfm-concept)
how I can reduce the "timer C" for only the serial-forking scenario, which
I was capable of doing with the lcr module....but now Parallell
forking doesnt
work anymore :-(
I changed my script to:
--------------------------
lookup("location", "m");
switch ($retcode)
{
case 1:
log(2, "(lab2) - Contact found in location server, rerouting.\n");
if (!serialize_branches(0))
{
log(1, "(lab2) - Unable to load contacts for serial forking\n");
t_reply("500", "Server Internal Error (Serial fork)");
exit;
}
if ( !next_branches() )
{
t_reply("509", "Serial fork error");
exit;
}
return(1);
---------------------------
But when my to UA's register with the SAME q-value, I get failure in
next_branches().
-------------------
Sep 28 20:41:54 sip-laptop2 opensips_lab2[2586]: (lab2) - Its a valid
local user
Sep 28 20:41:54 sip-laptop2 opensips_lab2[2586]:
DBG:core:comp_scriptvar: int 20 : 0 / 0
Sep 28 20:41:54 sip-laptop2 opensips_lab2[2586]: (lab2) - Stateful LS
lookup()
Sep 28 20:41:54 sip-laptop2 opensips_lab2[2586]: DBG:registrar:lookup:
setting as ruri <a class="moz-txt-link-rfc2396E" href="sip:jane@10.10.2.33:5060"><sip:jane@10.10.2.33:5060></a>
Sep 28 20:41:54 sip-laptop2 opensips_lab2[2586]: DBG:registrar:lookup:
looking for branches
Sep 28 20:41:54 sip-laptop2 opensips_lab2[2586]: DBG:registrar:lookup:
setting branch <a class="moz-txt-link-rfc2396E" href="sip:jane@10.10.2.33:5061"><sip:jane@10.10.2.33:5061></a>
Sep 28 20:41:54 sip-laptop2 opensips_lab2[2586]: (lab2) - Contact
found in location server, rerouting.
Sep 28 20:41:54 sip-laptop2 opensips_lab2[2586]:
DBG:core:serialize_branches: nothing to do - all same q!
Sep 28 20:41:54 sip-laptop2 opensips_lab2[2586]:
DBG:core:next_branches: no AVPs -- we are done!
Sep 28 20:41:54 sip-laptop2 opensips_lab2[2586]: ERROR:core:do_action:
next_branches failed
Sep 28 20:41:54 sip-laptop2 opensips_lab2[2586]:
DBG:core:parse_headers: flags=ffffffffffffffff
Sep 28 20:41:54 sip-laptop2 opensips_lab2[2586]:
DBG:core:check_ip_address: params 10.10.10.11, sip.core.net, 0
Sep 28 20:41:54 sip-laptop2 opensips_lab2[2586]: DBG:core:_shm_resize:
resize(0) called
Sep 28 20:41:54 sip-laptop2 opensips_lab2[2586]:
DBG:tm:cleanup_uac_timers: RETR/FR timers reset
Sep 28 20:41:54 sip-laptop2 opensips_lab2[2586]: DBG:tm:set_timer:
relative timeout is 500000
Sep 28 20:41:54 sip-laptop2 opensips_lab2[2586]:
DBG:tm:insert_timer_unsafe: [4]: 0xb5b89738 (332300000)
Sep 28 20:41:54 sip-laptop2 opensips_lab2[2586]: DBG:tm:set_timer:
relative timeout is 32
Sep 28 20:41:54 sip-laptop2 opensips_lab2[2586]:
DBG:tm:insert_timer_unsafe: [0]: 0xb5b89754 (363)
Sep 28 20:41:54 sip-laptop2 opensips_lab2[2586]: DBG:tm:_reply_light:
reply sent out. buf=0x81cf0e0: SIP/2.0 5..., shmem=0xb5b8b678: SIP/2.0 5
Sep 28 20:41:54 sip-laptop2 opensips_lab2[2586]: DBG:tm:_reply_light:
finished
-------------------
Concerning the timer issue, I suppose I could fiddle with the normal
fr_inv_timer,
but since I only want to reduce it from its default of 180s, I would
have to find
out wether (serial) forking will occur, and these functions doesnt
seem to give me
that information.
What I am doing wrong, with regards breaking normal parallell fork, I
havent go
a clue, and I hope you can help!
Regards
Taisto
Bogdan-Andrei Iancu skrev 2010-09-28 17:14:
</pre>
<blockquote type="cite">
<pre wrap="">Hi Taiso,
the load_contacts() and next_contact() are deprecated, better use the
core functions:
serialize_branches()
<a class="moz-txt-link-freetext" href="http://www.opensips.org/Resources/DocsCoreFcn16#toc128">http://www.opensips.org/Resources/DocsCoreFcn16#toc128</a>
next_branches() <a class="moz-txt-link-freetext" href="http://www.opensips.org/Resources/DocsCoreFcn16#toc112">http://www.opensips.org/Resources/DocsCoreFcn16#toc112</a>
which works in the same way.
Regards,
Bogdan
</pre>
</blockquote>
<pre wrap="">------------------------------------------------------------------------
_______________________________________________
Users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Users@lists.opensips.org">Users@lists.opensips.org</a>
<a class="moz-txt-link-freetext" href="http://lists.opensips.org/cgi-bin/mailman/listinfo/users">http://lists.opensips.org/cgi-bin/mailman/listinfo/users</a>
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
</body>
</html>