1 May
2007
1 May
'07
11:20 a.m.
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 <klaus.mailinglists(a)pernau.at>
> Subject: Re: [Users] memory leak in presence module?
> To: daniel(a)voice-system.ro
> Cc: "users openser.org" <users(a)openser.org>
> Message-ID: <4635F067.6070006(a)pernau.at>
> 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 <sajithts(a)gmail.com>
> Subject: [Users] rtpproxy CPU usage issue..
> To: users(a)openser.org
> Message-ID: <4635F995.3020908(a)gmail.com>
> 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 <edoardo.serra(a)webrainstorm.it>
> Subject: [Users] Dropped calls with OpenSER 1.1.x and Asterisk >=
> 1.2.14
> To: users(a)openser.org
> Message-ID: <f14udl$s9t$1(a)sea.gmane.org>
> 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 <alexsc_java(a)yahoo.com.mx>
> Subject: Re: [Users] Redirect the same INVITE to the SIP SERVER from
> Balancer?
> To: daniel(a)voice-system.ro
> Cc: openser openser <users(a)openser.org>
> Message-ID: <626480.1349.qm(a)web35306.mail.mud.yahoo.com>
> 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 <daniel(a)voice-system.ro>
> 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/
>