Hi All,
How reliable is forward_tcp? I have 3 SIP servers, 1 acting as the database of the three, I used forward tcp to replicate registration, unfortunately there are some instance that a local extension cannot contact another extension. Here's a part of my config
if ((src_ip == 10.10.10.149) || (src_ip == 10.10.10.151)) { save_memory("location"); };
if (!www_authorize("sipdomain.com", "subscriber")) { www_challenge("sipdomain.com", "0"); break; };
if (!save("location")) { sl_reply_error(); } else { if ((!src_ip == 10.10.10.149) && (!src_ip == 10.10.10.151)) { forward_tcp("10.10.10.149", 5060); forward_tcp("10.10.10.151", 5060); }; break;
should I use savce_memory? becuase I'm seeing some config that uses save_noreply, should I use this one?
also should I changed the db_url parameter of usrloc and point it to the database of the main server?
e.g.
modparam("usrloc", "db_mode", 2) modparam("usrloc", "db_url", "mysql://ser:heslo@10.10.10.146/ser")
Hope you guys can help me
TIA
Regards, Nhadie
________________________________________________ Message sent using UebiMiau 2.7
Hi!
Nhadie wrote:
if ((src_ip == 10.10.10.149) || (src_ip == 10.10.10.151)) { save_memory("location"); };
I'd add a 'break;' there just to be sure ;)
I cannot give you any feedback on the reliability of the TCP stuff but just some thoughts:
- Why not use UDP? I mean if your local network is saturated or drops packets for other reasons your registration database is probably one of your smaller problems. - stateful vs. stateless Always take into account what would happen if some machine goes down. If you rely on a 200 OK or successful TCP handshake this may fill up your transaction module and initiate a retransmission flood if something goes 'slightly' bad. Forwarding via UDP and save_noreply() works very well in other setups. - Multicast It seems to me if your hosts are within the same multicast domain. How about sending successful registrations to a multicast address. It's gonna be fire-and-forget allowing you to completely decouple your SIP servers from each other. Remember to disable multicast routing - consume_credentials() Didn't see it in your config but since I'm paranoid: How about removing the authentication header?
Cheers, Hendrik