sr-users March 2020

sr-users@lists.kamailio.org

64 participants
80 discussions

P-CSCF Error - help required asap
by Pavithra N M 30 Mar '20

30 Mar '20

Hi, I am facing the below error in my P-CSCF module as i am running P-CSCF, I-CSCF, S-CSCF, HSS in separate VMs. 0(3512) INFO: <core> [core/udp_server.c:206]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 0(3512) ERROR: <script>: event_route[htable:mod-init] { 1(3513) ERROR: rtpengine [rtpengine.c:2839]: send_rtpp_command(): can't send command "ping" to RTP proxy <udp:localhost:9910> 1(3513) ERROR: rtpengine [rtpengine.c:2740]: rtpp_test(): proxy did not respond to ping 1(3513) ERROR: rtpengine [rtpengine.c:2839]: send_rtpp_command(): can't send command "ping" to RTP proxy <udp:localhost:9911> 1(3513) ERROR: rtpengine [rtpengine.c:2740]: rtpp_test(): proxy did not respond to ping 68(3637) INFO: ctl [io_listener.c:214]: io_listen_loop(): io_listen_loop: using epoll_lt io watch method (config) 72(3644) WARNING: ims_usrloc_pcscf [usrloc_db.c:67]: connect_db(): DB connection already open... continuing 73(3645) WARNING: ims_usrloc_pcscf [usrloc_db.c:67]: connect_db(): DB connection already open... continuing 69(3641) WARNING: ims_usrloc_pcscf [usrloc_db.c:67]: connect_db(): DB connection already open... continuing 75(3653) WARNING: ims_usrloc_pcscf [usrloc_db.c:67]: connect_db(): DB connection already open... continuing 71(3643) INFO: jsonrpcs [jsonrpcs_sock.c:443]: jsonrpc_dgram_process(): a new child 0/3643 77(3655) WARNING: ims_usrloc_pcscf [usrloc_db.c:67]: connect_db(): DB connection already open... continuing 76(3654) WARNING: ims_usrloc_pcscf [usrloc_db.c:67]: connect_db(): DB connection already open... continuing 74(3652) WARNING: ims_usrloc_pcscf [usrloc_db.c:67]: connect_db(): DB connection already open... continuing 79(3657) WARNING: ims_usrloc_pcscf [usrloc_db.c:67]: connect_db(): DB connection already open... continuing root@tel-VirtualBox:/etc/kamailio/pcscf# 78(3656) WARNING: ims_usrloc_pcscf [usrloc_db.c:67]: connect_db(): DB connection already open... continuing 69(3641) ERROR: *** cfgtrace:request_route=[NATPING] c=[/etc/kamailio/pcscf/kamailio.cfg] l=836 a=5 n=route 69(3641) ERROR: *** cfgtrace:request_route=[preload_pcscf] c=[/etc/kamailio/pcscf/kamailio.cfg] l=895 a=16 n=if 69(3641) ERROR: *** cfgtrace:request_route=[preload_pcscf] c=[/etc/kamailio/pcscf/kamailio.cfg] l=895 a=63 n=assign 69(3641) ERROR: *** cfgtrace:request_route=[preload_pcscf] c=[/etc/kamailio/pcscf/kamailio.cfg] l=897 a=27 n=sql_query 69(3641) ERROR: *** cfgtrace:request_route=[preload_pcscf] c=[/etc/kamailio/pcscf/kamailio.cfg] l=898 a=25 n=xlog 69(3641) ERROR: <script>: Preloading NAT-PING. Rows: 0 69(3641) ERROR: *** cfgtrace:request_route=[preload_pcscf] c=[/etc/kamailio/pcscf/kamailio.cfg] kindly help me in this issue of how to configure the rtp proxy or even if it is not required for basic configuration,let me know the procedure to comment this part or the procedure to take it forward to run P-CSCF without any errors. Kindly help me in this regard. Thanks Best Regards Pavithra M Tata Elxsi [cid:7ca5c450-5bb2-4d74-85ab-1c3e16346e2e] ________________________________ Disclaimer: This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you are not the intended recipient of this message , or if this message has been addressed to you in error, please immediately alert the sender by reply email and then delete this message and any attachments. If you are not the intended recipient, you are hereby notified that any use, dissemination, copying, or storage of this message or its attachments is strictly prohibited. Email 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. The sender, therefore, does not accept liability for any errors, omissions or contaminations in the contents of this message which might have occurred as a result of email transmission. If verification is required, please request for a hard-copy version. ________________________________

1 0

How to correctly answer a PnP-SUBSCRIBE message
by Jan-Hendrik Dörner 30 Mar '20

30 Mar '20

Hallo, several telephones send a SIP-multicast SUBSCRIBE message to address 224.0.1.75 if they have no settings-URL configured and receive none over DHCP. So I configure my kamailio server, to respond to that multicast-request. But: Although mine is working, I do feel it could be improved, since the NOTIFY packet send out is not quite as it should be … Here is what I did (the 172.23.56.1 is my voip-vlan-address) listen=udp:172.23.56.1:5060 advertise 192.168.1.156:5060 listen=udp:192.168.1.156:5060 advertise 192.168.1.156:5060 listen=tcp:127.0.0.1:5060 mcast="eth0" listen=udp:224.0.1.75:5060 …. if ($Ri == "224.0.1.75"){ if(is_method("SUBSCRIBE")){ xlog("L_INFO", "Received pnp-event from IP $si from User-Agent $hdr(User-Agent) und User $fU\r\n" ); sl_send_reply("200", "OK"); t_uac_send("NOTIFY", "$(ct{s.substr,1,0}{s.striptail,1})", "", "","Subscription-State: terminated;reason=timeout\r\nEvent: $hdr(Event)\r\nContent-Type: application/url\r\nFrom: $fU\r\nTo: $hdr(From)", "http://server.conf/settings-{mac}"); }else { xlog("L_INFO", "Drop message $rm from pnp-Interface \r\n" ); } exit; } And here are the SIP-packets I see on my server (192.168.1.156) coming from my snom-phone (192.168.1.152). My problems with the NOTIFY -packets are: 1) How do I set the Via parameters to be the same as in the OK-reply? 2) How do I send out the NOTIFY only via the 192.168.1.156 network interface? 3) May I send out the NOTIFY with the Call-ID from the SUBSCRIBE message? How? Any help is highly appreciated Jan-Hendrik # U 192.168.1.152:58714 -> 224.0.1.75:5060 #258 SUBSCRIBE sip:MAC%3a0004137120D8@lan SIP/2.0. Via: SIP/2.0/UDP 192.168.1.152:58714;rport. From: <sip:MAC%3a0004137120D8@lan>;tag=1750588964. To: <sip:MAC%3a0004137120D8@lan>. Call-ID: 1395386659(a)192.168.1.152. CSeq: 1 SUBSCRIBE. Event: ua-profile;profile-type="device";vendor="snom";model="snom760";version="8.9.3.80". Expires: 0. Accept: application/url. Contact: <sip:192.168.1.152:58714>. User-Agent: snom760/8.9.3.80. Content-Length: 0. . # U 192.168.1.156:5060 -> 192.168.1.152:58714 #259 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.1.152:58714;rport=58714;received=192.168.1.152. From: <sip:MAC%3a0004137120D8@lan>;tag=1750588964. To: <sip:MAC%3a0004137120D8@lan>;tag=fb721cde02dffb6bb099728401306798.2f00. Call-ID: 1395386659(a)192.168.1.152. CSeq: 1 SUBSCRIBE. Server: kamailio (5.2.5 (x86_64/linux)). Content-Length: 0. . # U 192.168.1.156:5060 -> 192.168.1.152:58714 #260 NOTIFY sip:192.168.1.152:58714 SIP/2.0. Via: SIP/2.0/UDP 224.0.1.75;branch=z9hG4bKf21c.917eaf36000000000000000000000000.0. To: <sip:MAC%3a0004137120D8@lan>;tag=1750588964. From: <MAC%3a0004137120D8>;tag=da567df9df3ac234e43969a051db4641-8cfb. CSeq: 10 NOTIFY. Call-ID: 24eaa8de01be1768-70960(a)172.23.56.1. Max-Forwards: 70. Content-Length: 33. User-Agent: kamailio (5.2.5 (x86_64/linux)). Subscription-State: terminated;reason=timeout. Event: ua-profile;profile-type="device";vendor="snom";model="snom760";version="8.9.3.80". Content-Type: application/url. . http://server.conf/settings-{mac} # U 172.23.56.1:5060 -> 192.168.1.152:58714 #261 NOTIFY sip:192.168.1.152:58714 SIP/2.0. Via: SIP/2.0/UDP 224.0.1.75;branch=z9hG4bKf21c.917eaf36000000000000000000000000.0. To: <sip:MAC%3a0004137120D8@lan>;tag=1750588964. From: <MAC%3a0004137120D8>;tag=da567df9df3ac234e43969a051db4641-8cfb. CSeq: 10 NOTIFY. Call-ID: 24eaa8de01be1768-70960(a)172.23.56.1. Max-Forwards: 70. Content-Length: 33. User-Agent: kamailio (5.2.5 (x86_64/linux)). Subscription-State: terminated;reason=timeout. Event: ua-profile;profile-type="device";vendor="snom";model="snom760";version="8.9.3.80". Content-Type: application/url. . http://server.conf/settings-{mac} # U 172.23.56.1:5060 -> 192.168.1.152:58714 #262 NOTIFY sip:192.168.1.152:58714 SIP/2.0. Via: SIP/2.0/UDP 224.0.1.75;branch=z9hG4bKf21c.917eaf36000000000000000000000000.0. To: <sip:MAC%3a0004137120D8@lan>;tag=1750588964. From: <MAC%3a0004137120D8>;tag=da567df9df3ac234e43969a051db4641-8cfb. CSeq: 10 NOTIFY. Call-ID: 24eaa8de01be1768-70960(a)172.23.56.1. Max-Forwards: 70. Content-Length: 33. User-Agent: kamailio (5.2.5 (x86_64/linux)). Subscription-State: terminated;reason=timeout. Event: ua-profile;profile-type="device";vendor="snom";model="snom760";version="8.9.3.80". Content-Type: application/url. . http://server.conf/settings-{mac} # U 192.168.1.152:58714 -> 224.0.1.75:5060 #263 SUBSCRIBE sip:MAC%3a0004137120D8@lan SIP/2.0. Via: SIP/2.0/UDP 192.168.1.152:58714;rport. From: <sip:MAC%3a0004137120D8@lan>;tag=1971605806. To: <sip:MAC%3a0004137120D8@lan>. Call-ID: 1846532696(a)192.168.1.152. CSeq: 1 SUBSCRIBE. Event: ua-profile;profile-type="device";vendor="snom";model="snom760";version="8.9.3.80". Expires: 0. Accept: application/url. Contact: <sip:192.168.1.152:58714>. User-Agent: snom760/8.9.3.80. Content-Length: 0. . # U 192.168.1.156:5060 -> 192.168.1.152:58714 #264 SIP/2.0 200 OK. Via: SIP/2.0/UDP 192.168.1.152:58714;rport=58714;received=192.168.1.152. From: <sip:MAC%3a0004137120D8@lan>;tag=1971605806. To: <sip:MAC%3a0004137120D8@lan>;tag=fb721cde02dffb6bb099728401306798.2f00. Call-ID: 1846532696(a)192.168.1.152. CSeq: 1 SUBSCRIBE. Server: kamailio (5.2.5 (x86_64/linux)). Content-Length: 0. . # U 192.168.1.156:5060 -> 192.168.1.152:58714 #265 NOTIFY sip:192.168.1.152:58714 SIP/2.0. Via: SIP/2.0/UDP 224.0.1.75;branch=z9hG4bK201a.063839a4000000000000000000000000.0. To: <sip:MAC%3a0004137120D8@lan>;tag=1971605806. From: <MAC%3a0004137120D8>;tag=da567df9df3ac234e43969a051db4641-f31b. CSeq: 10 NOTIFY. Call-ID: 24eaa8de01be1768-70963(a)172.23.56.1. Max-Forwards: 70. Content-Length: 33. User-Agent: kamailio (5.2.5 (x86_64/linux)). Subscription-State: terminated;reason=timeout. Event: ua-profile;profile-type="device";vendor="snom";model="snom760";version="8.9.3.80". Content-Type: application/url. . http://server.conf/settings-{mac} # U 192.168.1.152:58714 -> 192.168.1.156:5060 #266 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 224.0.1.75;branch=z9hG4bKf21c.917eaf36000000000000000000000000.0;received=192.168.1.156. From: <MAC:0004137120D8>;tag=da567df9df3ac234e43969a051db4641-8cfb. To: <sip:MAC%3A0004137120D8@lan>;tag=1750588964. Call-ID: 24eaa8de01be1768-70960(a)172.23.56.1. CSeq: 10 NOTIFY. User-Agent: snom760/8.9.3.80. Content-Length: 0. . # U 192.168.1.152:58714 -> 192.168.1.156:5060 #267 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 224.0.1.75;branch=z9hG4bKf21c.917eaf36000000000000000000000000.0;received=192.168.1.156. From: <MAC:0004137120D8>;tag=da567df9df3ac234e43969a051db4641-8cfb. To: <sip:MAC%3A0004137120D8@lan>;tag=1750588964. Call-ID: 24eaa8de01be1768-70960(a)172.23.56.1. CSeq: 10 NOTIFY. User-Agent: snom760/8.9.3.80. Content-Length: 0. . # U 192.168.1.152:58714 -> 192.168.1.156:5060 #268 SIP/2.0 200 Ok. Via: SIP/2.0/UDP 224.0.1.75;branch=z9hG4bK201a.063839a4000000000000000000000000.0;received=192.168.1.156. From: <MAC:0004137120D8>;tag=da567df9df3ac234e43969a051db4641-f31b. To: <sip:MAC%3A0004137120D8@lan>;tag=1971605806. Call-ID: 24eaa8de01be1768-70963(a)172.23.56.1. CSeq: 10 NOTIFY. User-Agent: snom760/8.9.3.80. Content-Length: 0. .

2 1

setting $du in branch route has no effect in 5.3
by Juha Heinanen 30 Mar '20

30 Mar '20

I noticed that in 5.3 and master setting $du in branch route has no effect. It works fine in 5.2 using exactly the same config. -- Juha

2 12

Problem faced when Using Kamaiio as Session Refresher
by harneet singh 30 Mar '20

30 Mar '20

Hi, I am fairly new to Kamailio and had a question regarding how to use Kamailio to enable Session refresh functionality when Kamailio is acting as Sip Stateful Proxy. Kamailio Version used: *5.3.2* with *Call Load based routing* using the *dispatcher *module. * From what i understand from the documentation, Kamailio will probably not be acting as a session refresher, but Kamailio can tear down the call in case session refresh is negotiated, between the caller and the callee(via Kamailio Sip Proxy), and no message exchange happens in the duration set in Session-Expires header. *Is my understanding correct?* ** *I believe the above functionality is possible by using the *sst* and *dialog* module. I have set the same according to the documentation but I keep getting the following error: "dialog [dlg_handlers.c:681]: *get_dlg_timeout(): invalid AVP value, using default timeout*" Can someone share a working example? * When i tried hardcoding the timeout value by setting the timeout_avp to a specific value, Kamailio did sense a timeout and hence sent a BYE towards the caller and the Callee side both(which is what the requirement is), however, i do see the *dialog is still not cleared* in the "kamcmd dispatcher.list". Output excerpt below for reference: [root@CPaaSVM ~]# kamcmd dispatcher.list { NRSETS: 1 RECORDS: { SET: { ID: 1 TARGETS: { DEST: { URI: sip:172.27.44.121:5080 ;transport=tcp FLAGS: AP PRIORITY: 0 ATTRS: { BODY: duid=sample-cas;maxload=1000 DUID: sample-cas MAXLOAD: 1000 WEIGHT: 0 RWEIGHT: 0 SOCKET: } LATENCY: { AVG: 111.304000 STD: 1042.193000 EST: 2.385000 MAX: 9999 TIMEOUT: 1 } RUNTIME: { DLGLOAD: *1* } } } } } } It is noteworthy that in case the BYE is initiated by either the caller or the callee, the dialog is cleared properly and the DLGLOAD is set to 0 on call termination. Any pointers for the above questions would be highly appreciated. Regards, Harneet -- "Once you eliminate the impossible, whatever remains, no matter how improbable, must be the truth" - Sir Arthur Conan Doyle

3 17

Transaction Matching Failed - ACK BYE
by egemen ulus 29 Mar '20

29 Mar '20

Hi All, I'm trying to establish a topology with Kamailio which is located between Asterisk and Outside. My issue is "transaction matching failed" (t_check_trans failed). That means Kamailio does not recognise ACK & BYE message to forwards. I had a check on email list and google but found nothing. I'm using it with record_route. SIP signalling and part of kamailio.cfg is below. Is there any suggestion? route[WITHINDLG] { if (!has_totag()) return; if (loose_route()) { route(DLGURI); if (is_method("BYE")) { setflag(FLT_ACC); # do accounting ... setflag(FLT_ACCFAILED); # ... even if the transaction fails } else if ( is_method("ACK") ) { xlog("ack is came: $si:$sp\n"); route(NATMANAGE); } else if ( is_method("NOTIFY") ) { record_route(); } route(RELAY); exit; } if (is_method("SUBSCRIBE") && uri == myself) { route(PRESENCE); exit; } if ( is_method("ACK") ) { if ( t_check_trans() ) { route(RELAY); exit; } else { exit; } } sl_send_reply("404","Not here"); exit; } route[NATMANAGE] { #!ifdef WITH_NAT if (is_request()) { if(has_totag()) { if(check_route_param("nat=yes")) { setbflag(FLB_NATB); } } } route(RTPPROXY); if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB))) return; 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(); } } #!endif return; } Asterisk > Kamailio INVITE sip:user@outside_ip SIP/2.0 Via: SIP/2.0/UDP asterisk_ip:5060;branch=z9hG4bK1b56cce0 Max-Forwards: 70 From: "KUYRUK" <sip:0553847<tel:+10553847>aaaa@asterisk_ip>;tag=as3dde7cdb To: <sip:user@outside_ip> Contact: <sip:0553847<tel:+10553847>aaaa@asterisk_ip:5060> Call-ID: 62a480bf71d2a1aa0ec94b454cd98945@asterisk_ip:5060 CSeq: 102 INVITE User-Agent: Asterisk PBX 1.8.32.3 Kamailio > Outside INVITE sip:user@outside_ip SIP/2.0 Record-Route: <sip:kamailio_ip;lr;nat=yes> Via: SIP/2.0/UDP kamailio_ip;branch=z9hG4bK7b3f.8e4716eeea4b0dc45cc51d21b5aded57.0 Via: SIP/2.0/UDP asterisk_ip:5060;rport=5060;branch=z9hG4bK1b56cce0 From: "KUYRUK" <sip:0553847<tel:+10553847>aaaa@asterisk_ip>;tag=as3dde7cdb To: <sip:user@outside_ip> Contact: <sip:0553847<tel:+10553847>aaaa@asterisk_ip:5060;alias=asterisk_ip~5060~1> Call-ID: 62a480bf71d2a1aa0ec94b454cd98945@asterisk_ip:5060 CSeq: 102 INVITE User-Agent: Asterisk PBX 1.8.32.3 Outside > Kamailio SIP/2.0 200 OK Via: SIP/2.0/UDP kamailio_ip;branch=z9hG4bK7b3f.8e4716eeea4b0dc45cc51d21b5aded57.0 Via: SIP/2.0/UDP asterisk_ip:5060;rport=5060;branch=z9hG4bK1b56cce0 From: "KUYRUK" <sip:0553847<tel:+10553847>aaaa@asterisk_ip>;tag=as3dde7cdb To: <sip:user@outside_ip>;tag=kv8iml6ur9 Call-ID: 62a480bf71d2a1aa0ec94b454cd98945@asterisk_ip:5060 CSeq: 102 INVITE Record-Route: <sip:kamailio_ip;lr;nat=yes> Contact: <sip:user@outside_ip:5060;alias=x.x.x.x~18005~6;transport=udp> Kamailio > Asterisk SIP/2.0 200 OK Via: SIP/2.0/UDP asterisk_ip:5060;rport=5060;branch=z9hG4bK1b56cce0 From: "KUYRUK" <sip:0553847<tel:+10553847>aaaa@asterisk_ip>;tag=as3dde7cdb To: <sip:user@outside_ip>;tag=kv8iml6ur9 Call-ID: 62a480bf71d2a1aa0ec94b454cd98945@asterisk_ip:5060 CSeq: 102 INVITE Record-Route: <sip:kamailio_ip;lr;nat=yes> Contact: <sip:user@outside_ip:5060;alias=x.x.x.x~18005~6;transport=udp> Asterisk > Kamailio THIS ACK IS NOT ROUTED TO OUTSIDE BY KAMAILIO!! ACK sip:user@outside_ip:5060;alias=x.x.x.x~18005~6;transport=udp SIP/2.0 Via: SIP/2.0/UDP asterisk_ip:5060;branch=z9hG4bK73366924 Route: <sip:kamailio_ip;lr;nat=yes> From: "KUYRUK" <sip:0553847<tel:+10553847>aaaa@asterisk_ip>;tag=as3dde7cdb To: <sip:user@outside_ip>;tag=kv8iml6ur9 Contact: <sip:0553847<tel:+10553847>aaaa@asterisk_ip:5060> Call-ID: 62a480bf71d2a1aa0ec94b454cd98945@asterisk_ip:5060 CSeq: 102 ACK User-Agent: Asterisk PBX 1.8.32.3 Get Outlook for Android<https://aka.ms/ghei36>

2 6

Kamailiio TLS and Let'sEncrypt certs
by Igor Olhovskiy 29 Mar '20

29 Mar '20

Hi! Actually I’m trying to get Kamailio to work as MS Teams SBC following by perfect article https://skalatan.de/en/blog/kamailio-sbc-teams <https://skalatan.de/en/blog/kamailio-sbc-teams> It works well, but one thing is bothering me. I’m using Let’sEncrypt certs (actually, works well), but with setting in tls.conf verify_certificate = yes require_certificate = yes It’s giving an errors like /usr/sbin/kamailio[4551]: ERROR: tls [tls_util.h:42]: tls_err_ret(): TLS write:error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed /usr/sbin/kamailio[4551]: ERROR: <core> [core/tcp_read.c:1505]: tcp_read_req(): ERROR: tcp_read_req: error reading - c: 0x7f03e6d23d88 r: 0x7f03e6d23e08 (-1) They are resolved with setting these settings (verify/require) to off (actually, as mentioned here - https://www.fredposner.com/1836/kamailio-tls-and-letsencrypt/ <https://www.fredposner.com/1836/kamailio-tls-and-letsencrypt/>), but I’m really curious - why? As I got, it’s using openssl verify on a background, but this check locally passed with openssl verify -CAfile issuer.crt myserver.crt myserver.crt: OK So, is there any tricks to lets encrypt or just some misconfig in tls.cfg? Now it looks like one from article [server:default] method = TLSv1.2+ verify_certificate = yes require_certificate = yes private_key = /etc/kamailio/tls/myserver.key certificate = /etc/kamailio/tls/myserver.crt ca_list = /etc/kamailio/tls/issuer.crt [client:default] method = TLSv1.2+ verify_certificate = yes require_certificate = yes private_key = /etc/kamailio/tls/myserver.key certificate = /etc/kamailio/tls/myserver.crt ca_list = /etc/kamailio/tls/issuer.crt — Regards, Igor

3 3

Kamailio OPTIONS Round-Trip
by Soltanici Ilie 27 Mar '20

27 Mar '20

Hi, With Asterisk, we are able to get some peer round-trip connection statistic by setting qualify=yes for the specified peer. It sends periodic OPTIONS to the peer and calculates the time round trip time. It's something like - "Status: OK (30 ms)". Is there any way to achieve this in Kamailio by using nathelper module, or any other? Thank you.

9 13

Segmentation fault in DMQ module
by Virgílio Cunha 27 Mar '20

27 Mar '20

Hello, I have in production environment with 4 proxies using DMQ to sync terminal registers and the DMQ configuration parameters is following: loadmodule "dmq.so" #modparam("dmq", "server_address", "sip:MY_IP_ADDRESS:MY_PORT_ADDRESS") modparam("dmq", "notification_address", "DMQ_HOSTS") modparam("dmq", "multi_notify", 1) modparam("dmq", "num_workers", 4) In the lab environment with the same configuration that in prod, I can simulate this problem with 12000 terminal REGISTERS and, when doing several restarts on a proxy, one of them is generated a coredump. Analyzing the core, I can see that the problem is concurrency in the dmq synchronization. Job_queue_size (...) is called with a valid *queue *and, but inside this function, the *queue *is null. (gdb) up #1 0x00007fefe58ee246 in job_queue_size (queue=0x0) at worker.c:254 254 return atomic_get(&queue->count); (gdb) print queue $1 = (job_queue_t *) 0x0 (gdb) up #2 0x00007fefe58ed920 in add_dmq_job (msg=0x7ff028b453f8, peer=0x7fefebcc4df8) at worker.c:184 184 if(job_queue_size(workers[i].queue) == 0) { (gdb) print i $2 = 1 (gdb) print workers[i].queue $3 = (job_queue_t *) 0x7fefebce49b0 If I configure DMQ with num_workers=1 I can't reproduce this problem. I'm using the kamailio 5.0.8 release. Is this problem known to you? What is the right way to solve it? Best Regards, Virgílio Cunha

3 7

Multiple advertise addresses per socket
by Sergiu Pojoga 25 Mar '20

25 Mar '20

Hi there, Question: how can I advertise and later match multiple FQDNs per socket? Example: auto_aliases=no alias="mydomain.net":5060 alias="mydomain.net":5061 alias="client1.mydomain.net":5060 alias="client1.mydomain.net":5061 # looks like I can advertise only one address per socket? listen=udp:65.65.65.65:5060 advertise "mydomain.net":5060 listen=tls:65.65.65.65:5061 advertise "mydomain.net":5061 Adding RR before relaying downstream like so: record_route_preset("client1.mydomain.net:5061;transport=tls;r2=on", "client1.mydomain.net:5060;r2=on"); This is the warning (just warning, works fine otherwise) after receiving for example the ACK from upstream following the 200 OK: *WARNING*: {1 19082 ACK } rr [loose.c:768]: rr_do_force_send_socket(): no socket found to match second RR (sip:client1.mydomain.net:5061 ;transport=tls;lr;r2=on) Figured warning itself can be turned off with modparam "enable_socket_mismatch_warning" of RR, still I'd like to know if I'm doing something wrong or there's a better way. Much obliged, --Sergiu

2 3

Kamailio 5.3.2 - Signal 11 on startup
by José Seabra 25 Mar '20

25 Mar '20

Hello there, I'm facing an issue with kamailio 5.3.2 when it is starting up, it breaks with signal 11 and generates a coredump file: - https://pastebin.com/FSqyGFp8 This seems to be something related to dmq module, kamailio exits with signal 11 when it receives a DMQ notification_peer message. I did a few more tests and I noticed that problem disappears if I configure DMQ with one worker only, which takes me to think that it's something related to concurrency. Best regards -- Cumprimentos José Seabra

2 7

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 March 2020