[OpenSIPS-Users] Serialforking failure, with lcr:parse_phostport: too many colons in udp:: 0
Taisto Qvist
taisto.qvist at ip-solutions.se
Wed Sep 29 10:46:40 CEST 2010
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.
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.
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?
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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.opensips.org/pipermail/users/attachments/20100929/40c500ea/attachment-0001.htm
More information about the Users
mailing list