[Users] Re: Users Digest, Vol 23, Issue 97 - sr-users

1 May 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@openser.org写道：
...
Send Users mailing list submissions to
   users@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@openser.org
You can reach the person managing the list at
   users-owner@openser.org
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Users digest..."
Today's Topics:

Re: memory leak in presence module? (Klaus Darilion)
rtpproxy CPU usage issue.. (Sajith T S)
Dropped calls with OpenSER 1.1.x and Asterisk >= 1.2.14 
(Edoardo Serra)
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@pernau.at
Subject: Re: [Users] memory leak in presence module?
To: daniel@voice-system.ro
Cc: "users openser.org" users@openser.org
Message-ID: 4635F067.6070006@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@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@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@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@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@gmail.com
Subject: [Users] rtpproxy CPU usage issue..
To: users@openser.org
Message-ID: 4635F995.3020908@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@webrainstorm.it
Subject: [Users] Dropped calls with OpenSER 1.1.x and Asterisk >=
   1.2.14 
To: users@openser.org
Message-ID: f14udl$s9t$1@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@yahoo.com.mx
Subject: Re: [Users] Redirect the same INVITE to the SIP SERVER from
   Balancer?
To: daniel@voice-system.ro
Cc: openser openser users@openser.org
Message-ID: 626480.1349.qm@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@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@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/