sr-users August 2015

sr-users@lists.kamailio.org

79 participants
125 discussions

force_send_socket/$fs behaviour when binding to INADDR_ANY
by Alex Balashov 11 Aug '15

11 Aug '15

Hello, When binding Kamailio to 0.0.0.0, Kamailio no longer recognises any specific IP address homed on the system as being a "socket" for purposes of forcing traffic out of any specific interface (i.e. setting $fs), or any other purpose for which ingress and egress "sockets" are tracked (e.g. double RR). As I understand it, this is because Kamailio considers only addresses explicitly specified via the 'listen' core config directive to be valid "send socket" arguments. Kamailio _will_ accept addresses already attached to the interface if it is bound interface-wise, e.g. listen=eth1:5060 but not when addresses are added to the interface without restarting the proxy: # ip addr add dev eth1 172.30.110.10/24 Aug 10 17:31:35 centosity6 /usr/local/sbin/kamailio[28627]: WARNING: pv [pv_core.c:2285]: pv_set_force_sock(): no socket found to match [udp:172.30.110.10:5060] Is there any straightforward way to modify this behaviour, so that it would be possible to dynamically add addresses to existing physical interfaces and get Kamailio to utilise them as if they were bound at boot time? Thanks, -- Alex -- Alex Balashov | Principal | Evariste Systems LLC 303 Perimeter Center North, Suite 300 Atlanta, GA 30346 United States Tel: +1-800-250-5920 (toll-free) / +1-678-954-0671 (direct) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

2 1

Re: [SR-Users] Unable to limit call duration with timeout_avp
by Admin 10 Aug '15

10 Aug '15

Thanks Alex. That worked.

1 0

Unable to limit call duration with timeout_avp
by Admin 10 Aug '15

10 Aug '15

Hi, I am using dialog time_avp() parameter to limit the call duration to a configured number of seconds but unfortunately when the number is reached, i get a warning but the call is not torn down. Here is the output from the log file 3(3711) DEBUG: <script>: return value = 30 -----> $avp(i:10) 5(3713) WARNING: dialog [dlg_handlers.c:1426]: dlg_ontimeout(): timeout for dlg with CallID '1-3743(a)192.168.1.100' and tags '37431' '37401' 5(3713) DEBUG: dialog [dlg_hash.c:832]: dlg_unref(): unref dlg 0x7f32ee941140 with 2 -> 0 5(3713) DEBUG: dialog [dlg_hash.c:832]: dlg_unref(): ref <=0 for dialog 0x7f32ee941140 5(3713) DEBUG: dialog [dlg_hash.c:320]: destroy_dlg(): destroying dialog 0x7f32ee941140 (ref 0) 5(3713) DEBUG: dialog [dlg_hash.c:336]: destroy_dlg(): removed timer for dlg 0x7f32ee941140 [773:2813] with clid '1-3743(a)192.168.1.100' and tags '37431' '37401' Here is my config. file related to dialog module: #!define DLG_FLAG 4 loadmodule "dialog.so" modparam("dialog", "dlg_match_mode", 2) modparam("dialog", "default_timeout", 3600) # 1 hour timeout modparam("dialog", "db_mode", 0) modparam("dialog", "hash_size", 2048) modparam("dialog", "dlg_flag", DLG_FLAG) modparam("dialog", "default_timeout", 3600) # 1 hour timeout modparam("dialog", "timeout_avp", "$avp(i:10)") if (is_method("INVITE")) { #$var(rv) = perl_exec("max_allowed_time"); $var(rv) = 30; $avp(i:10) = $var(rv); xlog("L_DBG", "return value = $var(rv)\n"); setflag(FLT_ACC); # do accounting setflag(DLG_FLAG); } Maybe i am missing some configuration related to the dialog module. Any help is very much appreciated. Thanks.

2 2

Handling a non-standard SIP port
by Jean-Marie Baran 10 Aug '15

10 Aug '15

Hi, This is a question for the sake of comprehension, as I actually solved the problem with a workaround. I am trying to get Kamailio working with a third party SIP provider. The SIP server of this provider pings my Kamailio with OPTIONS messages. Being located in a sub-network, the SIP messages are relayed to a router (not a SIP router, just a gateway to the Internet) which is not listening/sending on port 5060 but on 13377. When Kamailio answer to OPTIONS, it send back the message to the router on the port 5060 which is wrong. Here is the topology: *Kamailio* *Router* *SIP Server* /my.sip.domain 174.37.217.1 197.17.144.4/ | | ? <-------------------- 5060 | | 5060 <---------------- 13377 | | | 5060 ----------------−> 5060 | | | | X | You can see that, Kamailio answers to the wrong port, but I think this is somewhat coherent since the SIP message says that the port 5060 is in use. But still, I would have liked that the correct port was used: *Kamailio* *Router* *SIP Server* /my.sip.domain 174.37.217.1 197.17.144.4 / | | ? <-------------------- 5060 | | 5060 <---------------- 13377 | | | 5060 ---------------−> 13377 | | | | ? --------------------> 5060 | But I do not understand where Kamailio is supposed to find the correct port. Below are the transport frames, and SIP frames. Kamailio receives: Internet Protocol Version 4, Src: 174.37.217.1 (174.37.217.1), Dst: 172.16.8.61 (172.16.8.61) Source: 174.37.217.1 (174.37.217.1) Destination: 172.16.8.61 (172.16.8.61) User Datagram Protocol, Src Port: 13377 (13377), Dst Port: sip (5060) Source port: 13377 (13377) Destination port: sip (5060) OPTIONS sip:my.sip.domain:5060 SIP/2.0 Via: SIP/2.0/UDP 197.17.144.4:5060;branch=z9hG4bKb9340cb29ba From: <sip:197.17.144.4>;tag=1797904074 To: <sip:my.sip.domain> Date: Mon, 10 Aug 2015 10:01:51 GMT Call-ID: c7f38580-5c817680-b94-38512c6(a)197.17.144.4 User-Agent: Cisco-CUCM10.5 CSeq: 101 OPTIONS Contact: <sip:197.17.144.4:5060> Max-Forwards: 0 Content-Length: 0 ...and then sends: Internet Protocol Version 4, Src: 172.16.8.61 (172.16.8.61), Dst: 174.37.217.1 (174.37.217.1) Source: 172.16.8.61 (172.16.8.61) Destination: 174.37.217.1 (174.37.217.1) User Datagram Protocol, Src Port: sip (5060), Dst Port: sip (5060) Source port: sip (5060) Destination port: sip (5060) SIP/2.0 200 OK Via: SIP/2.0/UDP 197.17.144.4:5060;branch=z9hG4bKb9340cb29ba;received=174.37.217.1 From: <sip:197.17.144.4>;tag=1797904074 To: <sip:my.sip.domain>;tag=b27e1a1d33761e85846fc98f5f3a7e58.de7a Call-ID: c7f38580-5c817680-b94-38512c6(a)197.17.144.4 CSeq: 101 OPTIONS Allow: INVITE,ACK,BYE,CANCEL,INFO,OPTIONS,REFER,SUBSCRIBE,NOTIFY Accept: */* Accept-Encoding: Accept-Language: en Supported: Server: kamailio (4.3.1 (x86_64/linux)) Content-Length: 0 We see clearly that the port is wrong here. But in the received SIP frame, everything suggests that the correct port is 5060, and I do not think Kamailio will look at the transport frame to send the response back to the correct port. Am I correct stating this ? Maybe the Via header should contain a port along with the IP address ? I solved the problem by using TCP instead of UDP, as I know that since the TCP connection is maintained, the port would be correct (because imposed by the gateway). I am sorry if the question does not directly relates to Kamailio, but any explanation here would be appreciated, as I am a student trying to learn how all this is working :) Cheers, Jean-Marie.

2 2

rtpengine disabling offers of rtcp
by Daniel Tryba 10 Aug '15

10 Aug '15

Maybe a bit offtopic, but I can't find a rtpengine mailinglist and know the Sipwise guys are reading this list. Since upgrading to 4.2.x and rtpengine instead of rtpproxy I'm seeing problems with calls being terminated by upstream provider after a bit more than 5m. The INVITE process looks okay, the only difference with before as far as I can see is the rtcp attribute in the SDP body. According to http://kamailio.org/docs/modules/4.2.x/modules/rtpengine.html#rtpengine.f.r… and https://github.com/sipwise/rtpengine rtcp offering can be disabled. But neither rtcp-mux-demux nor rtcp-mux-accept have any impact on the adding of the a=rtcp:port attribute in SDP. rtpengine_manage("trust-address replace-origin replace-session-connection rtcp-mux-accept ICE=remove"); or rtpengine_manage("trust-address replace-origin replace-session-connection rtcp-mux-demux ICE=remove"); have no effect op the INVITE to the upstream. kamailio: 4.2.5 rtpengine: 4.1.0.0+0~mr4.1.0.0

3 4

Debian/jessie and 4.3.1 default config doesn't work
by Daniel Tryba 10 Aug '15

10 Aug '15

It looks like the compile defaults of the ctl and mi_fifo module and the default kamailio.conf/kamctlrc conflict. kamailio tries to open: /tmp/buildd/kamailio-4.3.1+jessie/debian/kamailio/var/run/kamailio//kamailio_ctl /tmp/buildd/kamailio-4.3.1+jessie/debian/kamailio/var/run/kamailio/kamailio_fifo and will fail to run, unless explicitly set to conf paths are set to /var/run/kamailio/kamailio_(ctl|fifo)

2 3

Re: [SR-Users] LCR Routing - Cost based routing
by DanB 10 Aug '15

10 Aug '15

Guys, Since I saw the thread growing, I am around if you got questions on CGRateS related LCR, fully compatible with Kamailio via evapi module. DanB

2 1

Running Kamailio 4.3 on Debian 8.1 and systemd
by Grant Bagdasarian 10 Aug '15

10 Aug '15

Hello, I just installed the latest stable release of Kamailio (I believe 4.3.1) on a debian 8.1 system using the install guide (http://www.kamailio.org/wiki/install/4.3.x/git). Starting kamailio didn't work using /etc/init.d/kamailio start. I got the following error: # /etc/init.d/kamailio start [....] Starting kamailio (via systemctl): kamailio.serviceFailed to start kamailio.service: Unit kamailio.service failed to load: No such file or directory. failed! After some googling I found out I have to add a new file named kamailio.service to the /etc/systemd/system/ directory. Kamailio.service: [Unit] Description=Kamailio SIP Server [Service] Type=forking PIDFile=/var/run/kamailio.pid ExecStart=/usr/local/sbin/kamctl start ExecRestart=/usr/local/sbin/kamctl restart ExecStop=/usr/local/sbin/kamctl stop [Install] WantedBy=multi-user.target Now I can start kamailio using the command: service kamailio start Is this the correct way of doing this? Does the file need any changes? Regards, Grant

1 0

Wrong Call-ID and tags in response to OPTIONS
by Jean-Marie Baran 10 Aug '15

10 Aug '15

Hi, I am trying to get Kamailio working with a third party SIP provider. This provider pings Kamailio with OPTIONS messages, but Kamailio does not answer correctly: the Call-ID and the tags change where they should not. Here is an example: Third party SIP server: OPTIONS sip:false.sip.provider:5060 SIP/2.0 Via: SIP/2.0/UDP 197.17.144.4:5060;branch=z9hG4bK8e45ac1463a From: <sip:197.17.144.4>;tag=1669836943 To: <sip:false.sip.provider> Date: Fri, 07 Aug 2015 12:34:37 GMT Call-ID: a012e080-5c41a5ce-8e5-38512c6(a)197.17.144.4 User-Agent: Cisco-CUCM10.5 CSeq: 101 OPTIONS Contact: <sip:197.17.144.4:5060> Max-Forwards: 0 Content-Length: 0 Kamailio's answer: SIP/2.0 200 OK Via: SIP/2.0/UDP 197.17.144.4:5060;branch=z9hG4bK93e5f072f5f;received=174.37.217.1 From: <sip:197.17.144.4>;tag=298911055 To: <sip:false.sip.provider>;tag=b27e1a1d33761e85846fc98f5f3a7e58.8c24 Call-ID: 2defcb00-5c41aa17-93f-38512c6(a)197.17.144.4 CSeq: 101 OPTIONS Server: kamailio (4.3.1 (x86_64/linux)) Content-Length: 0 You can see that the Call-ID change from "a012e080-5c41a5ce-8e5-38512c6" to "2defcb00-5c41aa17-93f-38512c6". Likewise, the From tag change ("1669836943" to "298911055"). What could be the reason for this ? Moreover I think Kamailio should add the field Allow (with INVITE,ACK,BYE,CANCEL,INFO,OPTIONS,REFER,SUBSCRIBE,NOTIFY), but it does not. I should mention that I had to modify /kamailio.cfg/ to have Kamailio answer to OPTIONS messages (I added *the code in bold*): if (*!is_method("OPTIONS") && *!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); exit; } if(is_method("OPTIONS") && uri==myself && $rU==$null) { *#* sl_send_reply("200","Keepalive"); *options_reply();* exit; } Maybe this hack replaces an expected behavior that I failed to see/configure ? Thanks, Jean-Marie.

3 3

Kamailio 4.3 and XCAP
by Safdar Khan 10 Aug '15

10 Aug '15

Hello sir/mam How can i configure xcap with kamailio 4.3. I am finding difficulties in routing logic of xcap_server module amd xcap_client module. Will you please share proper documentation of these two technology together.

1 0

← Newer
1
...
7
8
9
10
11
12
13
Older →

2026

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 August 2015