sr-dev May 2018

sr-dev@lists.kamailio.org

22 participants
214 discussions

[kamailio/kamailio] ims_isc module does not deliver to AS after asynchronous SAR to HSS (distinct PSI) (#1168)

by Christoph VALENTIN

### Description This is the same test case as I used for bug Report #1160 I used kamailio as an scscf (based on the configuration files from kamailio/examples/scscf) I did some changes according to my needs I did some Basic tests - the results were satisfying --> OK I configured a distinct PSI on the HSS (sip:04321234501@vict-ims.net) --> OK I registered some user from a Zoiper Client --> OK I told zoiper to call sip:04321234501@vict-ims.net --> I received 555 AS Contacting Failed - iFC terminated dialog ### Troubleshooting For some reason, the ims_isc module cannot deliver the Initial INVITE to the AS. First I thought, there was a bug in TM module, however there was no bug in TM module (please find the Explanation in issue #1160) The ims_isc module issues a CRITICAL log: File 2017_06_20_distinct_psi_03_scscf_kamailio.log: Line 642 - 660: Jun 20 16:14:12 vict-ims /usr/local/sbin/kamailio[108125]: INFO: ims_registrar_scscf [cxdx_avp.c:138]: cxdx_get_avp(): cxdx_get_experimental_result_code: Failed finding avp Jun 20 16:14:12 vict-ims /usr/local/sbin/kamailio[108125]: INFO: ims_registrar_scscf [cxdx_sar.c:84]: create_return_code(): created AVP successfully : [saa_return_code] - [1] Jun 20 16:14:12 vict-ims /usr/local/sbin/kamailio[108125]: ERROR: *** cfgtrace:failure_route=[UNREG_SAR_REPLY] c=[/usr/local/etc/kamailio-scscf/kamailio-scscf-routes.cfg] l=127 a=26 n=xlog Jun 20 16:14:12 vict-ims /usr/local/sbin/kamailio[108125]: ERROR: *** cfgtrace:failure_route=[UNREG_SAR_REPLY] c=[/usr/local/etc/kamailio-scscf/kamailio-scscf-routes.cfg] l=143 a=21 n=switch Jun 20 16:14:12 vict-ims /usr/local/sbin/kamailio[108125]: ERROR: *** cfgtrace:failure_route=[UNREG_SAR_REPLY] c=[/usr/local/etc/kamailio-scscf/kamailio-scscf-routes.cfg] l=130 a=26 n=xlog Jun 20 16:14:12 vict-ims /usr/local/sbin/kamailio[108125]: ERROR: *** cfgtrace:failure_route=[UNREG_SAR_REPLY] c=[/usr/local/etc/kamailio-scscf/kamailio-scscf-routes.cfg] l=131 a=5 n=route Jun 20 16:14:12 vict-ims /usr/local/sbin/kamailio[108125]: ERROR: *** cfgtrace:failure_route=[term] c=[/usr/local/etc/kamailio-scscf/kamailio-scscf-routes.cfg] l=673 a=26 n=xlog Jun 20 16:14:12 vict-ims /usr/local/sbin/kamailio[108125]: ERROR: *** cfgtrace:failure_route=[term] c=[/usr/local/etc/kamailio-scscf/kamailio-scscf-routes.cfg] l=675 a=24 n=t_newtran Jun 20 16:14:12 vict-ims /usr/local/sbin/kamailio[108125]: ERROR: tm [tm.c:1316]: w_t_newtran(): ERROR: t_newtran: transaction already in process 0x7ff2a6e66a58 Jun 20 16:14:12 vict-ims /usr/local/sbin/kamailio[108125]: ERROR: *** cfgtrace:failure_route=[term] c=[/usr/local/etc/kamailio-scscf/kamailio-scscf-routes.cfg] l=677 a=25 n=set_dlg_profile Jun 20 16:14:12 vict-ims /usr/local/sbin/kamailio[108125]: ERROR: *** cfgtrace:failure_route=[term] c=[/usr/local/etc/kamailio-scscf/kamailio-scscf-routes.cfg] l=692 a=16 n=if Jun 20 16:14:12 vict-ims /usr/local/sbin/kamailio[108125]: ERROR: *** cfgtrace:failure_route=[term] c=[/usr/local/etc/kamailio-scscf/kamailio-scscf-routes.cfg] l=685 a=25 n=is_method Jun 20 16:14:12 vict-ims /usr/local/sbin/kamailio[108125]: ERROR: *** cfgtrace:failure_route=[term] c=[/usr/local/etc/kamailio-scscf/kamailio-scscf-routes.cfg] l=686 a=63 n=assign Jun 20 16:14:12 vict-ims /usr/local/sbin/kamailio[108125]: ERROR: *** cfgtrace:failure_route=[term] c=[/usr/local/etc/kamailio-scscf/kamailio-scscf-routes.cfg] l=687 a=63 n=assign Jun 20 16:14:12 vict-ims /usr/local/sbin/kamailio[108125]: ERROR: *** cfgtrace:failure_route=[term] c=[/usr/local/etc/kamailio-scscf/kamailio-scscf-routes.cfg] l=688 a=24 n=record_route Jun 20 16:14:12 vict-ims /usr/local/sbin/kamailio[108125]: ERROR: *** cfgtrace:failure_route=[term] c=[/usr/local/etc/kamailio-scscf/kamailio-scscf-routes.cfg] l=698 a=16 n=if Jun 20 16:14:12 vict-ims /usr/local/sbin/kamailio[108125]: ERROR: *** cfgtrace:failure_route=[term] c=[/usr/local/etc/kamailio-scscf/kamailio-scscf-routes.cfg] l=692 a=26 n=isc_match_filter Jun 20 16:14:12 vict-ims /usr/local/sbin/kamailio[108125]: INFO: ims_isc [mod.c:233]: isc_match_filter(): Checking triggers Jun 20 16:14:12 vict-ims /usr/local/sbin/kamailio[108125]: CRITICAL: ims_isc [mod.c:284]: isc_match_filter(): SKIP: 0 #### Reproduction I can help to reproduce the issue. mailto:christoph.valentin@kapsch.net Currently I have got an experimental test setup using Zoiper Clients. After week 27 I should have simulated test cases to repeat the Scenario "per mouse-click" #### Debugging Data  ``` (paste your debugging data here) ``` #### Log Messages  ``` [logs-tshark-routes_2017_06_21.zip](https://github.com/kamailio/kamailio/fil… ``` #### SIP Traffic  ``` sip || diameter traffic at the s-cscf (172.29.21.23) [logs-tshark-routes_2017_06_21.zip](https://github.com/kamailio/kamailio/fil… ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` [root@vict-ims ~]# kamailio -v version: kamailio 4.4.5 (x86_64/linux) b0945e-dirty flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: b0945e -dirty compiled on 20:06:13 Jun 7 2017 with gcc 4.8.5 [root@vict-ims ~]# ``` * **Operating System**:  ``` [root@vict-ims ~]# uname -a Linux vict-ims 3.10.0-229.el7.x86_64 #1 SMP Thu Jan 29 18:37:38 EST 2015 x86_64 x86_64 x86_64 GNU/Linux [root@vict-ims ~]# ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1168

6 years, 2 months

[kamailio/kamailio] Append_to_reply does not work for XHTTP responses (#1548)

by Olle E. Johansson

Tried append_to_reply from textutils in event_route[xhttp:request] - which is not a documented usage. It did not generate an error about a bad route, but did not seem to append the header to the response. This may be a feature request, but wouldn't it be cool if it worked? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1548

6 years, 3 months

Kamailio 5.2 stable release

by Saurabh Kumar

Hi Miconda, We are using Kamailio 5.0.2 right now. We want to use recently introduced db_redis for location queries. So, can you confirm please when kamailio 5.2 stable (with db_redis) will be released (rough expectation). -- Regards, Saurabh Kumar VOIP Application Developer

6 years, 4 months

[kamailio/kamailio] 200 OK & ACK & topoh issues (#1541)

by Alexandru Pirvulescu

### Description A certain inbound provider does not return ACK R-URI as an exact copy of contact. A parameter is appended to it, like below: 200 OK Contact: `Contact: <sip:35.197.205.XXX:5060;line=sr-N6IAzJd4WxFLWxVlz.jwWB0yM.y7MlV7zGZlMlvuMx3A>` ACK R-URI: `ACK sip:35.197.205.XXX:5060;line=sr-N6IAzJd4WxFLWxVlz.jwWB0yM.y7MlV7zGZlMlvuMx3A;user=phone SIP/2.0` As you can see, the `user=phone` is appended along with `line=` put by topoh. ### Troubleshooting #### Reproduction I am not sure how this can be reproductible. I've put the URI with and without `user=phone` part in a small C app that calls kamailio's `parse_params` function and both resolved to one and two params, as expected, so the problem must come from `parse_uri`. See the debug logs below that show the difference between a "good" ACK and a "bad" ACK. `topoh` doesn't get its `line=` param, so it doesn't perform the `Contact` header rewrite. The ACK does not match a dialog/transaction and it is forwarded to itself (from internal IP to external IP, this being a kamailio behind NAT, but that's not the problem). #### Debugging Data #### Log Messages This is the "good" call, with ACK R-URI identical to Contact header. See the "+decoded" line: ``` 13(40) DEBUG: topoh [topoh_mod.c:249]: th_prepare_msg(): no second via in this message 13(40) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=as496aacd0 13(40) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 13(40) DEBUG: topoh [th_msg.c:1165]: th_route_direction(): ftag match 13(40) DEBUG: topoh [th_msg.c:763]: th_unmask_ruri(): +decoded: 34: [sip:+441274957XXX@10.32.2.133:5060] 13(40) DEBUG: topoh [topoh_mod.c:358]: th_msg_received(): adding cookie: dc 13(40) DEBUG: topoh [th_msg.c:997]: th_add_hdr_cookie(): added cookie header [TH: dch ``` This is the "bad" call, with ACK R-URI having a `user=phone` param appended to original Contact contents: ``` 10(37) DEBUG: topoh [topoh_mod.c:249]: th_prepare_msg(): no second via in this message 10(37) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=3735986184-753647 10(37) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 10(37) DEBUG: topoh [th_msg.c:1165]: th_route_direction(): ftag match 10(37) DEBUG: <core> [core/parser/parse_param.c:580]: parse_params2(): empty uri params, skipping 10(37) DEBUG: topoh [topoh_mod.c:358]: th_msg_received(): adding cookie: dc 10(37) DEBUG: topoh [th_msg.c:997]: th_add_hdr_cookie(): added cookie header [TH: dch ``` #### SIP Traffic ``` U 2018/05/21 10:22:53.206320 35.197.205.XXX:5060 -> 88.215.58.YYY:5060 SIP/2.0 200 OK. Via: SIP/2.0/UDP 88.215.58.YYY:5060;rport=5060;branch=z9hG4bK469d20c71c138e366475cd537dc0c68b. Record-Route: <sip:35.197.205.XXX;lr;ftag=3735908572-610467;vsf=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAACQgAAQMbFhsLHTE1OjUwNjA7dXNlcj1waG9uZQ--;did=f17.b7f>. From: <sip:+16098378XXX@88.215.58.YYY;user=phone>;tag=3735908572-610467. To: <sip:+441242395XXX@88.215.58.YYY:5060;user=phone>;tag=as3147fc45. Call-ID: 5577511-3735908572-610459(a)MSX163.XXX.com. CSeq: 1 INVITE. Server: Asterisk PBX 1.8.28-cert5. Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE. Supported: replaces. Contact: <sip:35.197.205.XXX:5060;line=sr-N6IAzJd4WxFLWxVlz.jwWB0yM.y7MlV7zGZlMlvuMx3A>. Content-Type: application/sdp. Content-Length: 259. . v=0. o=root 1611167628 1611167628 IN IP4 35.197.206.251. s=Asterisk PBX 1.8.28-cert5. c=IN IP4 35.197.206.251. t=0 0. m=audio 10948 RTP/AVP 8 101. a=rtpmap:8 PCMA/8000. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-16. a=ptime:20. a=sendrecv. a=rtcp:10949. U 2018/05/21 10:22:53.206827 88.215.58.YYY:5060 -> 35.197.205.XXX:5060 ACK sip:35.197.205.XXX:5060;line=sr-N6IAzJd4WxFLWxVlz.jwWB0yM.y7MlV7zGZlMlvuMx3A;user=phone SIP/2.0. Max-Forwards: 68. Route: <sip:35.197.205.XXX;lr;ftag=3735908572-610467;vsf=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA7dXNlcj1waG9uZQ--;vst=AAAAAAAAAAAAAAAAAAAAAAAACQgAAQMbFhsLHTE1OjUwNjA7dXNlcj1waG9uZQ--;did=f17.b7f>. To: <sip:+441242395XXX@88.215.58.YYY:5060;user=phone>;tag=as3147fc45. From: <sip:+16098378XXX@88.215.58.YYY;user=phone>;tag=3735908572-610467. Call-ID: 5577511-3735908572-610459(a)MSX163.XXX.com. CSeq: 1 ACK. Allow: PUBLISH,MESSAGE,UPDATE,SUBSCRIBE,REFER,INFO,NOTIFY,OPTIONS,BYE,INVITE,ACK,CANCEL. Via: SIP/2.0/UDP 88.215.58.15:5060;branch=z9hG4bK6c862e8111736dc6d7d22479393d1f2d. Contact: <sip:+16098378YYY@88.215.58.YYY:5060>. Content-Length: 0. ``` ### Possible Solutions Changed the provider to avoid downtime, but the `empty uri params, skipping` error from `parse_params2` is strange, considering that we do not have a single param but 2. ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.0.4 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 5.4.0 ``` * **Operating System**: ``` Linux gke-lon-1-sbc-in-082a7447-9rll 4.13.0-1011-gcp #15-Ubuntu SMP Mon Feb 12 16:29:04 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1541

6 years, 4 months

[kamailio/kamailio] app_java: gcj is been removed from gcc since gcc7 (#1487)

by Victor Seva

>From debian bugreport https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892538 ``` Source: kamailio Severity: serious Tags: sid buster User: debian-gcc(a)lists.debian.org Usertags: gcj-rm Hi, kamailio depends or build-depends on GCJ. GCJ has been dropped upstream since GCC 7, so we are dropping it from Debian. Thus please either drop support for GCJ if you are just building an alternative package with GCJ support (e.g. ant-gcj, ecj-gcj) or switch to default-jdk / default-jre as appropriate. Cheers, Emilio ``` >From https://gcc.gnu.org/gcc-7/changes.html ``` Java (GCJ) The GCC Java frontend and associated libjava runtime library have been removed from GCC. ``` Can the ``app_java`` module be built with openjdk-9-jdk? -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1487

6 years, 4 months

[kamailio/kamailio] when using jsonrpcc module it reports as follow (#1520)

by theblackworld

May 3 20:18:09 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46727]: INFO: jsonrpc-c [jsonrpc_io.c:488]: connect_servers(): Connecting to servers for priority 2: May 3 20:18:09 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46727]: INFO: jsonrpc-c [jsonrpc_io.c:494]: connect_servers(): Connected to host 219.216.65.195 on port 9999 May 3 20:18:09 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46726]: INFO: ctl [io_listener.c:214]: io_listen_loop(): io_listen_loop: using epoll_lt io watch method (config) May 3 20:18:19 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46708]: INFO: jsonrpc-c [jsonrpc_request.c:66]: jsonrpc_request(): jsonrp_requestctmb address is 0x7f741674e440 May 3 20:18:19 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46708]: ERROR: jsonrpc-c [jsonrpc_request.c:94]: jsonrpc_request(): START TM MODULE May 3 20:18:19 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46708]: ERROR: jsonrpc-c [jsonrpc_request.c:95]: jsonrpc_request(): hash is 4976 May 3 20:18:19 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46708]: ERROR: jsonrpc-c [jsonrpc_request.c:96]: jsonrpc_request(): label is 181128518 May 3 20:18:19 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46727]: INFO: jsonrpc-c [jsonrpc_io.c:189]: cmd_pipe_cb(): SEND STRING IS87:{ "id": 2, "jsonrpc": "2.0", "method": "start", "params": { "sdp": "aa", "id": 1000 } }, May 3 20:18:19 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46727]: ERROR: jsonrpc-c [netstring.c:73]: netstring_read_fd(): bytes is 99 May 3 20:18:19 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46727]: ERROR: jsonrpc-c [netstring.c:74]: netstring_read_fd(): read_len is 99 May 3 20:18:19 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46727]: INFO: jsonrpc-c [jsonrpc_io.c:281]: socket_cb(): NETSTRING IS{"jsonrpc":"2.0","id":2,"result":"This is result!","params":{"sdpAnswer":"This is sdpAnswer!"}} May 3 20:18:19 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46727]: INFO: jsonrpc-c [jsonrpc.c:96]: handle_jsonrpc_response(): id is 2 May 3 20:18:19 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46727]: INFO: jsonrpc-c [jsonrpc.c:105]: handle_jsonrpc_response(): GET THE RESULT step one May 3 20:18:19 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46727]: INFO: jsonrpc-c [jsonrpc.c:107]: handle_jsonrpc_response(): PROCESS THE STEP TWO May 3 20:18:19 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46727]: INFO: jsonrpc-c [jsonrpc_io.c:130]: result_cb(): 2 May 3 20:18:19 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46727]: INFO: jsonrpc-c [jsonrpc_io.c:134]: result_cb(): action s address 0x7f741b3b73c0 May 3 20:18:19 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46727]: INFO: jsonrpc-c [jsonrpc_io.c:135]: result_cb(): action ss adress 0x7ffe40907dd0 May 3 20:18:19 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46727]: INFO: jsonrpc-c [jsonrpc_io.c:136]: result_cb(): t_hash4976 May 3 20:18:19 lwm-PowerEdge-R720 kernel: [4074069.476634] kamailio[46727]: segfault at 38 ip 00007f7418b148a0 sp 00007ffe40907580 error 4 in tm.so[7f7418a50000+11e000] May 3 20:18:19 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46727]: INFO: jsonrpc-c [jsonrpc_io.c:137]: result_cb(): t_label181128518 May 3 20:18:19 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46727]: INFO: jsonrpc-c [jsonrpc_io.c:140]: result_cb(): tmb address is 0x7f741674e440 May 3 20:18:20 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46745]: CRITICAL: <core> [pass_fd.c:277]: receive_fd(): EOF on 5 May 3 20:18:20 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46694]: ALERT: <core> [main.c:727]: handle_sigs(): child process 46727 exited by a signal 11 May 3 20:18:20 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46694]: ALERT: <core> [main.c:730]: handle_sigs(): core was generated May 3 20:18:20 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46694]: INFO: <core> [main.c:743]: handle_sigs(): terminating due to SIGCHLD May 3 20:18:20 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46745]: INFO: <core> [main.c:798]: sig_usr(): signal 15 received May 3 20:18:20 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46743]: INFO: <core> [main.c:798]: sig_usr(): signal 15 received May 3 20:18:20 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46741]: INFO: <core> [main.c:798]: sig_usr(): signal 15 received May 3 20:18:20 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46726]: INFO: <core> [main.c:798]: sig_usr(): signal 15 received May 3 20:18:20 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46700]: INFO: <core> [main.c:798]: sig_usr(): signal 15 received May 3 20:18:20 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46699]: INFO: <core> [main.c:798]: sig_usr(): signal 15 received May 3 20:18:20 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46697]: INFO: <core> [main.c:798]: sig_usr(): signal 15 received May 3 20:18:20 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46701]: INFO: <core> [main.c:798]: sig_usr(): signal 15 received May 3 20:18:20 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46712]: INFO: <core> [main.c:798]: sig_usr(): signal 15 received May 3 20:18:20 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46703]: INFO: <core> [main.c:798]: sig_usr(): signal 15 received May 3 20:18:20 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46708]: INFO: <core> [main.c:798]: sig_usr(): signal 15 received May 3 20:18:20 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46716]: INFO: <core> [main.c:798]: sig_usr(): signal 15 received May 3 20:18:20 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46702]: INFO: <core> [main.c:798]: sig_usr(): signal 15 received May 3 20:18:20 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46695]: INFO: <core> [main.c:798]: sig_usr(): signal 15 received May 3 20:18:20 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46704]: INFO: <core> [main.c:798]: sig_usr(): signal 15 received May 3 20:18:20 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46698]: INFO: <core> [main.c:798]: sig_usr(): signal 15 received May 3 20:18:20 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46710]: INFO: <core> [main.c:798]: sig_usr(): signal 15 received May 3 20:18:20 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46731]: INFO: <core> [main.c:798]: sig_usr(): signal 15 received May 3 20:18:20 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46733]: INFO: <core> [main.c:798]: sig_usr(): signal 15 received May 3 20:18:20 lwm-PowerEdge-R720 /usr/local/sbin/kamailio[46696]: INFO: <core> [main.c:798]: sig_usr(): signal 15 received -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1520

6 years, 4 months

[kamailio/kamailio] gentoo can be removed from the install documentation (#1530)

by noci2012

AFAICT kamailio ebuild was removed from net-misc quite some time ago. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1530

6 years, 4 months

[kamailio/kamailio] str_hash: Option to allocate hash in shm (#1535)

by Alfonso Pinto

Added an allocator function to allocate the hash in shared memory. Added also locking stuff   #### Pre-Submission Checklist    - [X] Commit message has the format required by CONTRIBUTING guide - [X] Commits are split per component (core, individual modules, libs, utils, ...) - [X] Each component has a single commit (if not, squash them into one commit) - [X] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [X] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [X] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  Added a new allocator function to str_hash.h. This new function allows to allocate the hash table in shared memory. Changes to struct str_hash_table: - Added a gen_lock_set_t (locks) to hold the lock set - Added an int (locks_no) to hold the number of locks - Added an indicator (memory) to know if the table was allocated in private memory (p) or shared memory(s) Changes to struct str_hash_head: - Added an int(lock_idx) that hold the index of the lock when the head is locked. Changes to struct str_hash_entry: - Added a pointer to the head the entry belongs to. This allows to unlock the head when needed. Added functions to lock and unlock the head when needed. Modified functions str_hash_add and str_hash_get to lock the head when needed Added function str_hash_destroy to remove the hash table and all its contents from memory. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/1535 -- Commit Summary -- * str_hash: Option to allocate hash in shm -- File Changes -- M src/core/str_hash.h (100) -- Patch Links -- https://github.com/kamailio/kamailio/pull/1535.patch https://github.com/kamailio/kamailio/pull/1535.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/1535

6 years, 4 months

[kamailio/kamailio] t_relay() sending packets from the wrong TCP socket (#1532)

by Jared Hull

### Description Kamailio is using the wrong source port when relaying INVITE packets with t_relay(). Another interesting thing is that while doing this, Kamailio reports to Homer via HEPv2 that it sent the packet from port 4242, but a tcpdump on the server shows this to be false so maybe homer was just looking at the R-URI port? There is a somewhat random element to this, so it is very difficult to reproduce. I will provide the scenario which led to this problem. #### Reproduction This is the code block which is responsible for relaying INVITEs to phone from our PBX servers, it is also the only instance of port 5062 being inserted into a SIP message. ``` if(is_method("INVITE")) { if(lookup("location", "sip:$rU@location")) { remove_hf("Contact"); append_hf("Contact: <sip:$sel(cfg_get.global.publicIP):5062>\r\n"); //A vendor's SIPIS server doesn't work on port 4242, does changing this port break SIP compliance? rtpproxy_manage("cow"); t_relay(); exit; } } ``` - Kamailio listens for UDP+TCP on ports 5060,5062, and 4242. - Phone A registers to tcp:KamailioIP:4242 from tcp:CustomerIP:10042 - Phone B registers to tcp:KamailioIP:4242 from tcp:CustomerIP:11042 - These phones have been re-registering from and to the same ports for a long time without problems with the same REGISTER callID (same transaction so nothing about the connection has changed). - At this point we have TCP connections `tcp:CustomerIP:10042 -> tcp:KamailioIP:4242` and `tcp:CustomerIP:11042 -> tcp:KamailioIP:4242` - Kamailio sends INVITEs from tcp:KamailioIP:4242 to the address of the registered phone with a contact header that tells the phones to send responses to tcp:KamailioIP:5062 (as seen in the above code block). This causes a new TCP connection to be made from the customer's router to Kamailio, just for this transaction. - All is well until phone A sends a response and the customer's router, by pure chance, decides to use port 11042 for the new TCP connection. `tcp:CustomerIP:11042 -> tcp:KamailioIP:5062` - From this point on Kamailio begins to route INVITEs, that were meant for phone B, to phone A using this TCP connection `tcp:CustomerIP:11042 -> tcp:KamailioIP:5062` (source port 5062!) rather than the connection that phone B is actually registered to `tcp:CustomerIP:11042 -> tcp:KamailioIP:4242`. - The customer's router sends packets from this TCP socket to phone A because the connection identified by the Kamailio source port had been created by phone A. - Kamailio is still routing other types of packets to phone B from port 4242 like NOTIFY in response to a subscription and OPTIONs keep alives, but INVITEs (which are an entirely new SIP transaction) are being sent from the wrong source port. ### Possible ~Solutions~ Problems I have the default tcp_accept_aliases=0, so ;alias in a Via header is not a problem. We are also not using force_send_socket. I've tried to figure out how Kamailio works, and I am wondering if this function might be adding the new TCP connection from phone A to port 5062 as an alias of the already existing TCP connection from phone B to port 4242. https://github.com/kamailio/kamailio/blob/cb7810c939da9c8f4385b530539487528… I also found these comments interesting. https://github.com/kamailio/kamailio/blob/52111974b4571e0562e8e731df80f48db… https://github.com/kamailio/kamailio/blob/52111974b4571e0562e8e731df80f48db… ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.0.5 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled on 04:38:13 Feb 2 2018 with gcc 4.8.5 ``` * **Operating System**: ``` Linux dallas-sip1-int 3.10.0-514.16.1.el7.x86_64 #1 SMP Wed Apr 12 15:04:24 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux ``` -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/1532

6 years, 5 months

[kamailio/kamailio] tm: add relay_100 config parameter to support stateless operation (#1534)

by Armen Babikyan

#### Pre-Submission Checklist    - [ ] Commit message has the format required by CONTRIBUTING guide - [ ] Commits are split per component (core, individual modules, libs, utils, ...) - [ ] Each component has a single commit (if not, squash them into one commit) - [ ] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated) #### Type Of Change - [ ] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality) #### Checklist:  - [ ] PR should be backported to stable branches - [ ] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number) #### Description  You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/1534 -- Commit Summary -- * tm: add relay_100 config parameter to support stateless operation -- File Changes -- M src/modules/tm/config.c (5) M src/modules/tm/config.h (1) M src/modules/tm/t_reply.c (2) M src/modules/tm/tm.c (1) -- Patch Links -- https://github.com/kamailio/kamailio/pull/1534.patch https://github.com/kamailio/kamailio/pull/1534.diff -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/1534

6 years, 5 months

← Newer
1
...
4
5
6
7
8
9
10
...
22
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev May 2018