sr-users

sr-users@lists.kamailio.org

13 participants
37464 discussions

[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

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

23 Apr '07

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

[Users] how to refresh REGISTER state when restarting redundant proxy
by Alan Crosswell 23 Apr '07

23 Apr '07

We are using t_replicate() to replicate REGISTERs among redundant proxies (and a separate presence server that needs REGISTER for pua_bla). Before reinventing the wheel here, I thought I'd ask if others already have a method in place to re-sync a restarted proxy's state? I guess one way is to pull the usrloc data from mysql.... Another would be to somehow ask the proxy to walk the usrloc table and do a bunch of t_registers()... Any thoughts appreciated. /a

9 25

[Users] question about ACK
by Papadopoulos Georgios 23 Apr '07

23 Apr '07

Hello all, In the following call to PSTN, Openser gets into an infinite loop when the ACK is received. It starts sending the ACK to itself. Is this because the ACK is not right or could it be a misconfiguration in my part? thank you for any help George # U 2007/04/18 13:44:46.759951 213.5.17.223:5058 -> 213.5.43.4:5060 INVITE sip:2116873831@sip.altecnet.gr:5060 SIP/2.0. Max-Forwards: 70. Content-Length: 378. Via: SIP/2.0/UDP 213.5.17.223:5058;branch=z9hG4bK08349b43d. Call-ID: 91a3a06767e6d11c4a62a583078d95fb(a)213.5.17.223. From: demo1 <sip:demo1@sip.altecnet.gr:5060>;tag=299ad500d129e32. To: 2116873831 <sip:2116873831@sip.altecnet.gr:5060>. CSeq: 424044974 INVITE. Supported: 100rel. Supported: timer. Allow: NOTIFY, REFER, OPTIONS, INVITE, ACK, CANCEL, BYE. Content-Type: application/sdp. Supported: replaces. Proxy-Authorization:Digest response="87bc0f48f292fa5213368434f8712c39",username="demo1",realm="alte cnet.gr",nonce="4625f7cabd05f0720edd9ab601211b1759066235",uri="sip:21168 73831@sip.altecnet.gr:5060". Contact: demo1 <sip:demo1@213.5.17.223:5058>. User-Agent: Brcm-Callctrl/v1.7.1.1 MxSF/v3.6.2.5. . v=0. o=MxSIP 0 1153034350 IN IP4 213.5.17.223. s=SIP Call. c=IN IP4 213.5.17.223. t=0 0. m=audio 57994 RTP/AVP 8 0 97 98 109 99 4 18. a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:97 G726-16/8000. a=rtpmap:98 G726-24/8000. a=rtpmap:109 G726-32/8000. a=rtpmap:99 G726-40/8000. a=rtpmap:4 G723/8000. a=rtpmap:18 G729/8000. a=ptime:20. a=sendrecv. a=silenceSupp:on - - - -. # U 2007/04/18 13:44:46.764816 213.5.43.4:5060 -> 213.5.17.223:5058 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 213.5.17.223:5058;branch=z9hG4bK08349b43d;rport=5058. Call-ID: 91a3a06767e6d11c4a62a583078d95fb(a)213.5.17.223. From: demo1 <sip:demo1@sip.altecnet.gr:5060>;tag=299ad500d129e32. To: 2116873831 <sip:2116873831@sip.altecnet.gr:5060>. CSeq: 424044974 INVITE. Server: OpenSer (1.1.1-notls (i386/linux)). Content-Length: 0. . # U 2007/04/18 13:44:46.764967 213.5.43.4:5060 -> 213.5.1.6:5060 INVITE sip:400#2116873831@213.5.1.6:5060 SIP/2.0. Record-Route: <sip:213.5.43.4;lr=on;ftag=299ad500d129e32>. Max-Forwards: 69. Content-Length: 378. Via: SIP/2.0/UDP 213.5.43.4;branch=z9hG4bKb455.b4c98796.0. Via: SIP/2.0/UDP 213.5.17.223:5058;rport=5058;branch=z9hG4bK08349b43d. Call-ID: 91a3a06767e6d11c4a62a583078d95fb(a)213.5.17.223. From: demo1 <sip:demo1@sip.altecnet.gr:5060>;tag=299ad500d129e32. To: 2116873831 <sip:2116873831@sip.altecnet.gr:5060>. CSeq: 424044974 INVITE. Supported: 100rel. Supported: timer. Allow: NOTIFY, REFER, OPTIONS, INVITE, ACK, CANCEL, BYE. Content-Type: application/sdp. Supported: replaces. Contact: demo1 <sip:demo1@213.5.17.223:5058>. User-Agent: Brcm-Callctrl/v1.7.1.1 MxSF/v3.6.2.5. . v=0. o=MxSIP 0 1153034350 IN IP4 213.5.17.223. s=SIP Call. c=IN IP4 213.5.17.223. t=0 0. m=audio 57994 RTP/AVP 8 0 97 98 109 99 4 18. a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:97 G726-16/8000. a=rtpmap:98 G726-24/8000. a=rtpmap:109 G726-32/8000. a=rtpmap:99 G726-40/8000. a=rtpmap:4 G723/8000. a=rtpmap:18 G729/8000. a=ptime:20. a=sendrecv. a=silenceSupp:on - - - -. # U 2007/04/18 13:44:46.781896 213.5.1.6:5060 -> 213.5.43.4:5060 SIP/2.0 100 Trying. Via: SIP/2.0/UDP 213.5.43.4;branch=z9hG4bKb455.b4c98796.0,SIP/2.0/UDP 213.5.17.223:5058;rport=5058;branch=z9hG4bK08349b43d. From: demo1 <sip:demo1@sip.altecnet.gr:5060>;tag=299ad500d129e32. To: 2116873831 <sip:2116873831@sip.altecnet.gr:5060>;tag=4C655430-F57. Date: Wed, 18 Apr 2007 10:44:46 GMT. Call-ID: 91a3a06767e6d11c4a62a583078d95fb(a)213.5.17.223. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 424044974 INVITE. Allow-Events: telephone-event. Content-Length: 0. . # U 2007/04/18 13:44:46.913667 213.5.1.6:5060 -> 213.5.43.4:5060 SIP/2.0 183 Session Progress. Via: SIP/2.0/UDP 213.5.43.4;branch=z9hG4bKb455.b4c98796.0,SIP/2.0/UDP 213.5.17.223:5058;rport=5058;branch=z9hG4bK08349b43d. From: demo1 <sip:demo1@sip.altecnet.gr:5060>;tag=299ad500d129e32. To: 2116873831 <sip:2116873831@sip.altecnet.gr:5060>;tag=4C655430-F57. Date: Wed, 18 Apr 2007 10:44:46 GMT. Call-ID: 91a3a06767e6d11c4a62a583078d95fb(a)213.5.17.223. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 424044974 INVITE. Require: 100rel. RSeq: 1883. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER. Allow-Events: telephone-event. Contact: <sip:400#2116873831@213.5.1.6:5060>. Record-Route: <sip:213.5.43.4;lr=on;ftag=299ad500d129e32>. Content-Disposition: session;handling=required. Content-Type: application/sdp. Content-Length: 232. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7897 3551 IN IP4 213.5.1.6. s=SIP Call. c=IN IP4 213.5.1.6. t=0 0. m=audio 19140 RTP/AVP 18. c=IN IP4 213.5.1.6. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=ptime:40. a=silenceSupp:off - - - -. # U 2007/04/18 13:44:46.914048 213.5.43.4:5060 -> 213.5.17.223:5058 SIP/2.0 183 Session Progress. Via: SIP/2.0/UDP 213.5.17.223:5058;rport=5058;branch=z9hG4bK08349b43d. From: demo1 <sip:demo1@sip.altecnet.gr:5060>;tag=299ad500d129e32. To: 2116873831 <sip:2116873831@sip.altecnet.gr:5060>;tag=4C655430-F57. Date: Wed, 18 Apr 2007 10:44:46 GMT. Call-ID: 91a3a06767e6d11c4a62a583078d95fb(a)213.5.17.223. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 424044974 INVITE. Require: 100rel. RSeq: 1883. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER. Allow-Events: telephone-event. Contact: <sip:400#2116873831@213.5.1.6:5060>. Record-Route: <sip:213.5.43.4;lr=on;ftag=299ad500d129e32>. Content-Disposition: session;handling=required. Content-Type: application/sdp. Content-Length: 232. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7897 3551 IN IP4 213.5.1.6. s=SIP Call. c=IN IP4 213.5.1.6. t=0 0. m=audio 19140 RTP/AVP 18. c=IN IP4 213.5.1.6. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=ptime:40. a=silenceSupp:off - - - -. # U 2007/04/18 13:44:47.413787 213.5.1.6:5060 -> 213.5.43.4:5060 SIP/2.0 183 Session Progress. Via: SIP/2.0/UDP 213.5.43.4;branch=z9hG4bKb455.b4c98796.0,SIP/2.0/UDP 213.5.17.223:5058;rport=5058;branch=z9hG4bK08349b43d. From: demo1 <sip:demo1@sip.altecnet.gr:5060>;tag=299ad500d129e32. To: 2116873831 <sip:2116873831@sip.altecnet.gr:5060>;tag=4C655430-F57. Date: Wed, 18 Apr 2007 10:44:46 GMT. Call-ID: 91a3a06767e6d11c4a62a583078d95fb(a)213.5.17.223. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 424044974 INVITE. Require: 100rel. RSeq: 1883. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER. Allow-Events: telephone-event. Contact: <sip:400#2116873831@213.5.1.6:5060>. Record-Route: <sip:213.5.43.4;lr=on;ftag=299ad500d129e32>. Content-Disposition: session;handling=required. Content-Type: application/sdp. Content-Length: 232. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7897 3551 IN IP4 213.5.1.6. s=SIP Call. c=IN IP4 213.5.1.6. t=0 0. m=audio 19140 RTP/AVP 18. c=IN IP4 213.5.1.6. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=ptime:40. a=silenceSupp:off - - - -. # U 2007/04/18 13:44:47.414278 213.5.43.4:5060 -> 213.5.17.223:5058 SIP/2.0 183 Session Progress. Via: SIP/2.0/UDP 213.5.17.223:5058;rport=5058;branch=z9hG4bK08349b43d. From: demo1 <sip:demo1@sip.altecnet.gr:5060>;tag=299ad500d129e32. To: 2116873831 <sip:2116873831@sip.altecnet.gr:5060>;tag=4C655430-F57. Date: Wed, 18 Apr 2007 10:44:46 GMT. Call-ID: 91a3a06767e6d11c4a62a583078d95fb(a)213.5.17.223. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 424044974 INVITE. Require: 100rel. RSeq: 1883. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER. Allow-Events: telephone-event. Contact: <sip:400#2116873831@213.5.1.6:5060>. Record-Route: <sip:213.5.43.4;lr=on;ftag=299ad500d129e32>. Content-Disposition: session;handling=required. Content-Type: application/sdp. Content-Length: 232. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7897 3551 IN IP4 213.5.1.6. s=SIP Call. c=IN IP4 213.5.1.6. t=0 0. m=audio 19140 RTP/AVP 18. c=IN IP4 213.5.1.6. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=ptime:40. a=silenceSupp:off - - - -. # U 2007/04/18 13:44:48.413460 213.5.1.6:5060 -> 213.5.43.4:5060 SIP/2.0 183 Session Progress. Via: SIP/2.0/UDP 213.5.43.4;branch=z9hG4bKb455.b4c98796.0,SIP/2.0/UDP 213.5.17.223:5058;rport=5058;branch=z9hG4bK08349b43d. From: demo1 <sip:demo1@sip.altecnet.gr:5060>;tag=299ad500d129e32. To: 2116873831 <sip:2116873831@sip.altecnet.gr:5060>;tag=4C655430-F57. Date: Wed, 18 Apr 2007 10:44:46 GMT. Call-ID: 91a3a06767e6d11c4a62a583078d95fb(a)213.5.17.223. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 424044974 INVITE. Require: 100rel. RSeq: 1883. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER. Allow-Events: telephone-event. Contact: <sip:400#2116873831@213.5.1.6:5060>. Record-Route: <sip:213.5.43.4;lr=on;ftag=299ad500d129e32>. Content-Disposition: session;handling=required. Content-Type: application/sdp. Content-Length: 232. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7897 3551 IN IP4 213.5.1.6. s=SIP Call. c=IN IP4 213.5.1.6. t=0 0. m=audio 19140 RTP/AVP 18. c=IN IP4 213.5.1.6. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=ptime:40. a=silenceSupp:off - - - -. # U 2007/04/18 13:44:48.413952 213.5.43.4:5060 -> 213.5.17.223:5058 SIP/2.0 183 Session Progress. Via: SIP/2.0/UDP 213.5.17.223:5058;rport=5058;branch=z9hG4bK08349b43d. From: demo1 <sip:demo1@sip.altecnet.gr:5060>;tag=299ad500d129e32. To: 2116873831 <sip:2116873831@sip.altecnet.gr:5060>;tag=4C655430-F57. Date: Wed, 18 Apr 2007 10:44:46 GMT. Call-ID: 91a3a06767e6d11c4a62a583078d95fb(a)213.5.17.223. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 424044974 INVITE. Require: 100rel. RSeq: 1883. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER. Allow-Events: telephone-event. Contact: <sip:400#2116873831@213.5.1.6:5060>. Record-Route: <sip:213.5.43.4;lr=on;ftag=299ad500d129e32>. Content-Disposition: session;handling=required. Content-Type: application/sdp. Content-Length: 232. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7897 3551 IN IP4 213.5.1.6. s=SIP Call. c=IN IP4 213.5.1.6. t=0 0. m=audio 19140 RTP/AVP 18. c=IN IP4 213.5.1.6. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=ptime:40. a=silenceSupp:off - - - -. # U 2007/04/18 13:44:48.582989 213.5.1.6:5060 -> 213.5.43.4:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 213.5.43.4;branch=z9hG4bKb455.b4c98796.0,SIP/2.0/UDP 213.5.17.223:5058;rport=5058;branch=z9hG4bK08349b43d. From: demo1 <sip:demo1@sip.altecnet.gr:5060>;tag=299ad500d129e32. To: 2116873831 <sip:2116873831@sip.altecnet.gr:5060>;tag=4C655430-F57. Date: Wed, 18 Apr 2007 10:44:46 GMT. Call-ID: 91a3a06767e6d11c4a62a583078d95fb(a)213.5.17.223. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 424044974 INVITE. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER. Allow-Events: telephone-event. Contact: <sip:400#2116873831@213.5.1.6:5060>. Record-Route: <sip:213.5.43.4;lr=on;ftag=299ad500d129e32>. Content-Type: application/sdp. Content-Length: 232. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7897 3551 IN IP4 213.5.1.6. s=SIP Call. c=IN IP4 213.5.1.6. t=0 0. m=audio 19140 RTP/AVP 18. c=IN IP4 213.5.1.6. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=ptime:40. a=silenceSupp:off - - - -. # U 2007/04/18 13:44:48.583304 213.5.43.4:5060 -> 213.5.17.223:5058 SIP/2.0 200 OK. Via: SIP/2.0/UDP 213.5.17.223:5058;rport=5058;branch=z9hG4bK08349b43d. From: demo1 <sip:demo1@sip.altecnet.gr:5060>;tag=299ad500d129e32. To: 2116873831 <sip:2116873831@sip.altecnet.gr:5060>;tag=4C655430-F57. Date: Wed, 18 Apr 2007 10:44:46 GMT. Call-ID: 91a3a06767e6d11c4a62a583078d95fb(a)213.5.17.223. Server: Cisco-SIPGateway/IOS-12.x. CSeq: 424044974 INVITE. Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, COMET, REFER, SUBSCRIBE, NOTIFY, INFO, UPDATE, REGISTER. Allow-Events: telephone-event. Contact: <sip:400#2116873831@213.5.1.6:5060>. Record-Route: <sip:213.5.43.4;lr=on;ftag=299ad500d129e32>. Content-Type: application/sdp. Content-Length: 232. . v=0. o=CiscoSystemsSIP-GW-UserAgent 7897 3551 IN IP4 213.5.1.6. s=SIP Call. c=IN IP4 213.5.1.6. t=0 0. m=audio 19140 RTP/AVP 18. c=IN IP4 213.5.1.6. a=rtpmap:18 G729/8000. a=fmtp:18 annexb=no. a=ptime:40. a=silenceSupp:off - - - -. # U 2007/04/18 13:44:48.718798 213.5.17.223:5058 -> 213.5.43.4:5060 ACK sip:2116873831@sip.altecnet.gr:5060 SIP/2.0. Max-Forwards: 70. Content-Length: 0. Via: SIP/2.0/UDP 213.5.17.223:5058;branch=z9hG4bKd1e7e81f7. Call-ID: 91a3a06767e6d11c4a62a583078d95fb(a)213.5.17.223. From: demo1 <sip:demo1@sip.altecnet.gr:5060>;tag=299ad500d129e32. To: 2116873831 <sip:2116873831@sip.altecnet.gr:5060>;tag=4C655430-F57. Route: <sip:213.5.43.4;lr=on;ftag=299ad500d129e32>. CSeq: 424044974 ACK. Proxy-Authorization:Digest response="87bc0f48f292fa5213368434f8712c39",username="demo1",realm="alte cnet.gr",nonce="4625f7cabd05f0720edd9ab601211b1759066235",uri="sip:21168 73831@sip.altecnet.gr:5060". User-Agent: Brcm-Callctrl/v1.7.1.1 MxSF/v3.6.2.5. . # U 2007/04/18 13:44:48.719303 213.5.43.4:5060 -> 213.5.43.4:5060 ACK sip:213.5.43.4;lr=on;ftag=299ad500d129e32 SIP/2.0. Record-Route: <sip:213.5.43.4;lr=on;ftag=299ad500d129e32>. Max-Forwards: 69. Content-Length: 0. Via: SIP/2.0/UDP 213.5.43.4;branch=z9hG4bKb455.b4c98796.2. Via: SIP/2.0/UDP 213.5.17.223:5058;rport=5058;branch=z9hG4bKd1e7e81f7. Call-ID: 91a3a06767e6d11c4a62a583078d95fb(a)213.5.17.223. From: demo1 <sip:demo1@sip.altecnet.gr:5060>;tag=299ad500d129e32. To: 2116873831 <sip:2116873831@sip.altecnet.gr:5060>;tag=4C655430-F57. CSeq: 424044974 ACK. Proxy-Authorization:Digest response="87bc0f48f292fa5213368434f8712c39",username="demo1",realm="alte cnet.gr",nonce="4625f7cabd05f0720edd9ab601211b1759066235",uri="sip:21168 73831@sip.altecnet.gr:5060". User-Agent: Brcm-Callctrl/v1.7.1.1 MxSF/v3.6.2.5. P-hint: rr-enforced. . Disclaimer The information in this e-mail and any attachments is confidential. It is intended solely for the attention and use of the named addressee(s). If you are not the intended recipient, or person responsible for delivering this information to the intended recipient, please notify the sender immediately. Unless you are the intended recipient or his/her representative you are not authorized to, and must not, read, copy, distribute, use or retain this message or any part of it. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.

2 1

Re: [Users] Re: Multiple invites
by venkatesh.d 23 Apr '07

23 Apr '07

hi ravi prakash, route[1] { append_branch("sip:C@xx:xx:xx:xx"); t_relay(); } above will work .but i have not enable nat routing in this .when i enabled nat routing with media proxy same problem i am facing raviprakash sunkara wrote: > Hi Klaus , > Thanks for replying , > > if(method=="INVITE" && uri=~"sip:B@xx.xxx.xx ") > { > setuser("C"); > append_branch() > t_relay(); > }; > > The B's Information is override by C , But Call goes to C , only, > > When A invites B, then B and C has ring parallel. > > On 4/23/07, Klaus Darilion <klaus.mailinglists(a)pernau.at> wrote: > > Take a look at append_branch(). (core documentation) > > regards > klaus > > raviprakash sunkara wrote: > > Hello Users, > > > > For My Sip Servicing, There is Call Hunting Features > > > > This had done , When I forwarded the Asterisk Server. > > But I want to implements in OpenSER itself, > > > > When A Calls to B, the proxy has to send to invites to B and C, So that B > > and C rings simultaneously > > > > >

1 0

[Users] Multiple invites
by raviprakash sunkara 23 Apr '07

23 Apr '07

Hello Users, For My Sip Servicing, There is Call Hunting Features This had done , When I forwarded the Asterisk Server. But I want to implements in OpenSER itself, When A Calls to B, the proxy has to send to invites to B and C, So that B and C rings simultaneously -- Thanks and Regards Ravi Prakash Sunkara ravi.sunkara(a)hyperion-tech.com M:+91 9985077535 www.hyperion-tech.com Client and Parent company :- www.august-networks.com

2 3

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