use rtpproxy trunk tree, perhaps have no this buf. rtpproxy-0.3.0 has this problem . I use the SVN trunk . this problem not happend. 在 2007-05-01二的 16:15 +0800，users-request(a)openser.xn--org:-7z8fk634a > Send Users mailing list submissions to > users(a)openser.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://openser.org/cgi-bin/mailman/listinfo/users > or, via email, send a message with subject or body 'help' to > users-request(a)openser.org > > You can reach the person managing the list at > users-owner(a)openser.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Users digest..." > > > Today's Topics: > > 1. Re: memory leak in presence module? (Klaus Darilion) > 2. rtpproxy CPU usage issue.. (Sajith T S) > 3. Dropped calls with OpenSER 1.1.x and Asterisk >= 1.2.14 > (Edoardo Serra) > 4. Re: Redirect the same INVITE to the SIP SERVER from Balancer? > (Alejandro Sanchez) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 30 Apr 2007 15:34:31 +0200 > From: Klaus Darilion &lt;klaus.mailinglists(a)pernau.at&gt; > Subject: Re: [Users] memory leak in presence module? > To: daniel(a)voice-system.ro > Cc: "users openser.org" &lt;users(a)openser.org&gt; > Message-ID: &lt;4635F067.6070006(a)pernau.at&gt; > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi! > > I tried again and it happened again: > > Apr 30 15:00:54 ds3000 /usr/sbin/openser[7648]: > 32b24f15e52d603ba890a9729723c4b0.0167///45-6782(a)83.136.32.132 PUBLISH > detected, handle_publish ... > outside t_newtran > Apr 30 15:00:54 ds3000 /usr/sbin/openser[7655]: > 32b24f15e52d603ba890a9729723c4b0.7e11///14-6782(a)83.136.32.132 PUBLISH > detected, handle_publish ... > outside t_newtran > Apr 30 15:00:54 ds3000 /usr/sbin/openser[7648]: > 32b24f15e52d603ba890a9729723c4b0.0167///45-6782(a)83.136.32.132 PUBLISH > detected, handle_publish ... > inside t_newtran > Apr 30 15:00:54 ds3000 /usr/sbin/openser[7655]: > 32b24f15e52d603ba890a9729723c4b0.7e11///14-6782(a)83.136.32.132 PUBLISH > detected, handle_publish ... > inside t_newtran > Apr 30 15:01:03 ds3000 /usr/sbin/openser[7644]: child process 7648 > exited by a signal 9 > Apr 30 15:01:08 ds3000 /usr/sbin/openser[7644]: core was not generated > Apr 30 15:01:08 ds3000 /usr/sbin/openser[7644]: INFO: terminating due to > SIGCHLD > Apr 30 15:01:14 ds3000 /usr/sbin/openser[7657]: INFO: signal 15 received > Apr 30 15:01:14 ds3000 /usr/sbin/openser[7657]: Memory status (pkg): > Apr 30 15:01:14 ds3000 /usr/sbin/openser[7657]: qm_status (0x8145960): > Apr 30 15:01:14 ds3000 /usr/sbin/openser[7657]: heap size= 1048576 > Apr 30 15:01:14 ds3000 /usr/sbin/openser[7659]: INFO: signal 15 received > Apr 30 15:01:14 ds3000 /usr/sbin/openser[7653]: INFO: signal 15 received > Apr 30 15:01:14 ds3000 /usr/sbin/openser[7653]: Memory status (pkg): > Apr 30 15:01:14 ds3000 /usr/sbin/openser[7650]: INFO: signal 15 received > > > Any hints how to debug this? > > regards > klaus > > Daniel-Constantin Mierla wrote: > > Hello Klaus, > > > > On 04/30/07 13:55, Klaus Darilion wrote: > >> > >> > >> Daniel-Constantin Mierla wrote: > >>> Hello Klaus, > >>> > >>> On 04/27/07 09:27, Klaus Darilion wrote: > >>>> Hi Daniel! > >>>> > >>>> I've tried with t_release and it was running fine several hours > >>>> without leaking. But then, unfortunately openser terminated with > >>>> signal 9. I've never seen this before. > >>> > >>> signal 9 is KILL, it is very strange if it was not issued by a user > >>> or other process. > >>> > >>> We discovered the issue (tm/uac.c, line 224), ther eis flag that is > >>> kept to see if there was some operation with the transaction, but in > >>> case of handle_publish() that flag is set by TM api when sending > >>> NOTIFY. The patch is trivial, removing a line, but we have to > >>> investigate if there are some other effects -- so it may take a > >>> while. t_release() should solve meanwhile. > >> > >> Should solve the memory-leak - but the signal 9? > > It might be that it took so long to write the mem long at shut down and > > openser killed itself. If it was not due to a openser stop, then I am > > not aware of any case when signal 9 is sent unless issued by user. > > > > Cheers, > > Daniel > > > >> > >> regards > >> klaus > >> > > > > ------------------------------ > > Message: 2 > Date: Mon, 30 Apr 2007 19:43:41 +0530 > From: Sajith T S &lt;sajithts(a)gmail.com&gt; > Subject: [Users] rtpproxy CPU usage issue.. > To: users(a)openser.org > Message-ID: &lt;4635F995.3020908(a)gmail.com&gt; > Content-Type: text/plain; charset=ISO-8859-1 > > Hi, > > Have any of you folks seen an abnormal CPU usage issue with rtpprpxy? > At times, "top" shows rtpproxy uses 100% CPU (sometimes 99%, sometimes > even 101%!), and it stops responding to openser. I have to restart > everything now. > > A small thread in Serdev list recommends upgrading rtpproxy to latest > in CVS: > > http://lists.iptel.org/pipermail/serdev/2006-June/007459.html > > Mine was fairly old, so I upgraded, but without much progress. What > really bugs is I don't know what triggers it. > > Backtraces suggest that this occurs in different places in rtpproxy, > before and after upgrading. > > Before upgrade: > > (gdb) where > #0 0xb7f49410 in ?? () > #1 0xbffd6d88 in ?? () > #2 0x00000076 in ?? () > #3 0xbffd2410 in ?? () > #4 0x4a8d9fd1 in sendto () from /lib/tls/libc.so.6 > #5 0x0804ac0c in main (argc=7, argv=0xbffd6e14) at main.c:1467 > > After upgrade: > > (gdb) where > #0 0xb7f0a410 in ?? () > #1 0xbfcb0258 in ?? () > #2 0xbfcadfc0 in ?? () > #3 0xbfcab8e0 in ?? () > #4 0x00bb8dd1 in recvfrom () from /lib/tls/libc.so.6 > #5 0x0804a568 in main (argc=7, argv=0xbfcb02e4) at main.c:1364 > > Any clues? Is this a known problem and is there a patch or some sort > ofworkaround? Is there anything I need to upgrade? (This is CentOS > 4.4, FWIW) Anything that should be done in openser configuration? > > Thanks much in advance. > > - Sajith. > > > > ------------------------------ > > Message: 3 > Date: Mon, 30 Apr 2007 16:27:43 +0200 > From: Edoardo Serra &lt;edoardo.serra(a)webrainstorm.it&gt; > Subject: [Users] Dropped calls with OpenSER 1.1.x and Asterisk >= > 1.2.14 > To: users(a)openser.org > Message-ID: &lt;f14udl$s9t$1(a)sea.gmane.org&gt; > Content-Type: text/plain; charset=ISO-8859-15; format=flowed > > Hi guys, > I'm having a problem about asterisk dropping calls received from OpenSER > > The problems was spotted at Asterisk users mailing lists > http://lists.digium.com/pipermail/asterisk-users/2007-April/184875.html > > Asterisk complains about an ACK not received and drops the calls. > It expects OpenSER to send an ACK back to its '200 OK' when the call is > set up > > Is that a problem OpenSER should solve ??? > > Tnx in advance > > Regards > > Edoardo Serra > WeBRainstorm S.r.l. > > > > > ------------------------------ > > Message: 4 > Date: Mon, 30 Apr 2007 10:54:17 -0500 (CDT) > From: Alejandro Sanchez &lt;alexsc_java(a)yahoo.com.mx&gt; > Subject: Re: [Users] Redirect the same INVITE to the SIP SERVER from > Balancer? > To: daniel(a)voice-system.ro > Cc: openser openser &lt;users(a)openser.org&gt; > Message-ID: &lt;626480.1349.qm(a)web35306.mail.mud.yahoo.com&gt; > Content-Type: text/plain; charset="iso-8859-1" > > Thank's for answer Daniel. > > In fact i think is a retransmission and i need the > balanser ask to the SipServer if the another > videotelephone B is register in every retransmision of > the INVITE. > > I send the trace where: > > -192.168.23 = Balancer (openser) > -192.168.20 = SipServer (openser) > -192.168.4 = VideoTelephone > > In this case there is not another videotelefhone. > > > Thank's > > > > > > --- Daniel-Constantin Mierla &lt;daniel(a)voice-system.ro&gt; > escribi: > > > Hello, > > > > if it happens in very short time, then seems to be a > > retransmission. Can > > you post a sip trace (ngrep, ethereal) taken on the > > balancer? > > > > Cheers, > > Daniel > > > > > > On 04/27/07 22:01, Alejandro Sanchez wrote: > > > Hello. > > > > > > My enviroment is the next: > > > > > > -Balancer > > > OS. Red Hat 4 up. 4 > > > Openser 1.1.1 (balance with the module dispatcher) > > > > > > -Sip Server > > > OS. Red Hat 4 up. 4 > > > Openser 1.1.1 > > > > > > > > > The actual flow is this. > > > > > > VTA B C VTB > > > ---register----> > > > ---register----> > > > <---200 OK------ > > > <----200 OK----- > > > > > > ---invite------> > > > -----invite----> > > > <-404 NotFound-- > > > --404 NotFound-- > > > <----------register--------- > > > ----register----> > > > <----200 OK------ > > > ------------ 200 OK--------> > > > ----invite-----> > > > <-404 NotFound-- > > > > > > VTA= videotelephone A > > > B= balancer (openser 1.1.1 with dispatcher module) > > > C= SipServer (openser 1.1.1) > > > VTB= video telephone B > > > > > > How you see when the VTA sends again the same > > invite, > > > the balancer(B) answer with the 404 not found but > > > without ask again to the SipServer(C), and my > > problem > > > is that VTB is late and i have to try find it in > > the > > > second invite, then in the second invite i need > > ask > > > again to the SipServer(C) if the VTB is register. > > > > > > VTA y VTB access to the IP network making a > > dial-up > > > connection. > > > > > > Why the balancer dosen't send the second invite to > > > SipServer? > > > > > > How do i get this flow? > > > > > > > > > Thank's for the Help > > > > > > > > > __________________________________________________ > > > Correo Yahoo! > > > Espacio para todos tus mensajes, antivirus y > > antispam gratis! > > > Regstrate ya - http://correo.yahoo.com.mx/ > > > > > > _______________________________________________ > > > Users mailing list > > > Users(a)openser.org > > > http://openser.org/cgi-bin/mailman/listinfo/users > > > > > > > > > > > __________________________________________________ > Correo Yahoo! > Espacio para todos tus mensajes, antivirus y antispam gratis! > Regstrate ya - http://correo.yahoo.com.mx/ >