sr-users

sr-users@lists.kamailio.org

42 participants
37549 discussions

[Users] typo error in acc_mod.c
by Helmut Kuper 24 Apr '07

24 Apr '07

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, there is a typo error in acc_mod.c replace line 222 ({"acc_totag_column", STR_PARAM, &acc_totag_col },) with ({"acc_to_tag_column", STR_PARAM, &acc_totag_col },) this will make modparam acc_to_tag_column work. Alternatively u can use acc_totag_column in openser.cfg as modparam name. regard Helmut -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGLeMz4tZeNddg3dwRAhhHAJ9eeXdpVfWc/SxPnMl7AZPV1NzvGACdEKIv JTj1E8XYptFYPB0HG4K92Jw= =DudI -----END PGP SIGNATURE-----

2 1

[Users] FIFO chmod
by Joao Pereira 24 Apr '07

24 Apr '07

Hello My serweb needs the FIFO to be with writing permissions: prwxrwxrwx 1 root root 0 Apr 23 23:23 /tmp/openser_fifo But every time I reload Openser, the openser_fifo permissions dont allow serweb to use the FIFO. In the old SER I did: fifo_mode=0666 But this doesn't work in OpenSER Is there any similar command in Openser? Thanks Regards Joao Pereira

2 1

[Users] ACC module, always prints message for successful transaction
by Tim Madorma 24 Apr '07

24 Apr '07

Hi, I would rather not have a syslog message for successful transactions - just failed ones. I have set the appropriate flags for the transactions that I would like to see: my settings are: modparam("acc", "log_level", 2) modparam("acc", "log_flag", 1) modparam("acc","report_cancels", 1) modparam("acc","failed_transaction_flag", 1) But in my syslog, I get a log entry for every successful transaction - such as: Apr 23 13:54:12 homer openser[17280]: [ID 729047 local0.notice] ACC: transaction answered: timestamp=1177350852;method=INVITE;from_t ag=188229;to_tag=6110;call_id=188229-14338(a)65.185.233.183;code=200;reason=OK How do I stop ACC from logging for successful transactions? thanks, Tim

2 1

[Serusers] SER + RTPproxy with video
by roayu 24 Apr '07

24 Apr '07

Good day! I'm a newbie on SER. I had configured a SER server running with RTPproxy. I'm using SER v0.9.6 and RTPproxy Basic Version 20040107. It works fine with the audio but not for the video. From what i understand that this version of rtpproxy do support both audio and video. I had trace the message header of SDP and it seems fine. I'm not sure what caused this happended. Could you pls guide me on this? Thanks. Regards, Roa

1 0

Re: [Users] memory issues
by Daniel-Constantin Mierla 23 Apr '07

23 Apr '07

Hello, daily snapshots are enabled now for 1.2.x as well: http://www.openser.org/downloads/snapshots/openser-1.2.x/ Cheers, Daniel On 04/23/07 17:47, Ovidiu Sas wrote: > Hi Tim, > > Check the download page from openser website: > http://www.openser.org/mos/view/Download/: > > The command that you need to run: > svn co http://openser.svn.sourceforge.net/svnroot/openser/branches/1.2 > openser > > Make sure that you have svn installed. > > > Regards, > Ovidiu Sas > > On 4/23/07, Tim Madorma <tmadorma(a)gmail.com> wrote: >> Hi Daniel, >> >> I have run into a leak in 1.2 and I assume it is the same one that >> Ovidiu ran into. I see in your response that it was "backported to >> 1.2", but I'm not sure how to get the fix. When I look at the SVN >> repository at: >> http://www.openser.org/pub/openser/latest-1.2.x/, the date is earlier >> than the date of your email exchange so I don't think the fix has been >> added there. Can you please let me know how I can get it? >> >> thanks, >> Tim >> >> On 3/23/07, Daniel-Constantin Mierla <daniel(a)voice-system.ro> wrote: >> > Hello Ovidiu, >> > >> > On 03/23/07 17:04, Ovidiu Sas wrote: >> > > Hi Daniel, >> > > >> > > Can we backport this one to 1.2? >> > already done, two minutes after the commit in trunk. >> > >> > Cheers, >> > Daniel >> > >> > > >> > > >> > > Regards, >> > > Ovidiu Sas >> > > >> > > On 3/22/07, Daniel-Constantin Mierla <daniel(a)voice-system.ro> wrote: >> > >> Hello, >> > >> >> > >> the supposed fragmentation turned out to be a mem leak in pkg. >> Please >> > >> take the latest SVN version and try again to see if you got same >> > >> results. >> > >> >> > >> Thanks, >> > >> Daniel >> > >> >> > >> On 03/19/07 18:52, Christian Schlatter wrote: >> > >> > ... >> > >> >>> The memory statistics indeed show a high number of memory >> fragments: >> > >> >>> >> > >> >>> before 'out of memory': >> > >> >>> >> > >> >>> shmem:total_size = 536870912 >> > >> >>> shmem:used_size = 59607040 >> > >> >>> shmem:real_used_size = 60106488 >> > >> >>> shmem:max_used_size = 68261536 >> > >> >>> shmem:free_size = 476764424 >> > >> >>> shmem:fragments = 9897 >> > >> >>> >> > >> >>> after 'out of memory' (about 8000 calls per process): >> > >> >>> >> > >> >>> shmem:total_size = 536870912 >> > >> >>> shmem:used_size = 4171160 >> > >> >>> shmem:real_used_size = 4670744 >> > >> >>> shmem:max_used_size = 68261536 >> > >> >>> shmem:free_size = 532200168 >> > >> >>> shmem:fragments = 57902 >> > >> >>> >> > >> >>>> >> > >> >>>> You can try to compile openser with -DQM_JOIN_FREE (add it >> in DEFS >> > >> >>>> variable of Makefile.defs) and test again. Free fragments >> should be >> > >> >>>> merged and fragmentation should not occur -- processing >> will be >> > >> >>>> slower. We will try for next release to provide a better >> solution >> > >> >>>> for that. >> > >> >>> >> > >> >>> Compiling openser with -DQM_JOIN_FREE did not help. I'm not >> sure how >> > >> >>> big of a problem this fragmentation issue is. >> > >> >> What is the number of fragments with QM_JOIN_FREE after >> flooding? >> > >> > >> > >> > The numbers included above are with QM_JOIN_FREE enabled. >> > >> > >> > >> >>> Do you think it would make sense to restart our production >> openser >> > >> >>> instances from time to time just to make sure they're not >> running >> > >> >>> into this memory fragmentation limits? >> > >> >> The issue will occur only when the call rate reaches the >> limits of >> > >> >> the proxy's memory. Otherwise the chunks are reused. >> Transactions and >> > >> >> avps are rounded up to be sure there will be minimized the >> number of >> > >> >> different sizes for memory chunks. It wasn't reported too often, >> > >> >> maybe that's why no big attention was paid to it. This memory >> system >> > >> >> is in place since the beginning of ser. Alternative is to use >> sysv >> > >> >> shared memory, but is much slower, along with libc private >> memory >> > >> >> manager. >> > >> > >> > >> > I've done some more testing and the same out-of-memory stuff >> happens >> > >> > when I run sipp with 10 calls per second only. I tested with >> > >> > 'children=1' and I only could get through about 8200 calls (again >> > >> > those 8000 calls / process). And this is with QM_JOIN_FREE >> enabled. >> > >> > >> > >> > Memory statistics: >> > >> > >> > >> > before: >> > >> > shmem:total_size = 536870912 >> > >> > shmem:used_size = 2311976 >> > >> > shmem:real_used_size = 2335720 >> > >> > shmem:max_used_size = 2465816 >> > >> > shmem:free_size = 534535192 >> > >> > shmem:fragments = 183 >> > >> > >> > >> > after: >> > >> > shmem:total_size = 536870912 >> > >> > shmem:used_size = 1853472 >> > >> > shmem:real_used_size = 1877224 >> > >> > shmem:max_used_size = 2465816 >> > >> > shmem:free_size = 534993688 >> > >> > shmem:fragments = 547 >> > >> > >> > >> > So I'm not sure if this is really a fragmentation issue. 10 >> cps surely >> > >> > doesn't reach the proxy's memory. >> > >> > >> > >> > Thoughts? >> > >> > >> > >> > Christian >> > >> > >> > >> > >> > >> > >> > >> >> Cheers, >> > >> >> Daniel >> > >> >> >> > >> >>> >> > >> >>> thanks, >> > >> >>> Christian >> > >> >>> >> > >> >>>> >> > >> >>>> Cheers, >> > >> >>>> Daniel >> > >> >>>> >> > >> >>>> On 03/18/07 01:21, Christian Schlatter wrote: >> > >> >>>>> Christian Schlatter wrote: >> > >> >>>>> ... >> > >> >>>>>> >> > >> >>>>>> I always had 768MB shared memory configured though, so I >> still >> > >> >>>>>> can't explain the memory allocation errors I got. Some >> more test >> > >> >>>>>> runs revealed that I only get these errors when using a more >> > >> >>>>>> production oriented config that loads more modules than >> the one >> > >> >>>>>> posted in my earlier email. I now try to figure out what >> exactly >> > >> >>>>>> causes these memory allocation errors that happen >> reproducibly >> > >> >>>>>> after about 220s at 400 cps. >> > >> >>>>> >> > >> >>>>> I think I found the cause for the memory allocation >> errors. As >> > >> >>>>> soon as I include an AVP write operation in the routing >> script, I >> > >> >>>>> get 'out of memory' messages after a certain number of calls >> > >> >>>>> generated with sipp. >> > >> >>>>> >> > >> >>>>> The routing script to reproduce this behavior looks like >> (full >> > >> >>>>> config available at >> > >> >>>>> http://www.unc.edu/~cschlatt/openser/openser.cfg): >> > >> >>>>> >> > >> >>>>> route{ >> > >> >>>>> $avp(s:ct) = $ct; # commenting this line solves >> > >> >>>>> # the memory problem >> > >> >>>>> >> > >> >>>>> if (!method=="REGISTER") record_route(); >> > >> >>>>> if (loose_route()) route(1); >> > >> >>>>> >> > >> >>>>> if (uri==myself) rewritehost("xx.xx.xx.xx"); >> > >> >>>>> route(1); >> > >> >>>>> } >> > >> >>>>> >> > >> >>>>> route[1] { >> > >> >>>>> if (!t_relay()) sl_reply_error(); >> > >> >>>>> exit; >> > >> >>>>> } >> > >> >>>>> >> > >> >>>>> An example log file showing the 'out of memory' messages is >> > >> >>>>> available at >> http://www.unc.edu/~cschlatt/openser/openser.log . >> > >> >>>>> >> > >> >>>>> Some observations: >> > >> >>>>> >> > >> >>>>> - The 'out of memory' messages always appear after about >> 8000 test >> > >> >>>>> calls per worker process. One call consists of two SIP >> > >> >>>>> transactions and six end-to-end SIP messages. An openser >> with 8 >> > >> >>>>> children handles about 64'000 calls, whereas 4 children only >> > >> >>>>> handle about 32'000 calls. The sipp call rate doesn't >> matter, only >> > >> >>>>> number of calls. >> > >> >>>>> >> > >> >>>>> - The 8000 calls per worker process are independent from the >> > >> >>>>> amount of shared memory available. Running openser with -m >> 128 or >> > >> >>>>> -m 768 does not make a difference. >> > >> >>>>> >> > >> >>>>> - The more AVP writes are done in the script, the less >> calls go >> > >> >>>>> through. It looks like each AVP write is leaking memory >> (unnoticed >> > >> >>>>> by the memory statistics). >> > >> >>>>> >> > >> >>>>> - The fifo memory statistics do not reflect the 'out of >> memory' >> > >> >>>>> syslog messages. Even if openser does not route a single SIP >> > >> >>>>> message because of memory issues, the statistics still >> show a lot >> > >> >>>>> of 'free' memory. >> > >> >>>>> >> > >> >>>>> >> > >> >>>>> All tests were done with openser SVN 1.2 branch on Ubuntu >> dapper >> > >> >>>>> x86. I think the same is true for 1.1 version but I >> haven't tested >> > >> >>>>> that yet. >> > >> >>>>> >> > >> >>>>> >> > >> >>>>> Christian >> > >> >>>>> >> > >> >>> >> > >> >>> >> > >> > >> > >> > >> > >> > _______________________________________________ >> > >> > Users mailing list >> > >> > Users(a)openser.org >> > >> > http://openser.org/cgi-bin/mailman/listinfo/users >> > >> > >> > >> >> > >> _______________________________________________ >> > >> Users mailing list >> > >> Users(a)openser.org >> > >> http://openser.org/cgi-bin/mailman/listinfo/users >> > >> >> > > >> > >> > _______________________________________________ >> > Users mailing list >> > Users(a)openser.org >> > http://openser.org/cgi-bin/mailman/listinfo/users >> > >> >

3 4

[Serusers] Mediaproxy sip-asymmetric-clients
by Ali Zaidi 23 Apr '07

23 Apr '07

Hi, I have been using ser with mediaproxy for more than a year without any major issue. I have couple of asymmetric UAs, and i'm not able to call them most of the time. i noticed in my ser.cfg following lines. My ser.cfg =========================== modparam("mediaproxy","sip_asymmetrics","/usr/local/etc/ser/sip-clients") modparam("mediaproxy","rtp_asymmetrics","/usr/local/etc/ser/rtp-clients") # modparam("mediaproxy","sip_asymmetrics","/usr/local/etc/ser/sip-asymmetric-clients") # modparam("mediaproxy","rtp_asymmetrics","/usr/local/etc/ser/rtp-asymmetric-clients") =========================== I have above files in ser folder, and i tried to put user agent in sip-clients file, i don't know if i'm doing it right. Ii'm still trying to figure it out, what should i put in these sip-clients and rtp-clients files (username? URI ), and how do i know if they are working. I just put UA 5007860215 and restarted ser and mediaproxy but ngrep are same. my sip-clients file is as follows: ########### START ################## # Lines starting with a '#' character or empty lines are ignored. # Put a User-Agent name or regular expression per line. # Check is case insensitive. # # This file should only list SIP clients that are asymmetric regarding # the SIP signaling. For clients that are asymmetric regarding the RTP # media streams, use the equivalent RTP version of this file. # Clients that are asymmetric for both SIP signaling as well as RTP media # streams should go in both files. # ipDialog SipTone.* #<== what is it? 5007860215 ########### END OF FILE############ client sending keep alive message, reason i setup keep alive on my client is becouse they were keep loosing registration, so that problem is solved. Following asymentric client coming through port 50005 and SER sending reply at port 5060. ################# U XX.XX.55.170:50005 -> XX.XX.66.231:5060 NOTIFY sip:ser.mydomain.com SIP/2.0..Via: SIP/2.0/UDP 192.168.1.25:5060;branch=z9hG4bK-2173a014..From: Tony < sip:5007860215@ser.mydomain.com>;tag=a11c95e2a205caa8o0..To: <sip: ser.mydomain.com>..Call-ID: 9b70d42-e62ebac8(a)192.168.1. 25..CSeq: 4043 NOTIFY..Max-Forwards: 70..Event: keep-alive..User-Agent: Sipura/SPA1001- 3.1.8(SEc)..Content-Length: 0. ... # U XX.XX.66.231:5060 -> XX.XX.55.170:5060 SIP/2.0 404 User Not Found..Via: SIP/2.0/UDP 192.168.1.25:5060 ;branch=z9hG4bK-ceived=XX.XX.55.170..From: Tony <sip:5007860215@ser.mydomain.com>;tag=a11c95e2a205caa8o0..To: <sip:ser.mydomain.com>;tag=e4b88024d5465a32af4d4d872ac6bb61.0ce2..Call-ID: 9b70d42-e62ebac8@192.168.1.25..CSeq: 4043 NOTIFY..Server: Sip EXpress router (0.9.5-pre4 (i386/linux))..Content-Length: 0..Warning: 392 ser.mydomain.com:5060"Noisy feedback tells: pid=14718 req_src_ip= 70.18.55.170 req_src_port=50005 in_uri=sip:ser.mydomain.com out_uri=sip: ser.mydomain.com via_cnt==1".... ################ If i ping my UA with (serctl ping sip:5007860208@ser.mydomain.com) i get following ngrep. It appears that SER has no problem reaching UA at port 50005. ################### U XX.XX.66.231:5060 -> XX.XX.55.170:50005 OPTIONS sip:5007860215@192.168.1.25:5060 SIP/2.0..Max-Forwards: 10..Record-Route: <sip:XX.XX.66.231;ftag=887df13cdb9661be5c6769ac08d69940-385f;lr=on>..Via: SIP/2.0/UDP XX.XX.66.231;branch=z9hG4bK88b5.16ac1512.0..Via: SIP/2.0/UDP 67.83.66.231;branch=z9hG4bK88b5.06ac1512.0..To: <sip:5007860215@ser.igranet.com >..From: sip:daemon@ool-435342e7.covad.net;tag=887df13cdb9661be5c6769ac08d69940-385f..CSeq: 10 OPTIONS..Call-ID: 7effbd40-0@XX.XX.66.231..Content-Length: 0..User-Agent: Sip EXpress router(0.9.5-pre4 (i386/linux))..Contact:< sip:daemon@XX.XX.66.231:5060>.... # U XX.XX.55.170:50005 -> XX.XX.66.231:5060 SIP/2.0 200 OK..To: < sip:5007860215@ser.igranet.com>;tag=8b659eab4f39640i0..From: sip:daemon@ool-435342e7.covad.net;tag=887df13cdb9661be5c6769ac08d69940-385f..Call-ID: 7effbd40-0@XX.XX.66.231..CSeq: 10 OPTIONS..Via: SIP/2.0/UD P XX.XX.66.231;branch=z9hG4bK88b5.16ac1512.0..Via: SIP/2.0/UDP XX.XX.66.231;branch=z9hG4bK88b5.06ac1512.0..Record-Rou te: <sip:XX.XX.66.231;ftag=887df13cdb9661be5c6769ac08d69940-385f;lr=on>..Server: Sipura/SPA1001-3.1.8(SEc)..Content-L ength: 0..Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER..Supported: x-sipura.... ################## please help... Ali....

2 3

[Users] MediaProxy Scenario
by Edson 23 Apr '07

23 Apr '07

Hi... I have two questions (well, three): 1a) How should Mediaproxy be configured so to permit a call interruption? 1b) Is there any external interface that permit communications with the Mediaproxy process? 2) How can a call (RTP traffic) be recorded with MediaProxy? Any format... Edson. ------ "It wouldn't be sell if it were easy..."

1 0

[Users] Openser with unixODBC + sqlite driver
by Sylvain Boily 23 Apr '07

23 Apr '07

Hi, I would like to connect openser 1.2 to sqlite db with unixodbc. I have installed unixodbc et sqlite driver and i configure openser.cfg but it doesn't working. I seems the configuration wants user:password@ip but for sqlite there no need this. I have testing lot off configuration but it doesn't work. My configuration and log : File /etc/odbc.ini [mysqlitedb] Description = SQLite Driver = SQLite Database = /tmp/mytest.db Timeout = 100000 StepAPI = No NoWCHAR = No LongNames = No File /etc/odbcinst.ini [SQLite] Description = SQLite ODBC Driver Driver = /usr/lib/odbc/libsqliteodbc.so Setup = /usr/lib/odbc/libsqliteodbc.so UsageCount = 1 File /etc/openser/openser.cfg loadmodule "unixodbc.so" loadmodule "auth.so" loadmodule "auth_db.so" modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo") modparam("usrloc", "db_mode", 2) modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password") modparam("rr", "enable_full_lr", 1) modparam("usrloc|auth_db", "db_url","unixodbc://SQLite/mysqlitedb") My log : Apr 21 13:33:25 sylvain-desktop /usr/sbin/openser[24539]: AUTH module - initializing Apr 21 13:33:25 sylvain-desktop /usr/sbin/openser[24539]: AUTH_DB module - initializing Apr 21 13:33:25 sylvain-desktop /usr/sbin/openser[24539]: ERROR:unixodbc:new_connection: failed to connect Apr 21 13:33:25 sylvain-desktop /usr/sbin/openser[24539]: register_udomain(): Can not open database connection Apr 21 13:33:25 sylvain-desktop /usr/sbin/openser[24539]: domain_fixup(): Error while registering domain Apr 21 13:33:25 sylvain-desktop /usr/sbin/openser[24539]: ERROR: fix_actions: fixing failed (code=-1) at cfg line 148 Apr 21 13:33:25 sylvain-desktop /usr/sbin/openser[24539]: INFO:mi_fifo:mi_destroy: process hasn't been created -> nothing to kill Thank for your help. Sylvain

3 4

[Serusers] IMPORTANT: Invitation to discuss the management of iptel.org
by Greger V. Teigre 23 Apr '07

23 Apr '07

Dear all, The way decisions has been made for SER and iptel.org is not explicitly described anywhere. In fact, there has not really been an official policy for how to make decisions. The consequence has been that some decisions have come out of consensus on the mailing lists (normally the developer mailing lists), some have come out of developers/individuals doing something they believe in and nobody has objected, and finally, in some areas, a small group of people have had private discussions before doing something. The truth is that for a casual observer (on a user mailing list) it has been hard to understand how (and why) iptel.org projects move forward. It is also easy to get to the wrong conclusions and iptel.org has suffered from this lack of transparency. Over the last year we have worked to make such processes more transparent and predictable. We have focused on development and development decisions and have tried to encourage discussions on the mailing lists, as well as to create wishlists and (starting) roadmaps (see iptel.org website for these). However, we have not addressed management issues like how to solve conflicts where no consensus can be reached and so on. Jan (Janak) raised this issue during the Prague Developer Workshop where 18 people participated. I will below try to summarize what we had agreement on and what was decided. In order to make sure this is accurate, several participants with different views have reviewed this post before sending it on the mailing lists. (enclosed in objective tags) <objective> Principles agreed to (but up for discussion in the spirit of IETF): 1. We want discussions on the mailing lists and consensus when making decisions 2. We don't want a lot of bureaucracy that sounds nice, but that we don't need. This includes how to resolve all sorts of issues 3. In general, we trust people (that is individuals, not companies) who are most knowledgeable and most involved to make good decisions on our behalf. Hence, contributors should have more to say in the areas they contribute (ex. module developers) 4. We want to avoid "do-nothing" decisions, for example if everybody agrees, but one person says no, or people are split in two camps Decisions made (but up for discussion on the mailing lists in the spirit of IETF): * Discussions should be held on the developer mailing lists and no formal voting process should be used * If discussions just continue and no consensus can be reached, we want a small technical board (TB) to have the authority to make the decision on behalf of the community * This board should be elected by the community in an open election process * The technical board (TB) should also have the authority to decide how to resolve issues if there are no obvious precedence from earlier cases * The TB should be elected by the community for a pre-defined period * The TB should focus on issues related to day-to-day development of the projects, but should not manage on a day-to-day basis, just convene if there are issues that could not be resolved by consensus </objective> I try here to identify open issues not discussed/decided: * Should there be one TB for all iptel.org projects or one TB for each? * What should be the criteria for selecting people on the TB (if any)? * Who have voting rights when we vote on candidates for the TB? * What should be the term for a TB member? * Should this TB handle any issues beyond development? (ex. website content, iptel.org in the wider SIP context, relationship with other projects, packaging, longer-term positioning of projects, longer-term development goals, and so on) * If not, do we need another group that could handle such things? Best regards, Greger

9 10

Re: [Users] memory issues
by Daniel-Constantin Mierla 23 Apr '07

23 Apr '07

please keep cc-ing to mailing list so other users can get the response in case they have same questions, avoiding waste of time to solve same issue. Thanks, Daniel On 04/23/07 18:46, Tim Madorma wrote: > Great - thanks Daniel! > > On 4/23/07, Daniel-Constantin Mierla <daniel(a)voice-system.ro> wrote: >> Hello Tim, >> >> On 04/23/07 18:36, Tim Madorma wrote: >> > Hey Daniel, >> > >> > When I looked at the ChangeLog, it does not seem to indicate that the >> > fix is there. >> > >> > >> http://openser.svn.sourceforge.net/svnroot/openser/branches/1.2/ChangeLog >> >> ChangeLog is usually left behind and updated just before the release. >> > >> > Should I be concerned about this? >> No >> > Should I just use the daily snapshot >> > instead? How stable is the daily snapshot? >> Daily snapshot is more or less what SVN 1.2 branch shows at the moment >> when the snapshot is done. So using SVN will guarantee the access to >> latest stable code. Snapshots and SVN of branch 1.2 should be the most >> stable in the 1.2.x release. There are no other commits to branch 1.2 >> but bug fixes. >> >> We publish daily snapshots just as backup when SVN is not available, >> otherwise SVN is advisable to use if you can use subversion. >> >> Cheers, >> Daniel >> > >> > Tim >> > >> > >> > On 4/23/07, Daniel-Constantin Mierla <daniel(a)voice-system.ro> wrote: >> >> Hello, >> >> >> >> daily snapshots are enabled now for 1.2.x as well: >> >> >> >> http://www.openser.org/downloads/snapshots/openser-1.2.x/ >> >> >> >> Cheers, >> >> Daniel >> >> >> >> On 04/23/07 17:47, Ovidiu Sas wrote: >> >> > Hi Tim, >> >> > >> >> > Check the download page from openser website: >> >> > http://www.openser.org/mos/view/Download/: >> >> > >> >> > The command that you need to run: >> >> > svn co >> http://openser.svn.sourceforge.net/svnroot/openser/branches/1.2 >> >> > openser >> >> > >> >> > Make sure that you have svn installed. >> >> > >> >> > >> >> > Regards, >> >> > Ovidiu Sas >> >> > >> >> > On 4/23/07, Tim Madorma <tmadorma(a)gmail.com> wrote: >> >> >> Hi Daniel, >> >> >> >> >> >> I have run into a leak in 1.2 and I assume it is the same one that >> >> >> Ovidiu ran into. I see in your response that it was "backported to >> >> >> 1.2", but I'm not sure how to get the fix. When I look at the SVN >> >> >> repository at: >> >> >> http://www.openser.org/pub/openser/latest-1.2.x/, the date is >> earlier >> >> >> than the date of your email exchange so I don't think the fix has >> >> been >> >> >> added there. Can you please let me know how I can get it? >> >> >> >> >> >> thanks, >> >> >> Tim >> >> >> >> >> >> On 3/23/07, Daniel-Constantin Mierla <daniel(a)voice-system.ro> >> wrote: >> >> >> > Hello Ovidiu, >> >> >> > >> >> >> > On 03/23/07 17:04, Ovidiu Sas wrote: >> >> >> > > Hi Daniel, >> >> >> > > >> >> >> > > Can we backport this one to 1.2? >> >> >> > already done, two minutes after the commit in trunk. >> >> >> > >> >> >> > Cheers, >> >> >> > Daniel >> >> >> > >> >> >> > > >> >> >> > > >> >> >> > > Regards, >> >> >> > > Ovidiu Sas >> >> >> > > >> >> >> > > On 3/22/07, Daniel-Constantin Mierla <daniel(a)voice-system.ro> >> >> wrote: >> >> >> > >> Hello, >> >> >> > >> >> >> >> > >> the supposed fragmentation turned out to be a mem leak in >> pkg. >> >> >> Please >> >> >> > >> take the latest SVN version and try again to see if you >> got same >> >> >> > >> results. >> >> >> > >> >> >> >> > >> Thanks, >> >> >> > >> Daniel >> >> >> > >> >> >> >> > >> On 03/19/07 18:52, Christian Schlatter wrote: >> >> >> > >> > ... >> >> >> > >> >>> The memory statistics indeed show a high number of memory >> >> >> fragments: >> >> >> > >> >>> >> >> >> > >> >>> before 'out of memory': >> >> >> > >> >>> >> >> >> > >> >>> shmem:total_size = 536870912 >> >> >> > >> >>> shmem:used_size = 59607040 >> >> >> > >> >>> shmem:real_used_size = 60106488 >> >> >> > >> >>> shmem:max_used_size = 68261536 >> >> >> > >> >>> shmem:free_size = 476764424 >> >> >> > >> >>> shmem:fragments = 9897 >> >> >> > >> >>> >> >> >> > >> >>> after 'out of memory' (about 8000 calls per process): >> >> >> > >> >>> >> >> >> > >> >>> shmem:total_size = 536870912 >> >> >> > >> >>> shmem:used_size = 4171160 >> >> >> > >> >>> shmem:real_used_size = 4670744 >> >> >> > >> >>> shmem:max_used_size = 68261536 >> >> >> > >> >>> shmem:free_size = 532200168 >> >> >> > >> >>> shmem:fragments = 57902 >> >> >> > >> >>> >> >> >> > >> >>>> >> >> >> > >> >>>> You can try to compile openser with -DQM_JOIN_FREE >> (add it >> >> >> in DEFS >> >> >> > >> >>>> variable of Makefile.defs) and test again. Free >> fragments >> >> >> should be >> >> >> > >> >>>> merged and fragmentation should not occur -- processing >> >> >> will be >> >> >> > >> >>>> slower. We will try for next release to provide a better >> >> >> solution >> >> >> > >> >>>> for that. >> >> >> > >> >>> >> >> >> > >> >>> Compiling openser with -DQM_JOIN_FREE did not help. >> I'm not >> >> >> sure how >> >> >> > >> >>> big of a problem this fragmentation issue is. >> >> >> > >> >> What is the number of fragments with QM_JOIN_FREE after >> >> >> flooding? >> >> >> > >> > >> >> >> > >> > The numbers included above are with QM_JOIN_FREE enabled. >> >> >> > >> > >> >> >> > >> >>> Do you think it would make sense to restart our >> production >> >> >> openser >> >> >> > >> >>> instances from time to time just to make sure they're not >> >> >> running >> >> >> > >> >>> into this memory fragmentation limits? >> >> >> > >> >> The issue will occur only when the call rate reaches the >> >> >> limits of >> >> >> > >> >> the proxy's memory. Otherwise the chunks are reused. >> >> >> Transactions and >> >> >> > >> >> avps are rounded up to be sure there will be minimized the >> >> >> number of >> >> >> > >> >> different sizes for memory chunks. It wasn't reported too >> >> often, >> >> >> > >> >> maybe that's why no big attention was paid to it. This >> memory >> >> >> system >> >> >> > >> >> is in place since the beginning of ser. Alternative is >> to use >> >> >> sysv >> >> >> > >> >> shared memory, but is much slower, along with libc private >> >> >> memory >> >> >> > >> >> manager. >> >> >> > >> > >> >> >> > >> > I've done some more testing and the same out-of-memory >> stuff >> >> >> happens >> >> >> > >> > when I run sipp with 10 calls per second only. I tested >> with >> >> >> > >> > 'children=1' and I only could get through about 8200 calls >> >> (again >> >> >> > >> > those 8000 calls / process). And this is with QM_JOIN_FREE >> >> >> enabled. >> >> >> > >> > >> >> >> > >> > Memory statistics: >> >> >> > >> > >> >> >> > >> > before: >> >> >> > >> > shmem:total_size = 536870912 >> >> >> > >> > shmem:used_size = 2311976 >> >> >> > >> > shmem:real_used_size = 2335720 >> >> >> > >> > shmem:max_used_size = 2465816 >> >> >> > >> > shmem:free_size = 534535192 >> >> >> > >> > shmem:fragments = 183 >> >> >> > >> > >> >> >> > >> > after: >> >> >> > >> > shmem:total_size = 536870912 >> >> >> > >> > shmem:used_size = 1853472 >> >> >> > >> > shmem:real_used_size = 1877224 >> >> >> > >> > shmem:max_used_size = 2465816 >> >> >> > >> > shmem:free_size = 534993688 >> >> >> > >> > shmem:fragments = 547 >> >> >> > >> > >> >> >> > >> > So I'm not sure if this is really a fragmentation issue. 10 >> >> >> cps surely >> >> >> > >> > doesn't reach the proxy's memory. >> >> >> > >> > >> >> >> > >> > Thoughts? >> >> >> > >> > >> >> >> > >> > Christian >> >> >> > >> > >> >> >> > >> > >> >> >> > >> > >> >> >> > >> >> Cheers, >> >> >> > >> >> Daniel >> >> >> > >> >> >> >> >> > >> >>> >> >> >> > >> >>> thanks, >> >> >> > >> >>> Christian >> >> >> > >> >>> >> >> >> > >> >>>> >> >> >> > >> >>>> Cheers, >> >> >> > >> >>>> Daniel >> >> >> > >> >>>> >> >> >> > >> >>>> On 03/18/07 01:21, Christian Schlatter wrote: >> >> >> > >> >>>>> Christian Schlatter wrote: >> >> >> > >> >>>>> ... >> >> >> > >> >>>>>> >> >> >> > >> >>>>>> I always had 768MB shared memory configured though, >> so I >> >> >> still >> >> >> > >> >>>>>> can't explain the memory allocation errors I got. Some >> >> >> more test >> >> >> > >> >>>>>> runs revealed that I only get these errors when using >> >> a more >> >> >> > >> >>>>>> production oriented config that loads more modules >> than >> >> >> the one >> >> >> > >> >>>>>> posted in my earlier email. I now try to figure out >> what >> >> >> exactly >> >> >> > >> >>>>>> causes these memory allocation errors that happen >> >> >> reproducibly >> >> >> > >> >>>>>> after about 220s at 400 cps. >> >> >> > >> >>>>> >> >> >> > >> >>>>> I think I found the cause for the memory allocation >> >> >> errors. As >> >> >> > >> >>>>> soon as I include an AVP write operation in the routing >> >> >> script, I >> >> >> > >> >>>>> get 'out of memory' messages after a certain number of >> >> calls >> >> >> > >> >>>>> generated with sipp. >> >> >> > >> >>>>> >> >> >> > >> >>>>> The routing script to reproduce this behavior looks >> like >> >> >> (full >> >> >> > >> >>>>> config available at >> >> >> > >> >>>>> http://www.unc.edu/~cschlatt/openser/openser.cfg): >> >> >> > >> >>>>> >> >> >> > >> >>>>> route{ >> >> >> > >> >>>>> $avp(s:ct) = $ct; # commenting this line solves >> >> >> > >> >>>>> # the memory problem >> >> >> > >> >>>>> >> >> >> > >> >>>>> if (!method=="REGISTER") record_route(); >> >> >> > >> >>>>> if (loose_route()) route(1); >> >> >> > >> >>>>> >> >> >> > >> >>>>> if (uri==myself) rewritehost("xx.xx.xx.xx"); >> >> >> > >> >>>>> route(1); >> >> >> > >> >>>>> } >> >> >> > >> >>>>> >> >> >> > >> >>>>> route[1] { >> >> >> > >> >>>>> if (!t_relay()) sl_reply_error(); >> >> >> > >> >>>>> exit; >> >> >> > >> >>>>> } >> >> >> > >> >>>>> >> >> >> > >> >>>>> An example log file showing the 'out of memory' >> >> messages is >> >> >> > >> >>>>> available at >> >> >> http://www.unc.edu/~cschlatt/openser/openser.log . >> >> >> > >> >>>>> >> >> >> > >> >>>>> Some observations: >> >> >> > >> >>>>> >> >> >> > >> >>>>> - The 'out of memory' messages always appear after >> about >> >> >> 8000 test >> >> >> > >> >>>>> calls per worker process. One call consists of two SIP >> >> >> > >> >>>>> transactions and six end-to-end SIP messages. An >> openser >> >> >> with 8 >> >> >> > >> >>>>> children handles about 64'000 calls, whereas 4 children >> >> only >> >> >> > >> >>>>> handle about 32'000 calls. The sipp call rate doesn't >> >> >> matter, only >> >> >> > >> >>>>> number of calls. >> >> >> > >> >>>>> >> >> >> > >> >>>>> - The 8000 calls per worker process are independent >> >> from the >> >> >> > >> >>>>> amount of shared memory available. Running openser >> with -m >> >> >> 128 or >> >> >> > >> >>>>> -m 768 does not make a difference. >> >> >> > >> >>>>> >> >> >> > >> >>>>> - The more AVP writes are done in the script, the less >> >> >> calls go >> >> >> > >> >>>>> through. It looks like each AVP write is leaking memory >> >> >> (unnoticed >> >> >> > >> >>>>> by the memory statistics). >> >> >> > >> >>>>> >> >> >> > >> >>>>> - The fifo memory statistics do not reflect the 'out of >> >> >> memory' >> >> >> > >> >>>>> syslog messages. Even if openser does not route a >> >> single SIP >> >> >> > >> >>>>> message because of memory issues, the statistics still >> >> >> show a lot >> >> >> > >> >>>>> of 'free' memory. >> >> >> > >> >>>>> >> >> >> > >> >>>>> >> >> >> > >> >>>>> All tests were done with openser SVN 1.2 branch on >> Ubuntu >> >> >> dapper >> >> >> > >> >>>>> x86. I think the same is true for 1.1 version but I >> >> >> haven't tested >> >> >> > >> >>>>> that yet. >> >> >> > >> >>>>> >> >> >> > >> >>>>> >> >> >> > >> >>>>> Christian >> >> >> > >> >>>>> >> >> >> > >> >>> >> >> >> > >> >>> >> >> >> > >> > >> >> >> > >> > >> >> >> > >> > _______________________________________________ >> >> >> > >> > Users mailing list >> >> >> > >> > Users(a)openser.org >> >> >> > >> > http://openser.org/cgi-bin/mailman/listinfo/users >> >> >> > >> > >> >> >> > >> >> >> >> > >> _______________________________________________ >> >> >> > >> Users mailing list >> >> >> > >> Users(a)openser.org >> >> >> > >> http://openser.org/cgi-bin/mailman/listinfo/users >> >> >> > >> >> >> >> > > >> >> >> > >> >> >> > _______________________________________________ >> >> >> > Users mailing list >> >> >> > Users(a)openser.org >> >> >> > http://openser.org/cgi-bin/mailman/listinfo/users >> >> >> > >> >> >> >> >> > >> >> >> > >> >

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users