[OpenSIPS-Users] Serialforking failure, with lcr:parse_phostport: too many colons in udp:: 0
Bogdan-Andrei Iancu
bogdan at voice-system.ro
Wed Sep 29 09:45:17 CEST 2010
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:
> 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 <sip:jane at 10.10.2.33:5060>
> 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 <sip:jane at 10.10.2.33:5061>
> 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:
>> Hi Taiso,
>>
>> the load_contacts() and next_contact() are deprecated, better use the
>> core functions:
>> serialize_branches()
>> http://www.opensips.org/Resources/DocsCoreFcn16#toc128
>> next_branches() http://www.opensips.org/Resources/DocsCoreFcn16#toc112
>>
>> which works in the same way.
>>
>> Regards,
>> Bogdan
>>
> ------------------------------------------------------------------------
>
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>
--
Bogdan-Andrei Iancu
OpenSIPS Bootcamp
15 - 19 November 2010, Edison, New Jersey, USA
www.voice-system.ro
More information about the Users
mailing list