[OpenSIPS-Users] Serialforking failure, with lcr:parse_phostport: too many colons in udp:: 0
Bogdan-Andrei Iancu
bogdan at voice-system.ro
Wed Oct 6 17:04:55 CEST 2010
Hi Taisto,
could you test the rev 7248 on trunk for solution 2) ? if ok, I will
backport to 1.6
Regards,
Bogdan
Taisto Qvist (WM) wrote:
> 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
>>>
>>>
>
>
--
Bogdan-Andrei Iancu
OpenSIPS Bootcamp
15 - 19 November 2010, Edison, New Jersey, USA
www.voice-system.ro
More information about the Users
mailing list