[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