[Users] Re: Users Digest, Vol 23, Issue 97

wangdq at gongye.com.cn wangdq at gongye.com.cn
Tue May 1 10:20:54 CEST 2007


 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 at openser.org写道:
> Send Users mailing list submissions to
> 	users at 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 at openser.org
> 
> You can reach the person managing the list at
> 	users-owner at 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 at pernau.at>
> Subject: Re: [Users] memory leak in presence module?
> To: daniel at voice-system.ro
> Cc: "users openser.org" <users at openser.org>
> Message-ID: <4635F067.6070006 at 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 at 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 at 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 at 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 at 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 at gmail.com>
> Subject: [Users] rtpproxy CPU usage issue..
> To: users at openser.org
> Message-ID: <4635F995.3020908 at 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 at webrainstorm.it>
> Subject: [Users] Dropped calls with OpenSER 1.1.x and Asterisk >=
> 	1.2.14 
> To: users at openser.org
> Message-ID: <f14udl$s9t$1 at 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 at yahoo.com.mx>
> Subject: Re: [Users] Redirect the same INVITE to the SIP SERVER from
> 	Balancer?
> To: daniel at voice-system.ro
> Cc: openser openser <users at openser.org>
> Message-ID: <626480.1349.qm at 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 at 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 at 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/ 
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: pruebasNoSincroP.cap
> Type: application/octet-stream
> Size: 13773 bytes
> Desc: 3505796577-pruebasNoSincroP.cap
> Url : http://openser.org/pipermail/users/attachments/20070430/7e9a7cc2/pruebasNoSincroP.obj
> 
> ------------------------------
> 
> _______________________________________________
> Users mailing list
> Users at openser.org
> http://openser.org/cgi-bin/mailman/listinfo/users
> 
> 
> End of Users Digest, Vol 23, Issue 97
> *************************************
> 
-- 
wangdq at gongye.com.cn <wangdq at gongye.com.cn>
gongye.com.cn





More information about the sr-users mailing list