sr-users

sr-users@lists.kamailio.org

1 participants
37563 discussions

Why Kamailio reply with null compression method when TLS handshake?
by 刘日新 13 May '14

13 May '14

Hi, all. I has set up a Kamailio server with TLS & compression enabled, I thought I set most things suitable , I has set modparam("tls","tls_disable_compression",0) I can find such log records as below when Kamailio boost: 0(10905) INFO: tls [tls_init.c:549]: init_tls_h(): tls: _init_tls_h: compiled with openssl version "OpenSSL 1.0.0-fips 29 Mar 2010" (0x10000003), kerberos support: on, compression: on 0(10905) INFO: tls [tls_init.c:557]: init_tls_h(): tls: init_tls_h: installed openssl library version "OpenSSL 1.0.0-fips 29 Mar 2010" (0x10000003), kerberos support: on, zlib compression: on compiler: gcc -fPIC -DOPENSSL_PIC -DZLIB -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -DKRB5_MIT -m64 -DL_ENDIAN -DTERMIO -Wall -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -Wa,--noexecstack -DMD32_REG_T=int -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DMD5_ASM -DAES_ASM -DWHIRLPOOL_ASM 0(10905) WARNING: tls [tls_init.c:611]: init_tls_h(): tls: openssl bug #1491 (crash/mem leaks on low memory) workaround enabled (on low memory tls operations will fail preemptively) with free memory thresholds 11534336 and 5767168 bytes 0(10905) INFO: <core> [cfg/cfg_ctx.c:613]: cfg_set_now(): INFO: cfg_set_now(): tls.low_mem_threshold1 has been changed to 11534336 0(10905) INFO: <core> [cfg/cfg_ctx.c:613]: cfg_set_now(): INFO: cfg_set_now(): tls.low_mem_threshold2 has been changed to 5767168 And I run kamcmd tls.options, I got: { force_run: 0 method: TLSv1 verify_certificate: 0 verify_depth: 9 require_certificate: 0 private_key: /ca/cert.pem ca_list: certificate: /ca/cert.pem cipher_list: session_cache: 1 session_id: vic22 config: /etc/kamailio/tls.cfg log: 3 debug: 3 connection_timeout: 600 disable_compression: 0 ssl_release_buffers: -1 ssl_freelist_max: -1 ssl_max_send_fragment: -1 ssl_read_ahead: 0 send_close_notify: 0 low_mem_threshold1: 11534336 low_mem_threshold2: 5767168 ct_wq_max: 10485760 con_ct_wq_max: 65536 ct_wq_blk_size: 4096 } But when My UA connect to this server, when TLS handshake, I can find that the clienthello with two compression method :1 (deflate) and 0 (null), but the server side reply with just one compression method: 0( null), thus the compression was disabled through the following communication. Why? are there any others issue can impact the behavior of Kamailio? Any hints will be appreciated. B.R. Rixin liu

1 0

Children, PKG_MEM and IMS
by Andrea Meroni 13 May '14

13 May '14

Hi all, i'm a little bit confused about the #children/PKG_MEM mechanism: in my setup (a simple IMS core with one P-CSCF, one I-CSCF, one dispatcher and 2 S-CSCFs) i wish to manage the highest possible #calls, but i don't know which is the ideal setup. I mean, i'm running all this components in VMs (with mem = 2048MB and smp = 8) inside a desktop machine with RAM = 32 GB and 8 processors; is it worth to define #children = #processors and setting an high value of PKG_MEM (for example 128MB) or use an higher #children (for example 64) with less PKG_MEM (for example 16MB)? Someone could explain me better how the mechanism works? Thank you, Andrea

1 0

Version support
by Jan Gaida 12 May '14

12 May '14

Hello, Which versions of Kamailio (OpenSER) are officially supported (e.g. actively patched) ? Is there a list of EOL dates for all versions or what is the general rule? Kind regards Jan -- *Jan **Gaida* Ingeniero Desarrollo Software C/ Marconi 3 (PTM) 28760 Tres Cantos Spain jan.gaida(a)grupoamper.com | www.grupoamper.com -- This message and any attachments are intended only for the use of the individual to whom they are addressed and it may contain information that is privileged or confidential. If you have received this communication by mistake, please notify us immediately by e-mail or telephone.The storage, recording, use or disclosure of this e-mail and its attachments by anyone other than the intended recipient is strictly prohibited. This message has been verified using antivirus software; however, the sender is not responsible for any damage to hardware or software resulting from the presence of any virus. Este mensaje y cualquier anexo son exclusivamente para la persona a quien van dirigidos y pueden contener información privilegiada o confidencial. Si usted ha recibido esta comunicación por error, le agradecemos notificarlo de inmediato por esta misma vía o por teléfono. Está prohibida su retención, grabación, utilización o divulgación con cualquier propósito. Este mensaje ha sido verificado con software antivirus; sin embargo, el remitente no se hace responsable en caso de que en éste o en los archivos adjuntos haya presencia de algún virus que pueda generar daños en los equipos o programas del destinatario.

2 1

Problem with rtpproxy and rtpproxy_manage()
by aft 12 May '14

12 May '14

Hi, I'm using kamailio from latest git-HEAD. The rtpproxy i'm using also from latest git. Our network topology is following : sip-softphone--------->kamailio/rtpproxy-------->softswitch---->gateway Because of saving bandwidth we need to use the "re-packetization" feature of rtpproxy. When we don't use it, it works perfectly without any glitches. Now if we use the repacketization feature like following : if (is_request()) { rtpproxy_manage("co"); } if (is_reply()) { rtpproxy_manage("z80"); } Then a bizzare thing happens. Suddenly rtp packets from gateway stops coming. So we don't have any voice in softphone, although everything seems ok at the "mobile phone's end." This is bizzare at multiple levels, as you can see we are using repacketize feature to increase the payload size from "proxy to softphone" leg. So we actually don't touch the packets from "softphone to proxy" leg. So how the gateway predicts this and decides not to send packets is beyond my understanding. As far as i can understand, rtpproxy_manage() is doing something to SDP which makes it impossible to send packets through the proxy. I will provide further information if anybody wants to look at it. Thanks in advance. -- -Cheers -Arif

2 5

Kamailio stopped, but kamctl online still get user info
by Eirc 12 May '14

12 May '14

Hello, all of users: I am confused here, my kamalio is stopped, but kamctl online and ul show still can see the user info: ============================================ root@kamailio:/home/admin_1# kamctl online 102 root@kamailio:/home/admin_1# kamctl online 102 root@kamailio:/home/admin_1# kamctl online 102 root@kamailio:/home/admin_1# service kamailio status Status of Kamailio: kamailio is not running. root@kamailio:/home/admin_1# kamctl ul show Domain:: location table=512 records=1 max_slot=1 AOR:: 102 Contact:: sip:102@192.168.1.105:5060 Q= Expires:: 313 Callid:: 363490571-5060-1(a)BJC.BGI.B.BAF Cseq:: 2117 User-agent:: Grandstream GXP2124 1.0.4.10 State:: CS_SYNC Flags:: 0 Cflag:: 0 Socket:: udp:192.168.1.116:5060 Methods:: 7135 Ruid:: uloc-536d9a68-6a5-1 Instance:: <urn:uuid:00000000-0000-1000-8000-000B824017A0> Reg-Id:: 1 root@kamailio:/home/admin_1# ========================================== Does kamctl only receive the data from mysql, no matter kamctl status? -- *Best regards*

2 1

Kamailio Logged in users
by Neville D'Souza 12 May '14

12 May '14

Hi, I am having a slight issue with Kamilio server. How do I disconnect users without restarting the server. When I run the command kamctl ul users i get the list of users connected, some that are already disconnected. I am using the Linphone android client to coonect through 5060 port. Kindly advise Best Regards, Neville D'Souza Network Administrator r_gogopay_96x73 Gogopay Online Pvt Ltd. India +91 832 222 0119 ncd(a)gogopay.com www.gogopay.com

2 1

One way audio
by aft 12 May '14

12 May '14

Hi, The network topology is : SipSoftphone(caller)----->kamailio/rtpproxy---->Softswitch---->sipGateway-->mobile phone(callee) The rtpproxy is managed in kamailio script by : if (is_request()) { if(has_totag()) { if(check_route_param("nat=yes")) { setbflag(FLB_NATB); } } } if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB))) return; if (is_request()) { rtpproxy_offer("co"); } if (is_reply()) { rtpproxy_answer("coz80"); } if (is_request()) { if (!has_totag()) { if(t_is_branch_route()) { add_rr_param(";nat=yes"); } } } if (is_reply()) { if(isbflagset(FLB_NATB)) { if(is_first_hop()) set_contact_alias(); } } Now if in rtpproxy_answer(), i don't resize rtp packets, then everything works fine. If i put "z80" then only one way audio can be heard. In SipSoftphone(caller) side, nothing can be heard. I have sniffed the SIP packets and it looked fine to me. The rtp packets from callee arrives fine in kamailio/rtpproxy box. But it does not leave that box. I've sniffed the rtp packets. Before the call is picked up by the callee, there is an ivr played. The ivr arrives at the caller(softphone) end fine. But after picking up the phone, rtppackets are not delivered to the caller(softphone)'s side. This is the rtpproxy's log: May 11 23:54:29 65429 rtpproxy[24207]: INFO:rxmit_packets: callee's address latched in: 85.13.205.178:13716 (RTP) May 11 23:54:41 65429 rtpproxy[24207]: DBUG:get_command: received command "27802_12 Uc18,96 2b15632de8c94ff488e9cdc1cdbcb85d 182.16.156.25 4000 74d009e3a57246138e2e0124cbe6ee89;1" May 11 23:54:41 65429 rtpproxy[24207]: INFO:handle_command: adding strong flag to existing session, new=1/0/0 May 11 23:54:41 65429 rtpproxy[24207]: INFO:handle_command: lookup on ports 54920/64810, session timer restarted May 11 23:54:41 65429 rtpproxy[24207]: DBUG:doreply: sending reply "27802_12 54920 64.120.57.111#012" May 11 23:55:42 65429 rtpproxy[24207]: INFO:process_rtp: session timeout May 11 23:55:42 65429 rtpproxy[24207]: INFO:remove_session: RTP stats: 1523 in from callee, 300 in from caller, 396 relayed, 0 dropped May 11 23:55:42 65429 rtpproxy[24207]: INFO:remove_session: RTCP stats: 0 in from callee, 8 in from caller, 8 relayed, 0 dropped May 11 23:55:42 65429 rtpproxy[24207]: INFO:remove_session: session on ports 54920/64810 is cleaned up May 11 23:58:58 65429 rtpproxy[24207]: DBUG:get_command: received command "27802_13 Uc18,96 008e2697e52a4adda7be16358b318def 182.16.156.25 4002 907ba9691f6a47f3bfb0bb4143ef7dc7;1" May 11 23:58:58 65429 rtpproxy[24207]: INFO:handle_command: new session 008e2697e52a4adda7be16358b318def, tag 907ba9691f6a47f3bfb0bb4143ef7dc7;1 requested, type strong May 11 23:58:58 65429 rtpproxy[24207]: INFO:handle_command: new session on a port 53876 created, tag 907ba9691f6a47f3bfb0bb4143ef7dc7;1 May 11 23:58:58 65429 rtpproxy[24207]: INFO:handle_command: pre-filling caller's address with 182.16.156.25:4002 May 11 23:58:58 65429 rtpproxy[24207]: DBUG:doreply: sending reply "27802_13 53876 64.120.57.111#012" May 11 23:58:59 65429 rtpproxy[24207]: DBUG:get_command: received command "27803_10 LZ80c18 008e2697e52a4adda7be16358b318def 85.13.205.178 26728 907ba9691f6a47f3bfb0bb4143ef7dc7;1 6611E63499885;1" May 11 23:58:59 65429 rtpproxy[24207]: INFO:handle_command: lookup on ports 53876/42866, session timer restarted May 11 23:58:59 65429 rtpproxy[24207]: INFO:handle_command: pre-filling callee's address with 85.13.205.178:26728 May 11 23:58:59 65429 rtpproxy[24207]: INFO:handle_command: RTP packets from callee will be resized to 80 milliseconds May 11 23:58:59 65429 rtpproxy[24207]: DBUG:doreply: sending reply "27803_10 42866 64.120.57.111#012" May 11 23:58:59 65429 rtpproxy[24207]: INFO:rxmit_packets: callee's address filled in: 85.13.217.158:26728 (RTP) May 11 23:58:59 65429 rtpproxy[24207]: INFO:rxmit_packets: guessing RTCP port for callee to be 26729 May 11 23:58:59 65429 rtpproxy[24207]: INFO:rxmit_packets: caller's address latched in: 182.16.156.25:4003 (RTCP) May 11 23:58:59 65429 rtpproxy[24207]: INFO:rxmit_packets: caller's address filled in: 182.16.156.25:1036 (RTP) May 11 23:58:59 65429 rtpproxy[24207]: DBUG:get_command: received command "27801_10 LZ80c18 008e2697e52a4adda7be16358b318def 85.13.205.178 26728 907ba9691f6a47f3bfb0bb4143ef7dc7;1 6611E63499885;1" May 11 23:58:59 65429 rtpproxy[24207]: INFO:handle_command: lookup on ports 53876/42866, session timer restarted May 11 23:58:59 65429 rtpproxy[24207]: INFO:handle_command: RTP packets from callee will be resized to 80 milliseconds May 11 23:58:59 65429 rtpproxy[24207]: DBUG:doreply: sending reply "27801_10 42866 64.120.57.111#012" May 11 23:59:00 65429 rtpproxy[24207]: DBUG:get_command: received command "27802_14 LZ80c18 008e2697e52a4adda7be16358b318def 85.13.205.178 26728 907ba9691f6a47f3bfb0bb4143ef7dc7;1 6611E63499885;1" May 11 23:59:00 65429 rtpproxy[24207]: INFO:handle_command: lookup on ports 53876/42866, session timer restarted May 11 23:59:00 65429 rtpproxy[24207]: INFO:handle_command: RTP packets from callee will be resized to 80 milliseconds May 11 23:59:00 65429 rtpproxy[24207]: DBUG:doreply: sending reply "27802_14 42866 64.120.57.111#012" May 11 23:59:02 65429 rtpproxy[24207]: DBUG:get_command: received command "27800_13 LZ80c18 008e2697e52a4adda7be16358b318def 85.13.205.178 26728 907ba9691f6a47f3bfb0bb4143ef7dc7;1 6611E63499885;1" May 11 23:59:02 65429 rtpproxy[24207]: INFO:handle_command: lookup on ports 53876/42866, session timer restarted May 11 23:59:02 65429 rtpproxy[24207]: INFO:handle_command: RTP packets from callee will be resized to 80 milliseconds May 11 23:59:02 65429 rtpproxy[24207]: DBUG:doreply: sending reply "27800_13 42866 64.120.57.111#012" May 11 23:59:06 65429 rtpproxy[24207]: DBUG:get_command: received command "27801_11 LZ80c18 008e2697e52a4adda7be16358b318def 85.13.205.178 26728 907ba9691f6a47f3bfb0bb4143ef7dc7;1 6611E63499885;1" May 11 23:59:06 65429 rtpproxy[24207]: INFO:handle_command: lookup on ports 53876/42866, session timer restarted May 11 23:59:06 65429 rtpproxy[24207]: INFO:handle_command: RTP packets from callee will be resized to 80 milliseconds May 11 23:59:06 65429 rtpproxy[24207]: DBUG:doreply: sending reply "27801_11 42866 64.120.57.111#012" May 11 23:59:10 65429 rtpproxy[24207]: DBUG:get_command: received command "27802_15 LZ80c18 008e2697e52a4adda7be16358b318def 85.13.205.178 26728 907ba9691f6a47f3bfb0bb4143ef7dc7;1 6611E63499885;1" May 11 23:59:10 65429 rtpproxy[24207]: INFO:handle_command: lookup on ports 53876/42866, session timer restarted May 11 23:59:10 65429 rtpproxy[24207]: INFO:handle_command: RTP packets from callee will be resized to 80 milliseconds May 11 23:59:10 65429 rtpproxy[24207]: DBUG:doreply: sending reply "27802_15 42866 64.120.57.111#012" May 11 23:59:20 65429 rtpproxy[24207]: INFO:rxmit_packets: callee's address latched in: 85.13.217.158:26728 (RTP) I don't what is going wrong here, but somehow rtpproxy is not relaying the packets from callee's end. But the addresses seems fine and whenever i remove the "z80" inside rtpproxy_answer(), It works fine. At first i thought its just that the resizer is broken. But when the ivr is played, the rtppackets of the ivr works just fine. -- -Cheers -Arif

1 0

Help diagnosing non-response from incoming call
by Alex Villacís Lasso 09 May '14

09 May '14

I have this setup for kamailio + asterisk, in which kamailio is supposed to listen on all ethernet interfaces on UDP port 5060, and will forward traffic from/to asterisk running on the same machine, and listening on localhost, udp port 5080. The scenario for the problematic call is somewhat like this: SIP-PROVIDER<--->NAT<--192.168.0.0/16-->eth0:192.168.10.10<--KAMAILIO-->127.0.0.1<--ASTERISK Our firewall/NAT has been configured to redirect SIP traffic from the SIP provider to the kamailio+asterisk machine at IP 192.168.10.10. The attached file sip-traffic-from-eth0.txt shows a tcpdump capture of an incoming call at eth0. Then, kamailio is supposed to redirect this traffic to asterisk. The attached file sip-traffic-from-localhost.txt shows a tcpdump capture of the same call at 127.0.0.1. The issue is that the INVITE is received, then routed to asterisk, which sends back the 200 OK, but then there is no ACK from the SIP provider. From the point of view of the caller of the SIP provider, the destination just keeps ringing until timeout. Am I right in assuming that the two Record-Route headers should not appear on the traffic as seen from eth0, and that they are the source of the trouble? Can you see any additional issues I might have not seen in the traffic?

1 0

Multiple port configuration
by Alex Villacís Lasso 09 May '14

09 May '14

How do I configure kamailio to listen to multiple ports, on all known interfaces? I have tried "listen=udp:*:5060", "listen=udp:*:5062" on separate lines, but I get the following errors: Not starting : invalid configuration file! 0(7806) : <core> [cfg.y:3411]: yyerror_at(): parse error in config file //etc/kamailio/kamailio.cfg, line 190, column 12: syntax error 0(7806) : <core> [cfg.y:3411]: yyerror_at(): parse error in config file //etc/kamailio/kamailio.cfg, line 190, column 12: ip address, interface name or hostname expected 0(7806) : <core> [cfg.y:3411]: yyerror_at(): parse error in config file //etc/kamailio/kamailio.cfg, line 190, column 13: ERROR: bad config file (3 errors) I have also tried "port=5060", then "port=5062" on separate lines, but kamailio only listens on the port indicated by the last line. I do not want to have to enumerate every single interface on the configuration file.

2 1

route(RELAY) - what exactly execute?
by Patrik Kristel 09 May '14

09 May '14

Hello, I would like to ask what exactly means route(RELAY)? I don't found some declaration of it. I{ found it in many method before exit; I think its probably last handle of SIP message, am I right? Thank you Patrik

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