Yeah, unfortunately Nabble caused an issue with formatting in HTML with all the tags ... Here's the contents:
----------------------------------------------------------------- Hello all, We're running Opensips in a production environment with about 10,000 users. We're currently running in a Registrar/Stateless proxy configuration -- very basic setup. Anyways, to the point. Currently, at random points throughout the day, opensips will stop running and the following will show up in the log: Mar 23 15:04:35 serbox2 /sbin/opensips[19181]: ERROR:registrar:update_contacts: invalid cseq for aor <70154> Mar 23 15:04:35 serbox2 /sbin/opensips[19178]: ERROR:registrar:update_contacts: invalid cseq for aor <vh27126> Mar 23 15:04:35 serbox2 /sbin/opensips[19180]: ERROR:registrar:update_contacts: invalid cseq for aor <70154> Mar 23 15:04:36 serbox2 /sbin/opensips[19181]: CRITICAL:core:anchor_lump: offset exceeds message size (1033 > 1000) aborting... Mar 23 15:04:36 serbox2 /sbin/opensips[19178]: CRITICAL:core:anchor_lump: offset exceeds message size (1033 > 1000) aborting... Mar 23 15:04:40 serbox2 /sbin/opensips[19180]: CRITICAL:core:anchor_lump: offset exceeds message size (1033 > 1000) aborting... Mar 23 15:04:48 serbox2 /sbin/opensips[19177]: INFO:core:handle_sigs: child process 19181 exited by a signal 6 Mar 23 15:04:48 serbox2 /sbin/opensips[19177]: INFO:core:handle_sigs: core was generated Mar 23 15:04:48 serbox2 /sbin/opensips[19177]: INFO:core:handle_sigs: terminating due to SIGCHLD Mar 23 15:04:48 serbox2 /sbin/opensips[19179]: INFO:core:sig_usr: signal 15 received Mar 23 15:04:48 serbox2 /sbin/opensips[19182]: INFO:core:sig_usr: signal 15 received Mar 23 15:04:48 serbox2 /sbin/opensips[19183]: INFO:core:sig_usr: signal 15 received Mar 23 15:05:24 serbox2 opensips: WARNING:core:fix_socket_list: could not rev. resolve XXX.XXX.XXX.XXX I'm not certain that this is a route script issue. It seems like a message header that isn't present is trying to be parsed or something along those lines. In trying to track this issue down, but would like a few pointers as to where to be looking. First, we've currently set the number of forks at 6 and the private memory per process to 32 MB. We're also using 512 MB of "shared" memory. A) Are there any recommendations as to memory requirements for the amount of users/subscriber base? Again, we process somewhere around 2 million registrations alone in an hour, and just statelessly forward requests unless they're destined for a UAC, where we do a location lookup and then forward to the handset. I haven't really found any core statistics or guidelines for memory parameters set. If there is any better documentation on this, I'd greatly appreciate a link. B) Here's the basic contents of our route script (where the ip addresses have been changed to *.domain for security purposes) route { if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } if (!is_method("REGISTER|MESSAGE")) { if(nat_uac_test("19")) { record_route(";nat=yes"); } else { record_route(); } } if (is_method("REGISTER")) { if (!search("^Contact:\ +\*")) { # xlog("Contact fix $ru\n"); fix_nated_register(); force_rport(); } if (!save("location")) sl_reply_error(); exit; } if(src_ip == "sbc.domain") { rewritehost("ser.domain"); if(!lookup("location")) { sl_send_reply("404", "Not Found"); exit; } route(1); exit; } else { if(is_method("NOTIFY")) { sl_send_reply("404", "Not Found"); exit; } rewritehost("sbc.domain"); route(1); exit; } } # --------- route[1] block ------------- # Handle NAT-related issues on INVITES # route[1] { #xlog("Beginning route $ru\n"); if (is_method("INVITE")) { force_rport(); fix_nated_contact(); fix_nated_sdp("10"); # xlog("Routing 1 inside $ru\n"); forward(); exit; } force_rport(); fix_nated_contact(); # xlog("Forward route $ru\n"); if (!forward()) { sl_reply_error(); }; } Is there a particular time where, for example, we're trying to fix a header that might not exist, that could cause this particular issue? As an FYI, we're currently running Opensips version 1.4.2, and are considering a production release to 1.4.5 tonight to see if any of these particular issues are fixed. I see also that 1.5 was released as well, is this a production worthy release? Lastly, we see this a lot in the logs: Mar 23 16:47:35 serbox2 /sbin/opensips[24586]: ERROR:registrar:update_contacts: invalid cseq for aor <vh13669> Mar 23 16:47:36 serbox2 /sbin/opensips[24586]: ERROR:registrar:update_contacts: invalid cseq for aor <vh13669> I've read something about Polycom user agent's attempting to reregister with the same call-id but incrimenting the cseq ID, but I also think I've read that there was a fix for the order this was looked up in in a version past 1.4.2. Thanks very much for any help. On Mon, Mar 23, 2009 at 4:53 PM, Iñaki Baz Castillo <i...@aliax.net> wrote: > Please note how your mail looks: > > El Lunes, 23 de Marzo de 2009, fabio4prez escribió: > > Hello all, > > <br><br>We're running Opensips in a production environment with about > > 10,000 users. We're currently running in a Registrar/Stateless > proxy > > configuration -- very basic setup. <br><br>Anyways, to the point. > > Currently, at random points throughout the day, opensips will stop > > running and the following will show up in the log: <br><br>Mar 23 > 15:04:35 > > serbox2 /sbin/opensips[19181]: ERROR:registrar:update_contacts: invalid > > cseq for aor <70154> <br>Mar 23 15:04:35 serbox2 > > /sbin/opensips[19178]: ERROR:registrar:update_contacts: invalid cseq for > > aor <vh27126> <br>Mar 23 15:04:35 serbox2 /sbin/opensips[19180]: > > ERROR:registrar:update_contacts: invalid cseq for aor <70154> > <br>Mar > > 23 15:04:36 serbox2 /sbin/opensips[19181]: CRITICAL:core:anchor_lump: > > offset exceeds message size (1033 > 1000) aborting... <br>Mar 23 > > 15:04:36 serbox2 /sbin/opensips[19178]: CRITICAL:core:anchor_lump: offset > > exceeds message size (1033 > 1000) aborting... <br>Mar 23 15:04:40 > > [...] > > You mail has "Content-Type: text/plain;" but the text has obviously HTML > tags. > Please don't use HTML but just text plain. > > Regards. > > > > -- > Iñaki Baz Castillo >
_______________________________________________ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users