[OpenSIPS-Users] Serialforking failure, with lcr:parse_phostport: too many colons in udp:: 0
Bogdan-Andrei Iancu
bogdan at voice-system.ro
Tue Oct 5 10:53:40 CEST 2010
Hi Taisto,
Taisto Qvist wrote:
> Hi Bogdan, and thanks again for the quick replies!
>
> I'll try the suggestion below. The downside of that solution(i think?)
> is that cant know if there was a real failure of the serialize&&next()-
> functions, and return an "serialforking-specific" error response if
> it was.
I do not think this is a problem - doesn't matter if there was nothing
to serialize or the serialize process failed, you should carry on with
normal forwarding - there are no other options.
> If something causes the serialize&&next_branches() to fail, that fault
> will be caught during t_relay later, which generates a (general?) failure
> response by TM...but no matter. this is a sip-course setup, so it will do.
the reasons to fail for serialize&branches() are not affecting t_relay()
at all - the first 2 may fail because of mem issue only, so there is no
error that you may catch in advance for t_relay.
>
> 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