[OpenSIPS-Users] Serialforking failure, with lcr:parse_phostport: too many colons in udp:: 0
Taisto Qvist (WM)
taisto.qvist at ip-solutions.se
Tue Oct 5 14:19:42 CEST 2010
Hi again, and thanks for your reply!
Personally I think alternative 2 feels best. It's similar to how
other functions use the returncode for status indications.
But either solution works for me, even though the first solution
is more specific for my requirement, and i suppose that the more
generic the solution the better.
Regards
Taisto
On Tue, 05 Oct 2010 11:53:40 +0300, Bogdan-Andrei Iancu
<bogdan at voice-system.ro> wrote:
> Hi Taisto,
>
>> Concerning the timer issue, I know about the avp-concept, and with your
>> solution below, I can figure out how to change the timer when serial
>> forking starts.
>> But what I also wanted, was to make sure that the last branch in the
>> fork was given a normal timer C.
>> In other words, as long as there are available branches, I will
>> "rollOver" to the next branch fairly quickly, but once i start the
>> last branch, normal timer C would apply.
>> (in other words, what the "fr_inv_timer_next" did in lcr)
>> So I would need, I think, to figure out in a failure_route(), that
>> the branches I am starting with next_branches() are the last ones.
>> But how can I know that? I cant find a way to count remaining branches?
> I see, I was not aware of this functionality of lcr functions. This can
> be fixed in several ways:
> 1) next_branches() get a new extra optional param - the rollover
> timeout - it will be set only if other branches are still
available. If
> not, the default timeout can be used
> 2) next_branches() can return (1) if a next branch was set and other
> branches are available and (2) if a next branch was set and NO
other
> branches are available; and you can do from script all your
timeout logic.
> 3) add a new function "still_has_branches()" to use after
> next_branches().
>
> Which approach you think is the simplest to use and also flexible enough
> to cover all cases ?
>
> Regards,
> Bogdan
>>
>> Btw, my "hack" was never intended as a real fix. I was just grasping
>> at straws during troubleshooting. Also, it didnt solve the scenario
>> of when there is only ONE contact in the target set.
>> Then it fails again since there are no branches, just a req-uri.
>>
>> Thanks again,
>> Taisto Qvist
>>
>> Bogdan-Andrei Iancu skrev 2010-09-29 09:45:
>>> 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
>>>>
>>>>
>>>
>>
------------------------------------------------------------------------
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
--
Taisto Qvist, IP-Solutions
Mobile: +46-708-88 02 63
"We are Pentium of Borg. Division is futile, You will be approximated"
More information about the Users
mailing list