sr-users February 2009

sr-users@lists.kamailio.org

76 participants
97 discussions

[Kamailio-Users] SIREMIS feedback
by Elena-Ramona Modroiu 14 Feb '09

14 Feb '09

Hi, it seems that meeting at FOSDEM brought lot of ideas around. Stefan already had a good suggestion - integration of SIREMIS with SEMS giving the possibility to monitor SEMS servers in the same nice manner from a web page. I would like to collect suggestions about what would be good to have in SIREMIS, what should be improved. My goal up to Kamailio 1.5 release is to add support for carrierroute, a cdr rating engine and cleanup the source tree in order to upload the sourceforge svn - this would make easier for others to contribute. However, if it is something we find very useful then I will prioritize. There is time to add new features after the release, as well. Please shoot here any crazy idea you have for a web management interface of Kamailio and later SIP Router. Regards, Ramona

4 7

[Kamailio-Users] UDP packet loss
by Alex R.S.M 13 Feb '09

13 Feb '09

Hi, I am performing SIP to SIP performance testing using Kamailio proxy (UAC-Kamailio-UAC). After increasing the load to 300 calls/sec Kamailio begins dropping UDP packets. (250 cps works fine). CPU utilization and network bandwidth looks fine. I think the bottleneck is the Linux UDP buffer size of the proxy server. Here is the proxy server information: $ uname -a Linux lab-linux01 2.6.24-19-server #1 SMP Wed Jun 18 14:44:47 UTC 2008 x86_64 GNU/Linux $ sudo sysctl -a | grep net.core.rmem_max net.core.rmem_max = 131071 The question is if I increase the linux UDP buffer size do I need to change any configuartion parameter (like MAX_RECV_BUFFER_SIZE) in Kamailio? Thanks, Alex R _________________________________________________________________ Windows Live™: Keep your life in sync. http://windowslive.com/howitworks?ocid=TXT_TAGLM_WL_t1_allup_howitworks_022…

3 6

[Kamailio-Users] Trying to compile openser 1.3.3 without PKG_MALLOC support
by toly 13 Feb '09

13 Feb '09

Greetings, Trying to compile openser 1.3.3 without PKG_MALLOC, just using OS malloc Here's me Makefile.defs DEFS+= $(extra_defs) \ -DNAME='"$(MAIN_NAME)"' -DVERSION='"$(RELEASE)"' -DARCH='"$(ARCH)"' \ -DOS='"$(OS)"' -DCOMPILER='"$(CC_VER)"' -D__CPU_$(ARCH) -D__OS_$(OS) \ -D__SMP_$(ISSMP) -DCFG_DIR='"$(cfg-target)"'\ -DSHM_MEM -DSHM_MMAP \ #-DPKG_MALLOC \ -DUSE_IPV6 \ -DUSE_MCAST \ -DUSE_TCP \ -DDISABLE_NAGLE \ -DHAVE_RESOLV_RES \ -DSTATISTICS \ -DCHANGEABLE_DEBUG_LEVEL \ #-DF_MALLOC \ -DQM_JOIN_FREE \ #-DDBG_QM_MALLOC \ #-DDBG_F_MALLOC \ #-DNO_DEBUG \ #-DNO_LOG \ #-DVQ_MALLOC \ #-DDBG_LOCK \ #-DNOSMP \ #-DEXTRA_DEBUG \ #-DUSE_SHM_MEM It's bailing out compiling blacklists.c blacklists.c: In function `rm_dups': blacklists.c:435: error: syntax error before "else" blacklists.c:440: error: syntax error before "else" blacklists.c: At top level: blacklists.c:443: error: syntax error before "else" blacklists.c:445: warning: type defaults to `int' in declaration of `q' blacklists.c:445: error: invalid type argument of `->' blacklists.c:445: warning: data definition has no type or storage class blacklists.c:446: error: syntax error before '}' token make: *** [blacklists.o] Error 1 Did anybody had a problem compiling openser without pkg_malloc support? I would appreciate any help. TIA Toly. -- View this message in context: http://www.nabble.com/Trying-to-compile-openser-1.3.3-without-PKG_MALLOC-su… Sent from the OpenSER Users Mailing List mailing list archive at Nabble.com.

4 12

[Kamailio-Users] Kernel Message
by Brian Chamberlain 12 Feb '09

12 Feb '09

Hi All, Is this something I should worry about? Feb 12 20:27:22 sw1 kernel: [3273100.087148] INFO: task kamailio:1845 blocked for more than 120 seconds. Feb 12 20:27:22 sw1 kernel: [3273100.087206] "echo 0 > /proc/sys/ kernel/hung_task_timeout_secs" disables this message. Feb 12 20:27:22 sw1 kernel: [3273100.087291] kamailio D 8ce9265a 0 1845 1829 Feb 12 20:27:22 sw1 kernel: [3273100.087346] f6a98da0 00000082 23f7e426 8ce9265a 000701ae f6a98f2c c302bfa0 00000002 Feb 12 20:27:22 sw1 kernel: [3273100.087427] c01344f6 001e17ce 00000001 00000000 c01190e6 f6a98da0 f6a98da0 c02c4dc0 Feb 12 20:27:22 sw1 kernel: [3273100.087538] f74eea84 f74eea8c f74eea88 f6a98da0 c02b8846 f68c3d68 f74eea8c f6a98da0 Feb 12 20:27:22 sw1 kernel: [3273100.087648] Call Trace: Feb 12 20:27:22 sw1 kernel: [3273100.087730] [<c01344f6>] ktime_get +0xd/0x21 Feb 12 20:27:22 sw1 kernel: [3273100.087784] [<c01190e6>] hrtick_start_fair+0xeb/0x12c Feb 12 20:27:22 sw1 kernel: [3273100.087840] [<c02b8846>] __mutex_lock_slowpath+0x50/0x7b Feb 12 20:27:22 sw1 kernel: [3273100.087896] [<c02b86dc>] mutex_lock +0xa/0xb Feb 12 20:27:22 sw1 kernel: [3273100.087945] [<c02a7ea9>] unix_dgram_recvmsg+0x3e/0x245 Feb 12 20:27:22 sw1 kernel: [3273100.087998] [<c01318e9>] autoremove_wake_function+0xd/0x2d Feb 12 20:27:22 sw1 kernel: [3273100.088055] [<c011845d>] __wake_up_common+0x2e/0x58 Feb 12 20:27:22 sw1 kernel: [3273100.088109] [<c024ef76>] sock_recvmsg +0xde/0xf9 Feb 12 20:27:22 sw1 kernel: [3273100.088165] [<c01318dc>] autoremove_wake_function+0x0/0x2d Feb 12 20:27:22 sw1 kernel: [3273100.088223] [<c0117c67>] kunmap_atomic+0x55/0x8a Feb 12 20:27:22 sw1 kernel: [3273100.088273] [<c0117c79>] kunmap_atomic+0x67/0x8a Feb 12 20:27:22 sw1 kernel: [3273100.088327] [<c015ae91>] get_page_from_freelist+0x34f/0x3e3 Feb 12 20:27:22 sw1 kernel: [3273100.088387] [<c024fd9a>] sys_recvfrom +0xb4/0x116 Feb 12 20:27:22 sw1 kernel: [3273100.088438] [<c015b0fb>] __alloc_pages_internal+0xb5/0x34e Feb 12 20:27:22 sw1 kernel: [3273100.088497] [<c0163cd3>] handle_mm_fault+0x257/0x690 Feb 12 20:27:22 sw1 kernel: [3273100.088554] [<c025024d>] sys_socketcall+0x135/0x19e Feb 12 20:27:22 sw1 kernel: [3273100.088610] [<c0103853>] sysenter_past_esp+0x78/0xb1 Feb 12 20:27:22 sw1 kernel: [3273100.091119] [<c02b0000>] acpi_pci_root_add+0x165/0x296 Feb 12 20:27:22 sw1 kernel: [3273100.091174] ======================= Feb 12 20:27:22 sw1 kernel: [3273100.091218] INFO: task kamailio:1846 blocked for more than 120 seconds. Feb 12 20:27:22 sw1 kernel: [3273100.091274] "echo 0 > /proc/sys/ kernel/hung_task_timeout_secs" disables this message. Feb 12 20:27:22 sw1 kernel: [3273100.091358] kamailio D 00000002 0 1846 1829 Feb 12 20:27:22 sw1 kernel: [3273100.091413] f6a995e0 00000086 00000000 00000002 00000000 f6a9976c c3017fa0 00000000 Feb 12 20:27:22 sw1 kernel: [3273100.091495] ffffffff 1d621a39 00000000 00000000 00000000 00000000 00000000 000000ff Feb 12 20:27:22 sw1 kernel: [3273100.091605] f74eea84 f74eea8c f74eea88 f6a995e0 c02b8846 f74eea8c f6b21d68 f6a995e0 Feb 12 20:27:22 sw1 kernel: [3273100.091715] Call Trace: Feb 12 20:27:22 sw1 kernel: [3273100.091790] [<c02b8846>] __mutex_lock_slowpath+0x50/0x7b Feb 12 20:27:22 sw1 kernel: [3273100.091847] [<c02b86dc>] mutex_lock +0xa/0xb Feb 12 20:27:22 sw1 kernel: [3273100.091895] [<c02a7ea9>] unix_dgram_recvmsg+0x3e/0x245 Feb 12 20:27:22 sw1 kernel: [3273100.091949] [<c0129ab0>] lock_timer_base+0x19/0x35 Feb 12 20:27:22 sw1 kernel: [3273100.092002] [<c0129b10>] try_to_del_timer_sync+0x44/0x4a Feb 12 20:27:22 sw1 kernel: [3273100.092057] [<c024ef76>] sock_recvmsg +0xde/0xf9 Feb 12 20:27:22 sw1 kernel: [3273100.092108] [<c01297ec>] process_timeout+0x0/0x5 Feb 12 20:27:22 sw1 kernel: [3273100.092163] [<c01318dc>] autoremove_wake_function+0x0/0x2d Feb 12 20:27:22 sw1 kernel: [3273100.092219] [<c015a0d0>] __rmqueue +0x13/0x174 Feb 12 20:27:22 sw1 kernel: [3273100.092221] [<c0117c67>] kunmap_atomic+0x55/0x8a Feb 12 20:27:22 sw1 kernel: [3273100.092221] [<c0117c79>] kunmap_atomic+0x67/0x8a Feb 12 20:27:22 sw1 kernel: [3273100.092221] [<c015ae91>] get_page_from_freelist+0x34f/0x3e3 Feb 12 20:27:22 sw1 kernel: [3273100.092221] [<c024fd9a>] sys_recvfrom +0xb4/0x116 Feb 12 20:27:22 sw1 kernel: [3273100.092221] [<c015b0fb>] __alloc_pages_internal+0xb5/0x34e Feb 12 20:27:22 sw1 kernel: [3273100.092221] [<c0163cd3>] handle_mm_fault+0x257/0x690 Feb 12 20:27:22 sw1 kernel: [3273100.092221] [<c025024d>] sys_socketcall+0x135/0x19e Feb 12 20:27:22 sw1 kernel: [3273100.092221] [<c0103853>] sysenter_past_esp+0x78/0xb1 Feb 12 20:27:22 sw1 kernel: [3273100.092221] [<c02b0000>] acpi_pci_root_add+0x165/0x296 Feb 12 20:27:22 sw1 kernel: [3273100.092221] ======================= Feb 12 20:27:22 sw1 kernel: [3273100.092221] INFO: task kamailio:22820 blocked for more than 120 seconds. Feb 12 20:27:22 sw1 kernel: [3273100.092221] "echo 0 > /proc/sys/ kernel/hung_task_timeout_secs" disables this message. Feb 12 20:27:22 sw1 kernel: [3273100.092221] kamailio D 854aa937 0 22820 22803 Feb 12 20:27:22 sw1 kernel: [3273100.092221] f762fa40 00000086 2603ada4 854aa937 000767a5 f762fbcc c3021fa0 00000001 Feb 12 20:27:22 sw1 kernel: [3273100.092221] c01344f6 001fcdbd 00000001 00000000 c01190e6 f762fa40 f762fa40 c02c4dc0 Feb 12 20:27:22 sw1 kernel: [3273100.092221] f6b38544 f6b3854c f6b38548 f762fa40 c02b8846 f68a3d68 f6b3854c f762fa40 Feb 12 20:27:22 sw1 kernel: [3273100.092221] Call Trace: Feb 12 20:27:22 sw1 kernel: [3273100.092221] [<c01344f6>] ktime_get +0xd/0x21 Feb 12 20:27:22 sw1 kernel: [3273100.092221] [<c01190e6>] hrtick_start_fair+0xeb/0x12c Feb 12 20:27:22 sw1 kernel: [3273100.092221] [<c02b8846>] __mutex_lock_slowpath+0x50/0x7b Feb 12 20:27:22 sw1 kernel: [3273100.092221] [<c02b86dc>] mutex_lock +0xa/0xb Feb 12 20:27:22 sw1 kernel: [3273100.092274] [<c02a7ea9>] unix_dgram_recvmsg+0x3e/0x245 Feb 12 20:27:22 sw1 kernel: [3273100.092328] [<c01318e9>] autoremove_wake_function+0xd/0x2d Feb 12 20:27:22 sw1 kernel: [3273100.092383] [<c015a05d>] __rmqueue_smallest+0x83/0xe3 Feb 12 20:27:22 sw1 kernel: [3273100.092438] [<c024ef76>] sock_recvmsg +0xde/0xf9 Feb 12 20:27:22 sw1 kernel: [3273100.092493] [<c01318dc>] autoremove_wake_function+0x0/0x2d Feb 12 20:27:22 sw1 kernel: [3273100.092551] [<c0117c67>] kunmap_atomic+0x55/0x8a Feb 12 20:27:22 sw1 kernel: [3273100.092601] [<c0117c79>] kunmap_atomic+0x67/0x8a Feb 12 20:27:22 sw1 kernel: [3273100.092653] [<c015ae91>] get_page_from_freelist+0x34f/0x3e3 Feb 12 20:27:22 sw1 kernel: [3273100.092712] [<c024fd9a>] sys_recvfrom +0xb4/0x116 Feb 12 20:27:22 sw1 kernel: [3273100.092764] [<c015b0fb>] __alloc_pages_internal+0xb5/0x34e Feb 12 20:27:22 sw1 kernel: [3273100.092822] [<c0163cd3>] handle_mm_fault+0x257/0x690 Feb 12 20:27:22 sw1 kernel: [3273100.092881] [<c025024d>] sys_socketcall+0x135/0x19e Feb 12 20:27:22 sw1 kernel: [3273100.092937] [<c0103853>] sysenter_past_esp+0x78/0xb1 Feb 12 20:27:22 sw1 kernel: [3273100.092991] [<c02b0000>] acpi_pci_root_add+0x165/0x296 Feb 12 20:27:22 sw1 kernel: [3273100.093046] ======================= Feb 12 20:27:22 sw1 kernel: [3273100.093090] INFO: task kamailio:22821 blocked for more than 120 seconds. Feb 12 20:27:22 sw1 kernel: [3273100.093146] "echo 0 > /proc/sys/ kernel/hung_task_timeout_secs" disables this message. Feb 12 20:27:22 sw1 kernel: [3273100.093230] kamailio D 8543066c 0 22821 22803 Feb 12 20:27:22 sw1 kernel: [3273100.110119] f762ede0 00000082 2603ada4 8543066c 000767a5 f762ef6c c3017fa0 00000000 Feb 12 20:27:22 sw1 kernel: [3273100.110201] c01344f6 001fcdbd 00000002 00000000 c01190e6 f762ede0 f762ede0 c02c4dc0 Feb 12 20:27:22 sw1 kernel: [3273100.110312] f6b38544 f6b3854c f6b38548 f762ede0 c02b8846 f6b3854c f6bfdd68 f762ede0 Feb 12 20:27:22 sw1 kernel: [3273100.110422] Call Trace: Feb 12 20:27:22 sw1 kernel: [3273100.110493] [<c01344f6>] ktime_get +0xd/0x21 Feb 12 20:27:22 sw1 kernel: [3273100.110543] [<c01190e6>] hrtick_start_fair+0xeb/0x12c Feb 12 20:27:22 sw1 kernel: [3273100.110598] [<c02b8846>] __mutex_lock_slowpath+0x50/0x7b Feb 12 20:27:22 sw1 kernel: [3273100.110653] [<c02b86dc>] mutex_lock +0xa/0xb Feb 12 20:27:22 sw1 kernel: [3273100.110702] [<c02a7ea9>] unix_dgram_recvmsg+0x3e/0x245 Feb 12 20:27:22 sw1 kernel: [3273100.110755] [<c01318e9>] autoremove_wake_function+0xd/0x2d Feb 12 20:27:22 sw1 kernel: [3273100.110810] [<c011845d>] __wake_up_common+0x2e/0x58 Feb 12 20:27:22 sw1 kernel: [3273100.110864] [<c024ef76>] sock_recvmsg +0xde/0xf9 Feb 12 20:27:22 sw1 kernel: [3273100.110919] [<c01318dc>] autoremove_wake_function+0x0/0x2d Feb 12 20:27:22 sw1 kernel: [3273100.110976] [<c0117c67>] kunmap_atomic+0x55/0x8a Feb 12 20:27:22 sw1 kernel: [3273100.111027] [<c0117c79>] kunmap_atomic+0x67/0x8a Feb 12 20:27:22 sw1 kernel: [3273100.111079] [<c015ae91>] get_page_from_freelist+0x34f/0x3e3 Feb 12 20:27:22 sw1 kernel: [3273100.111138] [<c024fd9a>] sys_recvfrom +0xb4/0x116 Feb 12 20:27:22 sw1 kernel: [3273100.111189] [<c015b0fb>] __alloc_pages_internal+0xb5/0x34e Feb 12 20:27:22 sw1 kernel: [3273100.111248] [<c0163cd3>] handle_mm_fault+0x257/0x690 Feb 12 20:27:22 sw1 kernel: [3273100.111307] [<c025024d>] sys_socketcall+0x135/0x19e Feb 12 20:27:22 sw1 kernel: [3273100.111362] [<c0103853>] sysenter_past_esp+0x78/0xb1 Feb 12 20:27:22 sw1 kernel: [3273100.111417] [<c02b0000>] acpi_pci_root_add+0x165/0x296 Feb 12 20:27:22 sw1 kernel: [3273100.111471] =======================

3 12

[Kamailio-Users] SIREMIS v0.9.1 Released
by Elena-Ramona Modroiu 12 Feb '09

12 Feb '09

Hi everybody, a new version, 0.9.1, of SIREMIS - the web management interface for Kamailio (OpenSER) and SIP-Router.org - is released. New features and improvements: * send MI commands to Kamailio (OpenSER) via UDP * display the output of a MI command * ability to predefine MI commands that can be selected from a drop-down menu * create graphic charts from statistic data * one or more charts per page * one or more graphics per chart * now new coding required, only configuration changes required to add new charts * drop-down selection for user AVP type Goals for next version: * carrierroute management * rating engine for CDRs View screenshots of the 0.9.1: http://www.asipto.com/gallery/v/siremis/ Relevant screenshots for new features: - charts: http://www.asipto.com/gallery/v/siremis/siremis_12.jpg.html - MI: http://www.asipto.com/gallery/v/siremis/siremis_15.jpg.html Demo site (it works on a database with random data, no MI; username: admin, password: admin): http://siremis.asipto.com/demo/ Download: http://siremis.asipto.com/pub/downloads/siremis/ Install/Upgrade documentation: http://siremis.asipto.com/install/ Regards, Ramona

3 3

[Kamailio-Users] how to work with Remote-Party-ID ?
by BERGANZ François 12 Feb '09

12 Feb '09

hello, i need to get the Remote-Party-ID in the header. I have that: Remote-Party-ID: "francois bgz" <sip:170725014@217.64.x.x:5067>;screen=yes;privacy=off;party=calling;-call-i nitiator=5016;-call-initiator-location=int;-redirected-by;-int-ext=5016;-ent -name=Acro;-direction=ext;-call-id=55665. I need to have -ent-name=Acro but, when I use $re, I have sip:170725014@217.64.x.x:5067 how can I do ? thank you Cordialement, BERGANZ François P Pensez à l'Environnement, n'imprimez ce mail que si nécessaire.

3 2

Re: [Kamailio-Users] [Kamailio-Devel] SIREMIS v0.9.1 Released
by Elena-Ramona Modroiu 12 Feb '09

12 Feb '09

Hi Stefan, Stefan Sayer wrote: > Hi, > > o Elena-Ramona Modroiu [02/11/09 11:48]: > >> Hi everybody, >> >> a new version, 0.9.1, of SIREMIS - the web management interface for >> Kamailio (OpenSER) and SIP-Router.org - is released. >> > this looks very nice. > thanks! > Just recently I started with some monitoring support for SEMS > (http://lists.iptel.org/pipermail/semsdev/2009-February/003517.html) > The way this works is to push some call related info to the monitoring > module, and access it from the outside via DI functions, e.g. via XMLRPC > (http://svn.berlios.de/wsvn/sems/trunk/doc/Readme.monitoring). So you > can get e.g. a list of callids by executing the XMLRPC function > server.listActive(), and get the info for a call with server.get(callid). > > At the moment it logs ruri/from/to/application/direction in the core, > for conference application additionally the conference room. To > illustrate, you would get this from the server: > >>> s.list() > ['3c2d4bde0d60-gds81g00uz1n'] > >>> s.get(s.list()[0]) > [{'from': '"2(a)stefan-lap.office.iptego.de" > <sip:2@stefan-lap.office.iptego.de>', 'app': 'conference', 'to': > '<sip:35@stefan-lap.office.iptego.de;user=phone>', 'conf_id': '35', > 'ruri': 'sip:35@stefan-lap.office.iptego.de;user=phone', 'dir': 'in'}] > > This is of course extensible, e.g. codec used, call start/end time etc. > > Maybe, if we would add a way to monitor SEMS servers from within > SIREMIS, it would give a good opportunity to monitor e.g. conference > bridge, voicemail server, prepaid app, or b2bua (like sbc). > > What do you think? > I think it would be very useful. It looks to me more like an extension to communicate via XMLRPC with SEMS - send command and display the result. What is the XMLRPC you are using in SEMS? The C library used in Kamailio proved quite unstable, therefore SIREMIS uses MI UDP - simpler protocol and easy to troubleshoot. There should be XMLRPC PHP lib, therefore easy to extend SIREMIS. Is it possible to get statistic information out of SEMS? Like number of active calls? Such data can be used to build charts, which is nice to monitor the service health and evolution. Regards, Ramona

2 2

[Serusers] Forking Proxy
by Amanda Mattiuz 12 Feb '09

12 Feb '09

Hello all, Is is possible to configure SER to act as a forking proxy, where the INVITE messages that arrive at the server are forwarded to multiple clients ins parallel? I saw something about call hunt, but it seems that the INVITES are sent sequentially, could I make it become concurrently? Thanks, Amanda

2 1

[Kamailio-Users] IP SEC tunel
by ALAEDDINE abbech 11 Feb '09

11 Feb '09

hi, How can i do a tunel (use IP SEC)whith my serveur openser. is there a code to write to the configuration file to do this. thanks __________________________________________________________________________________________________ Ne pleurez pas si votre Webmail ferme ! Récupérez votre historique sur Yahoo! Mail ! http://fr.docs.yahoo.com/mail/transfert_mails.html

2 1

[Kamailio-Users] Kamilio Failover Options
by Stagg Shelton 11 Feb '09

11 Feb '09

I am looking for some ideas on how to create a more redundant setup in my operation. About 60 days ago our openser 1.3.2 system started sending out 500 errors. Looking through the log file I found alot of ERROR:tm:new_t: out of mem that corresponded to the INVITES. A simple restart of openser freed the memory and calls processed normally as expected. Since then we have upgraded to openser 1.3.3 and haven't experienced the problem since. Currently I am testing kamilio 1.4.3 and planning my migration into kamilio from openser. What I would like to create is a system that has two kamailio systems where one can fail to the other in the event of an application error that prevents calls from processing. Does anyone have any suggestions on implementing a redundant kamilio system, or can point me in the direction of where to start reading and researching. Thanks Stagg Shelton www.3pconnect.com

3 2

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

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 February 2009