[OpenSIPS-Users] Serialforking failure, with lcr:parse_phostport: too many colons in udp:: 0

[Taisto Qvist]

  Just some additional information. I've been reading up on variables,
script-operations, etc, and I cant find any(simple) way to cause
what I call a "roll-over" timer.
That is, setting the timer(C) between the different serial-forked
targets low, but keeping a normal timer c for non-serial forked
scenarios, and the last target in a serial fork.

Also, even though I am a complete n00b when it comes to the opensips
source, I got the _parallell_ forking to work, by hacking serialize.c
and making sure that it doesnt completly bail out if the q-values are
the same.
This will most certainly cause a lot of unnecessary sorting which the
old logic in the lcr-module was able to avoid, if I understood the
docs properly.
But at least now my call to serialize_branches() doesnt fail.

  if (branch.s == 0) {
           LM_DBG("nothing to do - all same q!\n");
           // return 0; // This causes parallell fork to fail
  }

Regards
Taisto


Taisto Qvist skrev 2010-09-28 18:56:
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20100928/a623e1f3/attachment.htm