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 serbox2 /sbin/opensips[19180]: CRITICAL:core:anchor_lump:
offset exceeds message size (1033 > 1000) aborting...
<br>Mar 23 15:04:48 serbox2 /sbin/opensips[19177]: INFO:core:handle_sigs: child
process 19181 exited by a signal 6
<br>Mar 23 15:04:48 serbox2 /sbin/opensips[19177]: INFO:core:handle_sigs: core
was generated
<br>Mar 23 15:04:48 serbox2 /sbin/opensips[19177]: INFO:core:handle_sigs:
terminating due to SIGCHLD
<br>Mar 23 15:04:48 serbox2 /sbin/opensips[19179]: INFO:core:sig_usr: signal 15
received
<br>Mar 23 15:04:48 serbox2 /sbin/opensips[19182]: INFO:core:sig_usr: signal 15
received
<br>Mar 23 15:04:48 serbox2 /sbin/opensips[19183]: INFO:core:sig_usr: signal 15
received
<br>Mar 23 15:05:24 serbox2 opensips: WARNING:core:fix_socket_list: could not
rev. resolve XXX.XXX.XXX.XXX
<br><br>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.
<br><br>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.
<br><br>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.
<br><br>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.
<br><br>B) Here's the basic contents of our route script (where the ip
addresses have been changed to *.domain for security purposes)
<br><br>route
<br>{
<br> if (!mf_process_maxfwd_header("10"))
<br> {
<br>
sl_send_reply("483","Too Many Hops");
<br> exit;
<br> }
<br><br> if
(!is_method("REGISTER|MESSAGE"))
<br> {
<br>
if(nat_uac_test("19"))
<br> {
<br>
record_route(";nat=yes");
<br> }
<br> else
<br> {
<br>
record_route();
<br> }
<br> }
<br><br> if (is_method("REGISTER"))
<br> {
<br> if
(!search("^Contact:\ +\*"))
<br> {
<br> #
xlog("Contact fix $ru\n");
<br>
fix_nated_register();
<br>
force_rport();
<br> }
<br><br> if
(!save("location"))
<br>
sl_reply_error();
<br> exit;
<br> }
<br><br> if(src_ip == "sbc.domain")
<br> {
<br>
rewritehost("ser.domain");
<br><br>
if(!lookup("location"))
<br> {
<br>
sl_send_reply("404", "Not Found");
<br>
exit;
<br> }
<br><br> route(1);
<br> exit;
<br> }
<br><br> else
<br> {
<br>
if(is_method("NOTIFY"))
<br> {
<br>
sl_send_reply("404", "Not Found");
<br>
exit;
<br> }
<br><br>
rewritehost("sbc.domain");
<br> route(1);
<br> exit;
<br> }
<br>}
<br><br># --------- route[1] block -------------
<br># Handle NAT-related issues on INVITES
<br>#
<br><br>route[1]
<br>{
<br> #xlog("Beginning route $ru\n");
<br> if (is_method("INVITE"))
<br> {
<br> force_rport();
<br> fix_nated_contact();
<br>
fix_nated_sdp("10");
<br> # xlog("Routing 1
inside $ru\n");
<br> forward();
<br> exit;
<br> }
<br> force_rport();
<br> fix_nated_contact();
<br><br> # xlog("Forward
route $ru\n");
<br><br> if (!forward())
<br> {
<br> sl_reply_error();
<br> };
<br>}
<br><br><br><br>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?
<br><br>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?
<br><br>Lastly, we see this a lot in the logs:
<br><br>Mar 23 16:47:35 serbox2 /sbin/opensips[24586]:
ERROR:registrar:update_contacts: invalid cseq for aor <vh13669>
<br>Mar 23 16:47:36 serbox2 /sbin/opensips[24586]:
ERROR:registrar:update_contacts: invalid cseq for aor <vh13669>
<br><br>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.
<br><br>Thanks very much for any help.
--
View this message in context:
http://n2.nabble.com/Critical%3Acore%3Aanchor_lump%3A-offset-exceeds-message-size-%281033-%3E-1000%29%2C-aborting----exited-by-signal-6-tp2523387p2523387.html
Sent from the OpenSIPS - Users mailing list archive at Nabble.com.
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
