sr-users July 2020

sr-users@lists.kamailio.org

58 participants
88 discussions

by Marat Gareev

Hello, I have a customized Kamailio (kamailio 5.1.1 (x86_64/linux)), xHTTP_PROM <https://www.kamailio.org/docs/modules/devel/modules/xhttp_prom.html> was released in the 5.3.0 <https://www.kamailio.org/w/kamailio-v5-3-0-release-notes/> version. I'm trying to import the latest version of xhttp_prom to older Kamailio, but something goes wrong. This is simple config for test: log_stderror=yes > listen=5060 > debug=2 > mpath="/home/devel/build_dir/build/lib64/kamailio/modules" > loadmodule "tm.so" > loadmodule "sl.so" > loadmodule "xlog.so" > loadmodule "pv.so" > disable_tcp=no > tcp_accept_no_cl=yes > loadmodule "xhttp.so" > loadmodule "xhttp_prom.so" > modparam("xhttp_prom", "xhttp_prom_stats", "all") > route { > sl_send_reply("200", "OK"); > exit; > } > event_route[xhttp:request] { > if (prom_check_uri()) { > prom_dispatch(); > } else { > xhttp_reply("404", "Not Found", "text/plain", "Wrong URL $hu\n"); > } > } then I send HTTP request $ curl http://localhost:5060/metrics but get error: > 6(110968) CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 11 > 0(110962) ALERT: <core> [main.c:746]: handle_sigs(): child process 110967 > exited by a signal 11 > 0(110962) ALERT: <core> [main.c:749]: handle_sigs(): core was generated > 0(110962) INFO: <core> [main.c:771]: handle_sigs(): terminating due to > SIGCHLD note: for http://localhost:5060/test request I get the expected message "Wrong URL /test". Backtrace for killed process > (gdb) c > Continuing. > Program received signal SIGSEGV, Segmentation fault. > 0x00007fefff3ff096 in atomic_cmpxchg_int (var=0x0, old=0, new_v=1) at > ../../core/mem/../atomic/atomic_x86.h:224 > 224 ATOMIC_FUNC_CMPXCHG(cmpxchg, "cmpxchgl %2, %1", int , int) > (gdb) bt > #0 0x00007fefff3ff096 in atomic_cmpxchg_int (var=0x0, old=0, new_v=1) at > ../../core/mem/../atomic/atomic_x86.h:224 > #1 0x00007fefff3ff0e2 in futex_get (lock=0x0) at > ../../core/mem/../futexlock.h:99 > #2 0x00007fefff4130bf in prom_metric_list_print (ctx=0x7fefff628da0 > <ctx>) at prom_metric.c:1319 > #3 0x00007fefff416468 in prom_stats_get (ctx=0x7fefff628da0 <ctx>, > stat=0x7fefff6281f0 <xhttp_prom_stats>) at prom.c:178 > #4 0x00007fefff3d4d10 in prom_send (ctx=0x7fefff628da0 <ctx>) at > xhttp_prom.c:361 > #5 0x00007fefff3d5faf in ki_xhttp_prom_dispatch (msg=0x7ffecb730ee0) at > xhttp_prom.c:418 > #6 0x00007fefff3d5feb in w_prom_dispatch (msg=0x7ffecb730ee0) at > xhttp_prom.c:428 > #7 0x0000000000461dbe in do_action (h=0x7ffecb730e00, a=0x7ff0007c7b78, > msg=0x7ffecb730ee0) at core/action.c:1067 > #8 0x000000000046e571 in run_actions (h=0x7ffecb730e00, a=0x7ff0007c7b78, > msg=0x7ffecb730ee0) at core/action.c:1565 > #9 0x0000000000461d2d in do_action (h=0x7ffecb730e00, a=0x7ff0007ca628, > msg=0x7ffecb730ee0) at core/action.c:1058 > #10 0x000000000046e571 in run_actions (h=0x7ffecb730e00, a=0x7ff0007c76f8, > msg=0x7ffecb730ee0) at core/action.c:1565 > #11 0x00007fefff62f649 in xhttp_process_request (orig_msg=0x7ff0007ebbd8, > new_buf=0x7ff0007cc280 "GET /metrics HTTP/1.1\r\nVia: SIP/2.0/TCP > 127.0.0.1:37000\r\nUser-Agent: curl/7.29.0\r\nHost: > localhost:5060\r\nAccept: */*\r\n\r\n", new_len=119) at xhttp_mod.c:298 > #12 0x00007fefff630d78 in xhttp_handler (msg=0x7ff0007ebbd8) at > xhttp_mod.c:385 > #13 0x0000000000520141 in nonsip_msg_run_hooks (msg=0x7ff0007ebbd8) at > core/nonsip_hooks.c:111 > #14 0x000000000058cef1 in receive_msg (buf=0x7feffee65bb0 "GET /metrics > HTTP/1.1\r\nUser-Agent: curl/7.29.0\r\nHost: localhost:5060\r\nAccept: > */*\r\n\r\n", len=85, rcv_info=0x7feffee658d0) > at core/receive.c:216 > #15 0x000000000061233f in receive_tcp_msg (tcpbuf=0x7feffee65bb0 "GET > /metrics HTTP/1.1\r\nUser-Agent: curl/7.29.0\r\nHost: > localhost:5060\r\nAccept: */*\r\n\r\n", len=85, rcv_info=0x7feffee658d0, > con=0x7feffee658b8) at core/tcp_read.c:1379 > #16 0x000000000061479e in tcp_read_req (con=0x7feffee658b8, > bytes_read=0x7ffecb731c7c, read_flags=0x7ffecb731c78) at > core/tcp_read.c:1611 > #17 0x00000000006174e9 in handle_io (fm=0x7ff0007d9720, events=1, idx=-1) > at core/tcp_read.c:1785 > #18 0x00000000006069b4 in io_wait_loop_epoll (h=0xaa76c0 <io_w>, t=2, > repeat=0) at core/io_wait.h:1065 > #19 0x00000000006194ff in tcp_receive_loop (unix_sock=14) at > core/tcp_read.c:1955 > #20 0x00000000004f1a43 in tcp_init_children () at core/tcp_main.c:4853 > #21 0x0000000000423f99 in main_loop () at main.c:1716 > #22 0x000000000042a5ee in main (argc=9, argv=0x7ffecb7323b8) at main.c:2646 > (gdb) > (gdb) p 'prom_metric.c'::prom_lock > $4 = (gen_lock_t *) 0x0 If I understood correctly, the problem is in an uninitialized variable static gen_lock_t *prom_lock = NULL; /* Lock to protect Prometheus metrics. */ So, is it possible to import xHTTP_PROM to older Kamailio? I will be glad for any advice. Thanks.

4 years, 4 months

loose_route failing with topos ?

by Mark Boyce

Hi all Just enabled topos with redis backend (topos/topos_redis/ndb_redis) The interesting bits of the calls are going from kamailio (5.3.5) to Asterisk with topos enabled for that leg All seems to be ok until the far end (Asterisk) sends a BYE. At which point kamailo passes message to WITHINDLG, in loose_route comes up false (-1) and the BYE gets missed, falling through to the “404 Not here” at the end of WITHINDLG. I’m guessing that loose_route should be able to “see inside” topos, or should I be throwing loose_route away when using topos? Happy to upgrade to 5.4 and do diags if it appears to be a bug. Best regards Mark -- Mark Boyce Dark Origins Ltd

4 years, 4 months

rtcp-mux is missing in the OK for WebRTC-Calls

by Benjamin Flügel | vio:networks

Hey guys, I'm trying to configure a Kamailio to work with a browser softphone based on SIPJS using WebRTC. So far it works great on Firefox but have a specific problem with chrome, when I want to make call from the softphone to another extension. After anwsering the call Chrome/the softphone sends a BYE immediately, because this line "a=rtcp-mux" is missing in the OK. The Kamailio is a proxy. Behind the Kamailio there is an Asterisk, which is responsible for the pbx-features. Those are my rtpengine Flags for the Invite: rtpengine_manage: replace-origin replace-session-connection trust-address via-branch=extra rtcp-mux-demux DTLS=off SDES-on ICE=remove RTP/AVP And those are the flags for the response, in this case the OK: rtpengine_manage: replace-origin replace-session-connection rtcp-mux-offer rtcp-mux-accept generate-mid DTLS=off SDES-on ICE=force RTP/SAVPF direction=internal direction=external loop-protect It seems that the Kamailio ignores ths "rtcp-mux-offer rtcp-mux-accept" in the response. Can you help me get it to work? Here is the SIP-Dialog. The call is from extension 201 to the extension 2. INVITE: INVITE sip:2@mydomain SIP/2.0 Via: SIP/2.0/WSS g4n0lpfirgpv.invalid;branch=z9hG4bK5104892 To: <sip:2@mydomain.com> From: <sip:201@mydomain.com>;tag=aqplr71k05 CSeq: 2 INVITE Call-ID: sde09v49f8gqtt59oddn Max-Forwards: 70 Proxy-Authorization: Digest algorithm=MD5, username="201", realm="mydomain.com", nonce="sfdsdfdsfsdfdsfsdfaseqww", uri="sip:2@mydomain.com", response="81rewtrega23423r" Contact: <sip:kf6iduon@g4n0lpfirgpv.invalid;transport=ws;ob> Allow: ACK,CANCEL,INVITE,MESSAGE,BYE,OPTIONS,INFO,NOTIFY,REFER Supported: outbound User-Agent: SIPJS Content-Type: application/sdp Content-Length: 1916 v=0 o=- 5826889093965459811 2 IN IP4 127.0.0.1 s=- t=0 0 a=group:BUNDLE 0 a=msid-semantic: WMS Jk5GQwzPaVSTxyIZER7RBqkkMNWCdmKmMdyO m=audio 54274 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126 c=IN IP4 mycomputerIP a=rtcp:9 IN IP4 0.0.0.0 a=candidate:1577908739 1 udp 2113937151 efd6d297-d186-4c07-87d8-933e5846a82d.local 54274 typ host generation 0 network-cost 999 a=candidate:842163049 1 udp 1677729535 mycomputerIP 54274 typ srflx raddr 0.0.0.0 rport 0 generation 0 network-cost 999 a=ice-ufrag:Ktxl a=ice-pwd:x5xDUb41GeOXAcHNQlra4yUN a=ice-options:trickle a=fingerprint:sha-256 2C:7C:32:AF:34:A3:9D:AE:C7:FD:92:68:DD:D8:AB:82:DB:F0:32:51:14:97:20:60:66:5C:2F:CF:B7:98:B8:A8 a=setup:actpass a=mid:0 a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01 a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id a=sendrecv a=msid:Jk5GQwzPaVSTxyIZER7RBqkkMNWCdmKmMdyO dc187be3-4cd0-4129-98e4-f804cd8d2c94 a=rtcp-mux a=rtpmap:111 opus/48000/2 a=rtcp-fb:111 transport-cc a=fmtp:111 minptime=10;useinbandfec=1 a=rtpmap:103 ISAC/16000 a=rtpmap:104 ISAC/32000 a=rtpmap:9 G722/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:106 CN/32000 a=rtpmap:105 CN/16000 a=rtpmap:13 CN/8000 a=rtpmap:110 telephone-event/48000 a=rtpmap:112 telephone-event/32000 a=rtpmap:113 telephone-event/16000 a=rtpmap:126 telephone-event/8000 a=ssrc:2376769177 cname:RgPkYyxDrEJTpmO2 a=ssrc:2376769177 msid:Jk5GQwzPaVSTxyIZER7RBqkkMNWCdmKmMdyO dc187be3-4cd0-4129-98e4-f804cd8d2c94 a=ssrc:2376769177 mslabel:Jk5GQwzPaVSTxyIZER7RBqkkMNWCdmKmMdyO a=ssrc:2376769177 label:dc187be3-4cd0-4129-98e4-f804cd8d2c94 RINGING: SIP/2.0 180 Ringing Via: SIP/2.0/WSS g4n0lpfirgpv.invalid;rport=60196;received=mycomputerIP;branch=z9hG4bK5104892 Record-Route: <sip:internalIP;r2=on;lr=on;ftag=aqplr71k05;nat=yes;rtp=ws> Record-Route: <sip:externalIP;transport=ws;r2=on;lr=on;ftag=aqplr71k05;nat=yes;rtp=ws> From: <sip:201@mydomain.com>;tag=aqplr71k05 To: <sip:2@mydomain.com>;tag=as64fe0fc8 Call-ID: sde09v49f8gqtt59oddn CSeq: 2 INVITE Server: myserver Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Contact: <mycontact> P-Asserted-Identity: "Phone 2" <sip:2@mydomain.com> Content-Length: 0 OK: SIP/2.0 200 OK Via: SIP/2.0/WSS g4n0lpfirgpv.invalid;rport=60196;received=mycomputerIP;branch=z9hG4bK5104892 Record-Route: <sip:internal-ip;r2=on;lr=on;ftag=aqplr71k05;nat=yes;rtp=ws> Record-Route: <sip:external-ip;transport=ws;r2=on;lr=on;ftag=aqplr71k05;nat=yes;rtp=ws> From: <sip:201@mydomain.com>;tag=aqplr71k05 To: <sip:2@mydomain.com>;tag=as64fe0fc8 Call-ID: sde09v49f8gqtt59oddn CSeq: 2 INVITE Server: myserver Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE Supported: replaces, timer Contact: <mycontact> P-Asserted-Identity: "Phone 2" <sip:2@mydomain.com> Content-Type: application/sdp Content-Length: 806 v=0 o=root 882840402 882840402 IN IP4 externalIP s=Asterisk PBX 11.22.0 c=IN IP4 externalIP t=0 0 a=rtpengine:4d633e3022f5 m=audio 16416 RTP/SAVPF 111 9 8 0 126 a=maxptime:60 a=mid:0 a=rtpmap:111 opus/48000/2 a=rtpmap:9 G722/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:126 telephone-event/8000 a=fmtp:111 maxplaybackrate=16000; stereo=0; sprop-stereo=0; useinbandfec=0 a=fmtp:126 0-16 a=sendrecv a=rtcp:16417 a=setup:active a=fingerprint:sha-1 B1:67:4B:B8:47:89:E8:49:CD:DD:F8:FF:41:5C:83:72:D9:DE:4D:45 a=ptime:20 a=ice-ufrag:WBZN8m7c a=ice-pwd:mKVR6Jv0G0pvrTv7OfEm2wPW9Q a=ice-options:trickle a=candidate:3kddB3zBUV2n2jt0 1 UDP 2130706431 externalIP 16416 typ host a=candidate:3kddB3zBUV2n2jt0 2 UDP 2130706430 externalIP 16417 typ host a=end-of-candidates I hope, you can help me with this. If you have further question, I will try to answer them as best I can. Greetings, Ben

4 years, 4 months

Development is open for future release of v5.5.x series

by Daniel-Constantin Mierla

Hello, the branch 5.4 was created, therefore the master branch is open for adding new features, to be part of future release series v5.5.x. Any bug fix committed to master that applies to 5.4.x or older stable branches should be backported as usual with "git cherry-pick -x ..." to appropriate branches like 5.4 or 5.3. Expect that v5.4.0 will be released in a few weeks from now. Based on the workflow used during the past years, the next future release v5.5.0 should be out after another 8-10 months of development, plus 1-2 months of testing, so sometime in the first part of 2021. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

4 years, 4 months

Branch 5.4 has been created

by Daniel-Constantin Mierla

Hello, the branch 5.4 has been created, to be used for releasing v5.4.x series. To check out this branch, the following commands can be used: git clone https://github.com/kamailio/kamailio kamailio-5.4 cd kamailio-5.34 git checkout -b 5.4 origin/5.4 Pushing commits in this branch: git push origin 5.4:5.4 Note that 5.4 is an official stable branch, so only bug fixes, missing kemi exports (discuss on sr-dev if not sure) or improvements to documentation or helper tools can be pushed to this branch. As usual, if there is a bug fixed, commit and push first to master branch and then cherry pick to 5.4 branch: git cherry-pick -x COMMITID In few weeks, the first release from branch 5.4 will be out, respectively Kamailio v5.4.0. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda

4 years, 4 months

Drop local generated requests

by Patrick Wakano

Hello list, Hope you all doing fine! I have a case where I want to drop a local generated request but it looks like you can't drop the request from the tm:local-request route. I found this ticket https://github.com/kamailio/kamailio/issues/980, but I could not find somewhere in the docs or emails definitely saying that drop() is not supported from tm:local-request.... And in case we definitely can't drop the request in there, any ideas on how to avoid a local generated request of going out? I am specifically interested in dropping Registers from the uacreg module under certain situations, but I don't want to disable it or delete it from the DB.... Thank you, Kind regards, Patrick Wakano

4 years, 4 months

Help on dumping running config in Kamailio

by BALL SUN

Hi I need an urgent help, I accidentally pipe the output to the kamailio config, and now I lost the copy of my latest setting, is there a chance that I can dump the running config back to file? Thanks PLEASE HELP RBK

4 years, 4 months

Branching 5.4 in git repository

by Daniel-Constantin Mierla

Hello, so far it looks pretty calm during the testing phase, some static analysis didn't reveal any new major issues (well, this is done also during development phase). Therefore, if nothing else is proposed or shows up, I am considering to create the git branch 5.4 next week on Thursday -- this branch will hold the code for 5.4.x release series. After branching 5.4, the master branch will be open again for new features. The 5.4.0 enters the release candidate phase, likely to have the first release out in 1-2 weeks after branching. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla

4 years, 4 months

Maintenance work on kamailio.org server - Wed, July 8, 2020

by Daniel-Constantin Mierla

Hello, on Wednesday, July 8, 2020, there will be some work on Kamailio project infrastructure. Therefore there could be short intervals of downtime for online resources like the web server, wiki, documentation and downloads portals, mailing lists or the GIT repository mirror. Once the maintenance work is finished, we will post an update. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Funding: https://www.paypal.me/dcmierla

4 years, 4 months

30X redirect in interconnects - better alternative?

by Gerry | Rigatta.com

Hi, I would like to use Kamailio for load balancing incoming carrier traffic. We do currently IP authentication and call logic in Yate boxes. Ideally I would like to distribute calls with 30X redirects with the Kamailio dispatcher so that IP authentication and all logic can stay in the Yate boxes. However I have doubts that 30X redirects are generally accepted in interconnects. What is your experience with this? What is the possible alternative to redirects if one wants to keep IP authentication and call logic in the boxes behind the Kamailio SIP router? E.g. how can one reliably check the carrier source IPs behind Kamailio? Custom headers injected by Kamailio? Of cause I can check source IPs with a database lookup in Kamailio but I try to avoid that as this makes the setup much more complicated and error prone. Thank you for your ideas. Gerry

4 years, 4 months

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

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