Yeah, unfortunately Nabble caused an issue with formatting in HTML with all the tags ... Here's the contents:<span class="ul-threaded" style="margin: 0.5em 0pt 0pt -20px;"><span class="text-cell"><br><br>-----------------------------------------------------------------<br>
<br>Hello all,<br><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.
</span></span><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br>
<br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><br><div class="gmail_quote">
On Mon, Mar 23, 2009 at 4:53 PM, Iñaki Baz Castillo <span dir="ltr"><<a href="mailto:ibc@aliax.net">ibc@aliax.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Please note how your mail looks:<br>
<br>
El Lunes, 23 de Marzo de 2009, fabio4prez escribió:<br>
<div class="im">> Hello all,<br>
> <br><br>We're running Opensips in a production environment with about<br>
> 10,000 users. &nbsp;We're currently running in a Registrar/Stateless proxy<br>
> configuration -- very basic setup. <br><br>Anyways, to the point.<br>
> &nbsp;Currently, at random points throughout the day, opensips will stop<br>
> running and the following will show up in the log: <br><br>Mar 23 15:04:35<br>
> serbox2 /sbin/opensips[19181]: ERROR:registrar:update_contacts: invalid<br>
> cseq for aor &lt;70154&gt; <br>Mar 23 15:04:35 serbox2<br>
> /sbin/opensips[19178]: ERROR:registrar:update_contacts: invalid cseq for<br>
> aor &lt;vh27126&gt; <br>Mar 23 15:04:35 serbox2 /sbin/opensips[19180]:<br>
> ERROR:registrar:update_contacts: invalid cseq for aor &lt;70154&gt; <br>Mar<br>
> 23 15:04:36 serbox2 /sbin/opensips[19181]: CRITICAL:core:anchor_lump:<br>
> offset exceeds message size (1033 &gt; 1000) aborting... <br>Mar 23<br>
> 15:04:36 serbox2 /sbin/opensips[19178]: CRITICAL:core:anchor_lump: offset<br>
> exceeds message size (1033 &gt; 1000) aborting... <br>Mar 23 15:04:40<br>
<br>
</div>[...]<br>
<br>
You mail has "Content-Type: text/plain;" but the text has obviously HTML tags.<br>
Please don't use HTML but just text plain.<br>
<br>
Regards.<br>
<br>
<br>
<br>
--<br>
<font color="#888888">Iñaki Baz Castillo<br>
</font></blockquote></div><br>