[OpenSIPS-Users] Serialforking failure, with lcr:parse_phostport: too many colons in udp:: 0
Bogdan-Andrei Iancu
bogdan at voice-system.ro
Wed Sep 29 09:51:12 CEST 2010
Taisto Qvist wrote:
> Just some additional information. I've been reading up on variables,
> script-operations, etc, and I cant find any(simple) way to cause
> what I call a "roll-over" timer.
> That is, setting the timer(C) between the different serial-forked
> targets low, but keeping a normal timer c for non-serial forked
> scenarios, and the last target in a serial fork.
you can achieve custom timeouts (based on calling scenario) by using:
http://www.opensips.org/html/docs/modules/1.6.x/tm.html#id271154
and populating that AVP before t_relay() will set the timeout.
>
> Also, even though I am a complete n00b when it comes to the opensips
> source, I got the _parallell_ forking to work, by hacking serialize.c
> and making sure that it doesnt completly bail out if the q-values are
> the same.
> This will most certainly cause a lot of unnecessary sorting which the
> old logic in the lcr-module was able to avoid, if I understood the
> docs properly.
> But at least now my call to serialize_branches() doesnt fail.
>
> if (branch.s == 0) {
> LM_DBG("nothing to do - all same q!\n");
> // return 0; // This causes parallell fork to fail
> }
I do not agree with your hack to be honest - there is not need for that
- in your case it is just a matter of properly interpreting the return
code of the 2 functions - see my prev email with the script snapshot.
Regards,
Bogdan
>
> Regards
> Taisto
>
>
> Taisto Qvist skrev 2010-09-28 18:56:
>> 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