Yeah, I saw that in the README file. But I guess I was asking if next_contacts() could be used to implement a type of "follow-me" service in addition to the PSTN failover functionality that next_gw() provides.

Regards, Paul

On Sun, 20 Feb 2005 01:58:00 +0200, Juha Heinanen jh@lohi.tutpro.com wrote:

Java Rockx writes:

...

Can sequential forking (mutiple contacts) be used with multiple gateways? In other words if next_gw() is used from a failure_route block to try failover gateways, can I also use the next_contacts() for serial forking?

as the name says, next_gw() gives you only one next gateway. there is thus no need for serial forking.

...

If so, can you tell me how I would structure my failure_route or other necessary code blocks?

basically you call next_gw() and if that succeeds you set failure route again and call t_relay.

-- juha

On Sun, 20 Feb 2005, Juha Heinanen wrote:

Java Rockx writes:

...

If so, can you tell me how I would structure my failure_route or other necessary code blocks?

basically you call next_gw() and if that succeeds you set failure route again and call t_relay.

Hi,

Been trying out the LCR module from CVS (head, checkout today) and I can't get it to work when the first gateway fails.

Setup:

mysql> select * from lcr; +--------+----------+--------+----------+ | prefix | from_uri | grp_id | priority | +--------+----------+--------+----------+ | | % | 1 | 0 | +--------+----------+--------+----------+

mysql> select * from gw; +------------------+-----------+------+--------+ | gw_name | ip_addr | port | grp_id | +------------------+-----------+------+--------+ | sip-gw.swip.net | 247264386 | 5060 | 1 | | sip2-gw.swip.net | 247264385 | 5060 | 1 | +------------------+-----------+------+--------+

mysql> select * from gw_grp; +--------+---------------+ | grp_id | grp_name | +--------+---------------+ | 1 | PSTN Gateways | +--------+---------------+

sip2-gw.swip.net doesn't exist i.e. requests to it will timeout.

In route{} I have:

if (!load_gws()) { sl_send_reply("500", "Server Internal Error - Cannot load gateways"); break; };

And then calls to PSTN end up in route[4]

route[4]{ if (method=="INVITE" | method=="BYE") { xlog("L_INFO","Routeblock 4 - Call not to customer, to gateways\n"); };

t_on_failure("1");

if (!next_gw()) { sl_send_reply("503", "Service not available - No gateways"); break; };

if (!t_relay()) { sl_reply_error(); }; }

failure_route[1] { xlog("L_INFO","Failureroute 1 - Get next gateway from LCR\n");

if (!next_gw()) { xlog("L_INFO","Failureroute 1 - No more gateways available\n"); t_reply("503", "Service not available - No more gateways"); break; } else { t_on_failure("1"); t_relay(); }; }

When I call and LCR selects the working gateway first it works ok, but when it selects the gateway that doesn't exist I get this.

0(7028) Tue Mar 1 08:39:33 2005 - <null> - INVITE Call-ID: 00036bc3-7aa52432-43a4bc4f-121393fe@130.244.194.233 From: sip:0856204081@sip-corporate1.testdomain.com To: sip:0890510@sip-corporate1.testdomain.com 0(7028) Routeblock 2 - Calls from customers 0(7028) Call from customer: Test 0(7028) Call passed A-number check 0(7028) Routeblock 3 - To customer? 0(7028) Routeblock 4 - Call not to customer, to gateways 1(7032) Failureroute 1 - Get next gateway from LCR 1(7032) BUG: qm_free: bad pointer 0xb57a1bf0 (out of memory block!) - aborting 0(7028) child process 7032 exited by a signal 6 0(7028) core was generated 0(7028) INFO: dont_fork turned on, living on 2(7034) INFO: signal 15 received 0(7028) Thank you for flying ser

I have restarted ser after changing tables in mysql.

Any hints?

Best regard,

Thomas Björklund

On Wed, 2 Mar 2005, Juha Heinanen wrote:

thomas,

i looked at next_gw and it allocated memory for uri before called do_action to append the branch and then it free the memory. so i didn't see anything obvious tha could cause your core dump.

And my configuration in failure_route is ok?

failure_route[1] { if (!next_gw()) { t_reply("503", "Service not available - No more break; } else { t_on_failure("1"); t_relay(); }; }

I don't need append_branch or something?

can you start ser something like

ser -u root -g root -w /tmp

so that it produces a core dump. then run

gdb /usr/sbin/ser /tmp/core

and give it "where" command and send me the result.

-- juha

(gdb) where #0 0x008bfcef in raise () from /lib/tls/libc.so.6 #1 0x008c14f5 in abort () from /lib/tls/libc.so.6 #2 0x08081406 in qm_free (qm=0x80fad40, p=0xb579dbec, file=0x9cc898 "¤G\023", func=0x809e9b7 "free_lump", line=375) at mem/q_malloc.c:445 #3 0x080532cc in free_lump (lmp=0xb579dbcc) at data_lump.c:377 #4 0x003b7223 in free_via_clen_lump (list=0x3d8eb4) at fix_lumps.h:73 #5 0x003b5d0c in print_uac_request (t=0x3d0664, i_req=0x3d8c20, branch=0, uri=0x0, len=0xbfff907c, send_sock=0x0, proto=PROTO_NONE) at t_fwd.c:109 #6 0x003b613e in add_uac (t=0xb579c778, request=0x3d8c20, uri=0xbfff9118, next_hop=0xbfff9118, proxy=0x813983c, proto=1) at t_fwd.c:228 #7 0x003b696f in t_forward_nonack (t=0xb579c778, p_msg=0x3d8c20, proxy=0x0, proto=0) at t_fwd.c:453 #8 0x003be00e in w_t_relay (p_msg=0x3d8c20, _foo=0x0, _bar=0x0) at tm.c:886 #9 0x0804f1aa in do_action (a=0x81399ec, msg=0x3d8c20) at action.c:611 #10 0x08050a6c in run_actions (a=0x81399ec, msg=0x3d8c20) at action.c:719 #11 0x0804f0c9 in do_action (a=0x8139a3c, msg=0x3d8c20) at action.c:601 #12 0x08050a6c in run_actions (a=0x8139a3c, msg=0x3d8c20) at action.c:719 #13 0x003c736e in run_failure_handlers (t=0xb579c778, rpl=0x0, code=0) at t_reply.c:629 #14 0x003c6713 in t_should_relay_response (Trans=0xb579c778, new_code=408, branch=0, should_store=0xbfff9638, should_relay=0xbfff963c, cancel_bitmap=0x0, reply=0x0) at t_reply.c:772 #15 0x003c2daf in relay_reply (t=0xb579c778, p_msg=0xffffffff, branch=0, msg_status=408, cancel_bitmap=0xbfff96a8) at t_reply.c:994 #16 0x003b9413 in final_response_handler (fr_tl=0xffffff9c) at timer.c:251 #17 0x003b8d3d in timer_routine (ticks=7, attr=0x0) at timer.c:952 #18 0x0807adbb in timer_ticker () at timer.c:146 #19 0x0805bda1 in main_loop () at main.c:873 #20 0x0805d21c in main (argc=-1251896308, argv=0x0) at main.c:1568

Best regards,

Thomas Björklund