sr-users January 2020

sr-users@lists.kamailio.org

80 participants
94 discussions

pipelimit: inexistent pipe error logs
by Nuno Ferreira 20 Mar '20

20 Mar '20

Hi all, I'm using pipelimit with the "clean_unused" option to get rid of pipes that are not used for quite some time. At the same time we are monitoring pipelimit with a jsonrpc call similar to: # curl --header 'Content-Type: application/json' --data-binary '{"id": 1, "jsonrpc": "2.0", "method": "pl.list", "params": ["pipe_INVITE"]' http://127.0.0.1:8000/RPC Reply: { "jsonrpc": "2.0", "error": { "code": 400, "message": "Unknown pipe id pipe_INVITE" }, "id": 1 } The above reply is valid because the pipe_INVITE was not loaded yet, but the request makes kamailio to log the following log messages: Jan 20 11:21:48 proxy1 kamailio[24474]: ERROR: pipelimit [pl_ht.c:519]: rpc_pl_list(): no pipe: pipe_INVITE Jan 20 11:21:48 proxy1 kamailio[24474]: ERROR: <core> [core/parser/parse_fline.c:262]: parse_first_line(): parse_first_line: bad message (offset: 20) Jan 20 11:21:48 proxy1 kamailio[24474]: [466B blob data] Since the monitoring system does periodic requests, those log lines get a bit annoying and fill the log with ERROR messages that aren't really errors. IMHO the first log line should be converted to DEBUG instead of ERROR, but I have some doubts about the one from parse_fline.c:262. parse_first_line() is used to process both SIP and HTTP. It makes sense to log ERROR if SIP but not in the case of HTTP... Regarding the "[466B blob data]" I really don't know from where it's coming from. I can submit a PR, but I would like to have first some feedback from you. Thank you, Nuno -- *Confidentiality Notice: The information contained in this e-mail and any attachments may be confidential. If you are not an intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please notify the sender and permanently delete the e-mail and any attachments immediately. You should not retain, copy or use this e-mail or any attachment for any purpose, nor disclose all or any part of the contents to any other person. Thank you.*

3 10

systemd - properly starting up rtpengine with kernel forwarding
by Daniel-Constantin Mierla 17 Mar '20

17 Mar '20

Hello, do people here have (implemented) special ways to properly start rtpengine with kernel forwarding after system reboot? >From rtpengine readme: """ A typical start-up sequence including in-kernel forwarding might look like this: # this only needs to be one once after system (re-) boot modprobe xt_RTPENGINE iptables -I INPUT -p udp -j RTPENGINE --id 0 ip6tables -I INPUT -p udp -j RTPENGINE --id 0 # ensure that the table we want to use doesn't exist - usually needed after a daemon # restart, otherwise will error echo 'del 0' > /proc/rtpengine/control # start daemon /usr/sbin/rtpengine --table=0 --interface=10.64.73.31 --interface=2001:db8::4f3:3d \ --listen-ng=127.0.0.1:2223 --tos=184 --pidfile=/run/rtpengine.pid --no-fallback """ I was relying on shell scripts executed on boot time, but now that systemd is more common, I am looking to see what are "standard"/"recommended" ways for running additional scripts besides the start/stop daemon, which makes it also easier to build packages not worrying about the type of OS and how it can run scripts at startup. Systemd seems to have the "ExecStartPre" option, is it what people use to ensure the rtpengine kernel module is loaded and iptables rule exists? Any systemd-specific wayt to run a script only once after system boot? I have seen workarounds on the net for creating like a rc.local service, but they didn't look to be systemd-native, ... Not strictly related, but if someone is aware or had some experiences with, I am curious if "echo 'del 0' > /proc/rtpengine/control" is really needed because on a system where I forgot to have it in the scripts (well, was commented), I haven't noticed any issues after rtpengine restarts. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference - April 27-29, 2020, in Berlin -- www.kamailioworld.com

3 8

Kamailio 5.0.1 Crashes
by Virgílio Cunha 09 Mar '20

09 Mar '20

Hello everyone, I have a problem in production environment where I have two SIP Proxies and both had the same problem but I don't have a ideia about root cause that triggered it. Unfortunately I don't have a core dump file because it was truncated for don't have space enough in file system. So I only have loggings filesin DEBUG level. The proxy_1 apparently was processing a SUBSCRIBE request and the proxy_2 was processing a DMQ messages. Both of proxies crashed after appear this line in logging file " CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 10" What could trigger this error? The loggin of proxy_1 is following: 2020-01-28 05:17:37.058 INFO: <script>: New request - M=SUBSCRIBE R=sip: 172.29.213.10:5070 F=sip:9147323151@businesshostedvoice.com:5061 T=sip:9147323156@busine sshostedvoice.com:5061 IP=udp:10.159.0.25:5060 ID= 0gQAAC8WAAACBAAALxYAAJmTUrVeFdEMSouFoeDnzdKbnqZHYs2tiFs+Okphqx4p(a)10.159.0.25 CSeq=20830 2020-01-28 05:17:37.058 DEBUG: <core> [core/mem/q_malloc.c:368]: qm_malloc(): qm_malloc(0x7f3f97a41000, 74) called from core: core/usr_avp.c: create_avp(175) 2020-01-28 05:17:37.058 DEBUG: <core> [core/mem/q_malloc.c:413]: qm_malloc(): qm_malloc(0x7f3f97a41000, 80) returns address 0x7f3fb4365df8 frag. 0x7f3fb4365dc0 (size=80) on 1 -th hit 2020-01-28 05:17:37.058 DEBUG: <core> [core/mem/q_malloc.c:368]: qm_malloc(): qm_malloc(0x7f3f97a41000, 52) called from core: core/usr_avp.c: create_avp(175) 2020-01-28 05:17:37.058 DEBUG: <core> [core/mem/q_malloc.c:413]: qm_malloc(): qm_malloc(0x7f3f97a41000, 56) returns address 0x7f3fb7c8ef08 frag. 0x7f3fb7c8eed0 (size=56) on 1 -th hit 2020-01-28 05:17:37.058 DEBUG: <core> [core/mem/q_malloc.c:368]: qm_malloc(): qm_malloc(0x7f3f97a41000, 67) called from core: core/usr_avp.c: create_avp(175) 2020-01-28 05:17:37.058 DEBUG: <core> [core/mem/q_malloc.c:413]: qm_malloc(): qm_malloc(0x7f3f97a41000, 72) returns address 0x7f3fd2bc8928 frag. 0x7f3fd2bc88f0 (size=72) on 1 -th hit 2020-01-28 05:17:37.059 INFO: <script>: Applying rewrite rules on '9147323156' using dialplan 'DB_MANIPS' - R=sip:172.29.213.10:5070 ID=0gQAAC8WAAACBAAALxYAAJmT UrVeFdEMSouFoeDnzdKbnqZHYs2tiFs+Okphqx4p(a)10.159.0.25 UA='Grandstream GXP2140 1.0.9.135' 2020-01-28 05:17:37.059 DEBUG: dialplan [dialplan.c:208]: dp_get_ivalue(): searching 4 2020-01-28 05:17:37.059 DEBUG: dialplan [dialplan.c:216]: dp_get_ivalue(): dpid is 1 from pv argument 2020-01-28 05:17:37.059 DEBUG: dialplan [dialplan.c:225]: dp_get_svalue(): searching 4 2020-01-28 05:17:37.059 DEBUG: dialplan [dialplan.c:313]: dp_translate_f(): input is 9147323156 2020-01-28 05:17:37.059 DEBUG: dialplan [dp_repl.c:606]: translate(): regex operator testing over [9147323156] 2020-01-28 05:17:37.059 DEBUG: dialplan [dp_repl.c:606]: translate(): regex operator testing over [9147323156] 2020-01-28 05:17:37.059 DEBUG: dialplan [dp_repl.c:606]: translate(): regex operator testing over [9147323156] 2020-01-28 05:17:37.059 DEBUG: dialplan [dp_repl.c:676]: translate(): no matching rule 2020-01-28 05:17:37.059 DEBUG: dialplan [dialplan.c:318]: dp_translate_f(): could not translate 9147323156 with dpid 1 2020-01-28 05:17:37.059 INFO: <script>: No matching rewrite rules for '9147323156' found - R=sip:172.29.213.10:5070 ID=0gQAAC8WAAACBAAALxYAAJmTUrVeFdEMSouFoeDnz dKbnqZHYs2tiFs+Okphqx4p(a)10.159.0.25 UA='Grandstream GXP2140 1.0.9.135' 2020-01-28 05:17:37.059 DEBUG: <core> [core/mem/q_malloc.c:368]: qm_malloc(): qm_malloc(0x7f3f97a41000, 70) called from core: core/usr_avp.c: create_avp(175) 2020-01-28 05:17:37.059 DEBUG: <core> [core/mem/q_malloc.c:413]: qm_malloc(): qm_malloc(0x7f3f97a41000, 72) returns address 0x7f3fa7f6f028 frag. 0x7f3fa7f6eff0 (size=72) on 1 -th hit 2020-01-28 05:17:37.059 INFO: <script>: Clean AVPs that contains rewrite rule from method ROUTE_APPLY_REWRITE_RULE ID=0gQAAC8WAAACBAAALxYAAJmTUrVeFdEMSouFoeDnzd KbnqZHYs2tiFs+Okphqx4p(a)10.159.0.25 2020-01-28 05:17:37.059 DEBUG: <core> [core/mem/q_malloc.c:454]: qm_free(): qm_free(0x7f3f97a41000, 0x7f3fb4365df8), called from core: core/usr_avp.c: destroy_a vp(592) 2020-01-28 05:17:37.059 DEBUG: <core> [core/mem/q_malloc.c:489]: qm_free(): qm_free: freeing frag. 0x7f3fb4365dc0 alloc'ed from core: core/usr_avp.c: create_avp (175) 2020-01-28 05:17:37.059 DEBUG: <core> [core/mem/q_malloc.c:454]: qm_free(): qm_free(0x7f3f97a41000, 0x7f3fb7c8ef08), called from core: core/usr_avp.c: destroy_avp(592) 2020-01-28 05:17:37.059 DEBUG: <core> [core/mem/q_malloc.c:489]: qm_free(): qm_free: freeing frag. 0x7f3fb7c8eed0 alloc'ed from core: core/usr_avp.c: create_avp(175) 2020-01-28 05:17:37.059 DEBUG: <core> [core/mem/q_malloc.c:454]: qm_free(): qm_free(0x7f3f97a41000, 0x7f3fd2bc8928), called from core: core/usr_avp.c: destroy_avp(592) 2020-01-28 05:17:37.059 DEBUG: <core> [core/mem/q_malloc.c:489]: qm_free(): qm_free: freeing frag. 0x7f3fd2bc88f0 alloc'ed from core: core/usr_avp.c: create_avp(175) 2020-01-28 05:17:37.059 DEBUG: <core> [core/mem/q_malloc.c:368]: qm_malloc(): qm_malloc(0x7f40d8531010, 247) called from db_postgres: km_dbase.c: db_postgres_submit_query(171) 2020-01-28 05:17:37.059 DEBUG: <core> [core/mem/q_malloc.c:413]: qm_malloc(): qm_malloc(0x7f40d8531010, 248) returns address 0x7f40d8aac7d8 frag. 0x7f40d8aac7a0 (size=376) on 1 -th hit 2020-01-28 05:17:37.059 CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 10 2020-01-28 05:17:37.059 DEBUG: <core> [core/tcp_main.c:3456]: handle_ser_child(): dead child 2, pid 28150 (shutting down?) 2020-01-28 05:17:37.059 DEBUG: <core> [core/io_wait.h:602]: io_watch_del(): DBG: io_watch_del (0xa52ba0, 10, -1, 0x0) fd_no=61 called 2020-01-28 05:17:37.059 ALERT: <core> [main.c:744]: handle_sigs(): child process 28150 exited by a signal 11 2020-01-28 05:17:37.059 ALERT: <core> [main.c:747]: handle_sigs(): core was generated 2020-01-28 05:17:37.059 INFO: <core> [main.c:759]: handle_sigs(): terminating due to SIGCHLD 2020-01-28 05:17:37.059 DEBUG: <core> [main.c:761]: handle_sigs(): terminating due to SIGCHLD 2020-01-28 05:17:37.060 INFO: <core> [main.c:814]: sig_usr(): signal 15 received 2020-01-28 05:17:37.060 INFO: <core> [main.c:814]: sig_usr(): signal 15 received 2020-01-28 05:17:37.060 DEBUG: <core> [main.c:825]: sig_usr(): Memory status (pkg): 2020-01-28 05:17:37.060 DEBUG: <core> [main.c:825]: sig_usr(): Memory status (pkg): 2020-01-28 05:17:37.060 DEBUG: qm_status: (0x7f40d8531010): 2020-01-28 05:17:37.060 DEBUG: qm_status: (0x7f40d8531010): 2020-01-28 05:17:37.060 DEBUG: qm_status: heap size= 18874368 2020-01-28 05:17:37.060 DEBUG: qm_status: heap size= 18874368 2020-01-28 05:17:37.060 DEBUG: qm_status: used= 5260600, used+overhead=7067400, free=11806968 2020-01-28 05:17:37.060 DEBUG: qm_status: used= 5260600, used+overhead=7067400, free=11806968 2020-01-28 05:17:37.060 DEBUG: qm_status: max used (+overhead)= 7144424 2020-01-28 05:17:37.060 INFO: <core> [main.c:814]: sig_usr(): signal 15 received 2020-01-28 05:17:37.060 DEBUG: <core> [main.c:825]: sig_usr(): Memory status (pkg): 2020-01-28 05:17:37.060 DEBUG: qm_status: (0x7f40d8531010): 2020-01-28 05:17:37.060 DEBUG: qm_status: heap size= 18874368 2020-01-28 05:17:37.060 DEBUG: qm_status: used= 5111688, used+overhead=6932632, free=11941736 2020-01-28 05:17:37.060 DEBUG: qm_status: max used (+overhead)= 7144424 2020-01-28 05:17:37.060 DEBUG: qm_status: dumping all alloc'ed. fragments: 2020-01-28 05:17:37.060 INFO: <core> [main.c:814]: sig_usr(): signal 15 received 2020-01-28 05:17:37.060 DEBUG: qm_status: 0. N address=0x7f40d856a6d8 frag=0x7f40d856a6a0 size=1024 used=1 2020-01-28 05:17:37.060 DEBUG: <core> [main.c:825]: sig_usr(): Memory status (pkg): 2020-01-28 05:17:37.060 DEBUG: qm_status: alloc'd from core: core/str_hash.h: str_hash_alloc(59) 2020-01-28 05:17:37.060 DEBUG: qm_status: (0x7f40d8531010): 2020-01-28 05:17:37.060 DEBUG: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 2020-01-28 05:17:37.060 INFO: <core> [main.c:814]: sig_usr(): signal 15 received 2020-01-28 05:17:37.060 DEBUG: <core> [main.c:825]: sig_usr(): Memory status (pkg): 2020-01-28 05:17:37.060 DEBUG: qm_status: (0x7f40d8531010): 2020-01-28 05:17:37.060 INFO: <core> [main.c:814]: sig_usr(): signal 15 received 2020-01-28 05:17:37.060 DEBUG: qm_status: heap size= 18874368 2020-01-28 05:17:37.060 DEBUG: qm_status: used= 5260600, used+overhead=7067400, free=11806968 2020-01-28 05:17:37.060 DEBUG: <core> [main.c:825]: sig_usr(): Memory status (pkg): 2020-01-28 05:17:37.060 DEBUG: qm_status: max used (+overhead)= 7144424 2020-01-28 05:17:37.060 INFO: <core> [main.c:814]: sig_usr(): signal 15 received 2020-01-28 05:17:37.060 INFO: <core> [main.c:814]: sig_usr(): signal 15 received 2020-01-28 05:17:37.060 DEBUG: <core> [main.c:825]: sig_usr(): Memory status (pkg): 2020-01-28 05:17:37.060 DEBUG: <core> [main.c:825]: sig_usr(): Memory status (pkg): 2020-01-28 05:17:37.060 INFO: <core> [main.c:814]: sig_usr(): signal 15 received 2020-01-28 05:17:37.060 DEBUG: qm_status: (0x7f40d8531010): 2020-01-28 05:17:37.060 DEBUG: qm_status: heap size= 18874368 2020-01-28 05:17:37.060 INFO: <core> [main.c:814]: sig_usr(): signal 15 received 2020-01-28 05:17:37.060 INFO: <core> [main.c:814]: sig_usr(): signal 15 received 2020-01-28 05:17:37.060 DEBUG: <core> [main.c:825]: sig_usr(): Memory status (pkg): 2020-01-28 05:17:37.060 DEBUG: qm_status: (0x7f40d8531010): 2020-01-28 05:17:37.060 DEBUG: qm_status: heap size= 18874368 2020-01-28 05:17:37.060 DEBUG: qm_status: used= 5260600, used+overhead=7067400, free=11806968 2020-01-28 05:17:37.060 DEBUG: qm_status: max used (+overhead)= 7144424 2020-01-28 05:17:37.060 DEBUG: qm_status: dumping all alloc'ed. fragments: 2020-01-28 05:17:37.060 DEBUG: qm_status: 0. N address=0x7f40d856a6d8 frag=0x7f40d856a6a0 size=1024 used=1 2020-01-28 05:17:37.060 DEBUG: qm_status: alloc'd from core: core/str_hash.h: str_hash_alloc(59) 2020-01-28 05:17:37.060 DEBUG: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 2020-01-28 05:17:37.060 DEBUG: <core> [main.c:825]: sig_usr(): Memory status (pkg): 2020-01-28 05:17:37.060 DEBUG: qm_status: 1. N address=0x7f40d856ab40 frag=0x7f40d856ab08 size=256 used=1 2020-01-28 05:17:37.060 DEBUG: qm_status: alloc'd from core: core/str_hash.h: str_hash_alloc(59) 2020-01-28 05:17:37.060 DEBUG: qm_status: start check=f0f0f0f0, end check= c0c0c0c0, abcdefed 2020-01-28 05:17:37.060 DEBUG: qm_status: 2. N address=0x7f40d856aca8 frag=0x7f40d856ac70 size=176 used=1 2020-01-28 05:17:37.060 DEBUG: qm_status: (0x7f40d8531010): 2020-01-28 05:17:37.060 DEBUG: qm_status: alloc'd from core: core/counters.c: cnt_hash_add(332) 2020-01-28 05:17:37.060 INFO: <core> [main.c:814]: sig_usr(): signal 15 received 2020-01-28 05:17:37.060 INFO: <core> [main.c:814]: sig_usr(): signal 15 received 2020-01-28 05:17:37.060 DEBUG: <core> [main.c:825]: sig_usr(): Memory status (pkg): 2020-01-28 05:17:37.060 INFO: <core> [main.c:814]: sig_usr(): signal 15 received 2020-01-28 05:17:37.060 INFO: <core> [main.c:814]: sig_usr(): signal 15 received 2020-01-28 05:17:37.060 DEBUG: <core> [main.c:825]: sig_usr(): Memory status (pkg): 2020-01-28 05:17:37.060 DEBUG: <core> [main.c:825]: sig_usr(): Memory status (pkg): 2020-01-28 05:17:37.060 INFO: <core> [main.c:814]: sig_usr(): signal 15 received 2020-01-28 05:17:37.060 INFO: <core> [main.c:814]: sig_usr(): signal 15 received 2020-01-28 05:17:37.060 DEBUG: <core> [main.c:825]: sig_usr(): Memory status (pkg): 2020-01-28 05:17:37.060 DEBUG: <core> [main.c:825]: sig_usr(): Memory status (pkg): 2020-01-28 05:17:37.060 DEBUG: qm_status: (0x7f40d8531010): 2020-01-28 05:17:37.060 DEBUG: qm_status: (0x7f40d8531010): 2020-01-28 05:17:37.060 DEBUG: qm_status: heap size= 18874368 2020-01-28 05:17:37.060 DEBUG: qm_status: used= 5103784, used+overhead=6908920, free=11965448 2020-01-28 05:17:37.060 DEBUG: qm_status: heap size= 18874368 2020-01-28 05:17:37.060 DEBUG: qm_status: used= 5103784, used+overhead=6908920, free=11965448 2020-01-28 05:17:37.060 DEBUG: qm_status: max used (+overhead)= 7144424 2020-01-28 05:17:37.060 DEBUG: qm_status: dumping all alloc'ed. fragments: The loggin of proxy_2 is following: 2020-01-28 05:57:21.077 DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [74]; uri=[sip:usrloc@172.29.217.7:5060] 2020-01-28 05:57:21.077 DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body [<sip:usrloc@172.29.217.7:5060>] 2020-01-28 05:57:21.077 DEBUG: <core> [core/mem/q_malloc.c:368]: qm_malloc(): qm_malloc(0x7f5ae4367010, 64) called from core: core/parser/msg_parser.c: parse_he aders(319) 2020-01-28 05:57:21.077 DEBUG: <core> [core/mem/q_malloc.c:413]: qm_malloc(): qm_malloc(0x7f5ae4367010, 64) returns address 0x7f5ae499f980 frag. 0x7f5ae499f948 (size=64) on 1 -th hit 2020-01-28 05:57:21.077 DEBUG: <core> [core/mem/q_malloc.c:368]: qm_malloc(): qm_malloc(0x7f5ae4367010, 64) called from core: core/parser/msg_parser.c: parse_he aders(319) 2020-01-28 05:57:21.077 DEBUG: <core> [core/mem/q_malloc.c:413]: qm_malloc(): qm_malloc(0x7f5ae4367010, 64) returns address 0x7f5ae499bcf8 frag. 0x7f5ae499bcc0 (size=64) on 1 -th hit 2020-01-28 05:57:21.077 DEBUG: <core> [core/mem/q_malloc.c:368]: qm_malloc(): qm_malloc(0x7f5ae4367010, 48) called from core: core/parser/msg_parser.c: get_hdr_ field(135) 2020-01-28 05:57:21.077 DEBUG: <core> [core/mem/q_malloc.c:413]: qm_malloc(): qm_malloc(0x7f5ae4367010, 48) returns address 0x7f5ae4916f90 frag. 0x7f5ae4916f58 (size=48) on 1 -th hit 2020-01-28 05:57:21.077 DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <10> <KDMQ> 2020-01-28 05:57:21.077 DEBUG: <core> [core/mem/q_malloc.c:368]: qm_malloc(): qm_malloc(0x7f5ae4367010, 64) called from core: core/parser/msg_parser.c: parse_headers(319) 2020-01-28 05:57:21.077 DEBUG: <core> [core/mem/q_malloc.c:413]: qm_malloc(): qm_malloc(0x7f5ae4367010, 64) returns address 0x7f5ae499e520 frag. 0x7f5ae499e4e8 (size=64) on 1 -th hit 2020-01-28 05:57:21.077 DEBUG: <core> [core/receive.c:191]: receive_msg(): --- received sip message - reply - call-id: [ 3d48b3aa4ec7e11f-8255(a)172.29.213.8] - cseq: [10 KDMQ] 2020-01-28 05:57:21.077 DEBUG: <core> [core/mem/q_malloc.c:368]: qm_malloc(): qm_malloc(0x7f5ae4367010, 936) called from core: core/rvalue.c: rval_new_empty(224) 2020-01-28 05:57:21.077 DEBUG: <core> [core/mem/q_malloc.c:413]: qm_malloc(): qm_malloc(0x7f5ae4367010, 936) returns address 0x7f5ae48e1340 frag. 0x7f5ae48e1308 (size=1736) on 1 -th hit 2020-01-28 05:57:21.077 DEBUG: <core> [core/mem/q_malloc.c:454]: qm_free(): qm_free(0x7f5ae4367010, 0x7f5ae48e1340), called from core: core/rvalue.c: rval_destroy(129) 2020-01-28 05:57:21.077 DEBUG: <core> [core/mem/q_malloc.c:489]: qm_free(): qm_free: freeing frag. 0x7f5ae48e1308 alloc'ed from core: core/rvalue.c: rval_new_empty(224) 2020-01-28 05:57:21.077 DEBUG: tm [t_lookup.c:1001]: t_check_msg(): msg id=190277 global id=190276 T start=0xffffffffffffffff 2020-01-28 05:57:21.077 DEBUG: tm [t_lookup.c:879]: t_reply_matching(): t_reply_matching: hash 26335 label 0 branch 0 2020-01-28 05:57:21.077 DEBUG: tm [t_lookup.c:933]: t_reply_matching(): reply matched (T=0x7f59eef5b310)! 2020-01-28 05:57:21.077 DEBUG: tm [t_lookup.c:1070]: t_check_msg(): msg id=190277 global id=190277 T end=0x7f59eef5b310 2020-01-28 05:57:21.077 DEBUG: tm [t_lookup.c:1001]: t_check_msg(): msg id=190277 global id=190277 T start=0x7f59eef5b310 2020-01-28 05:57:21.077 DEBUG: tm [t_lookup.c:1073]: t_check_msg(): T already found! 2020-01-28 05:57:21.077 DEBUG: tm [t_reply.c:2147]: reply_received(): org. status uas=0, uac[0]=0 local=2 is_invite=0) 2020-01-28 05:57:21.077 DEBUG: tm [t_reply.c:1220]: t_should_relay_response(): ->>>>>>>>> T_code=0, new_code=200 2020-01-28 05:57:21.077 DEBUG: tm [t_reply.c:2021]: local_reply(): branch=0, save=0, winner=0 2020-01-28 05:57:21.077 DEBUG: tm [t_reply.c:2060]: local_reply(): local transaction completed 200/0 (totag retr: 0/1024) 2020-01-28 05:57:21.077 DEBUG: tm [t_hooks.c:258]: run_trans_callbacks_internal(): DBG: trans=0x7f59eef5b310, callback type 1024, id 0 entered 2020-01-28 05:57:21.077 DEBUG: dmq [dmq_funcs.c:61]: dmq_tm_callback(): dmq_tm_callback start 2020-01-28 05:57:21.077 DEBUG: dmq_usrloc [usrloc_sync.c:583]: usrloc_dmq_resp_callback_f(): dmq response callback triggered [0x7f5ae4a373c8 200 (nil)] 2020-01-28 05:57:21.077 DEBUG: dmq [dmq_funcs.c:67]: dmq_tm_callback(): dmq_tm_callback done 2020-01-28 05:57:21.077 DEBUG: <core> [core/mem/q_malloc.c:454]: qm_free(): qm_free(0x7f59a3877000, 0x7f59f9b93080), called from dmq: dmqnode.c: shm_free_node(306) 2020-01-28 05:57:21.077 DEBUG: <core> [core/mem/q_malloc.c:489]: qm_free(): qm_free: freeing frag. 0x7f59f9b93048 alloc'ed from dmq: ../../core/ut.h: shm_str_dup(723) 2020-01-28 05:57:21.077 DEBUG: <core> [core/mem/q_malloc.c:454]: qm_free(): qm_free(0x7f59a3877000, 0x7f59c6055a40), called from dmq: dmqnode.c: shm_free_node(307) 2020-01-28 05:57:21.077 DEBUG: <core> [core/mem/q_malloc.c:489]: qm_free(): qm_free: freeing frag. 0x7f59c6055a08 alloc'ed from dmq: dmqnode.c: shm_dup_node(279) 2020-01-28 05:57:21.077 DEBUG: <core> [core/mem/q_malloc.c:454]: qm_free(): qm_free(0x7f59a3877000, 0x7f59c4a46a48), called from dmq: dmq_funcs.c: dmq_tm_callback(69) 2020-01-28 05:57:21.077 DEBUG: <core> [core/mem/q_malloc.c:489]: qm_free(): qm_free: freeing frag. 0x7f59c4a46a10 alloc'ed from dmq: dmq_funcs.c: dmq_send_message(212) 2020-01-28 05:57:21.077 DEBUG: tm [t_reply.c:1578]: cleanup_uac_timers(): RETR/FR timers reset 2020-01-28 05:57:21.077 DEBUG: <core> [core/receive.c:348]: receive_msg(): reply-route executed in: 143 usec 2020-01-28 05:57:21.077 DEBUG: <core> [core/usr_avp.c:631]: destroy_avp_list(): destroying list (nil) 2020-01-28 05:57:21.077 DEBUG: <core> [core/usr_avp.c:631]: destroy_avp_list(): destroying list (nil) 2020-01-28 05:57:21.077 DEBUG: <core> [core/usr_avp.c:631]: destroy_avp_list(): destroying list (nil) 2020-01-28 05:57:21.077 DEBUG: <core> [core/usr_avp.c:631]: destroy_avp_list(): destroying list (nil) 2020-01-28 05:57:21.077 DEBUG: <core> [core/usr_avp.c:631]: destroy_avp_list(): destroying list (nil) 2020-01-28 05:57:21.077 DEBUG: <core> [core/usr_avp.c:631]: destroy_avp_list(): destroying list (nil) 2020-01-28 05:57:21.077 DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 2020-01-28 05:57:21.078 DEBUG: <core> [core/receive.c:368]: receive_msg(): cleaning up 2020-01-28 05:57:21.078 DEBUG: <core> [core/mem/q_malloc.c:454]: qm_free(): qm_free(0x7f5ae4367010, 0x7f5ae499e670), called from core: core/parser/parse_via.c: free_via_param_list(2725) 2020-01-28 05:57:21.078 DEBUG: <core> [core/mem/q_malloc.c:489]: qm_free(): qm_free: freeing frag. 0x7f5ae499e638 alloc'ed from core: core/parser/parse_via.c: parse_via(2511) 2020-01-28 05:57:21.078 DEBUG: <core> [core/mem/q_malloc.c:454]: qm_free(): qm_free(0x7f5ae4367010, 0x7f5ae499f830), called from core: core/parser/parse_via.c: free_via_list(2738) 2020-01-28 05:57:21.078 DEBUG: <core> [core/mem/q_malloc.c:489]: qm_free(): qm_free: freeing frag. 0x7f5ae499f7f8 alloc'ed from core: core/parser/msg_parser.c: get_hdr_field(116) 2020-01-28 05:57:21.078 DEBUG: <core> [core/mem/q_malloc.c:454]: qm_free(): qm_free(0x7f5ae4367010, 0x7f5ae4921478), called from core: core/parser/hf.c: free_hdr_field_lst(217) 2020-01-28 05:57:21.078 DEBUG: <core> [core/mem/q_malloc.c:489]: qm_free(): qm_free: freeing frag. 0x7f5ae4921440 alloc'ed from core: core/parser/msg_parser.c: parse_headers(319) 2020-01-28 05:57:21.078 DEBUG: <core> [core/mem/q_malloc.c:454]: qm_free(): qm_free(0x7f5ae4367010, 0x7f5ae4924f60), called from core: core/parser/parse_addr_spec.c: free_to_params(895) 2020-01-28 05:57:21.078 DEBUG: <core> [core/mem/q_malloc.c:489]: qm_free(): qm_free: freeing frag. 0x7f5ae4924f28 alloc'ed from core: core/parser/parse_addr_spec.c: parse_to_param(285) 2020-01-28 05:57:21.078 DEBUG: <core> [core/mem/q_malloc.c:454]: qm_free(): qm_free(0x7f5ae4367010, 0x7f5ae4998e48), called from core: core/parser/parse_addr_spec.c: free_to(905) 2020-01-28 05:57:21.078 DEBUG: <core> [core/mem/q_malloc.c:489]: qm_free(): qm_free: freeing frag. 0x7f5ae4998e10 alloc'ed from core: core/parser/msg_parser.c: get_hdr_field(155) 2020-01-28 05:57:21.078 DEBUG: <core> [core/mem/q_malloc.c:454]: qm_free(): qm_free(0x7f5ae4367010, 0x7f5ae48ecd18), called from core: core/parser/hf.c: free_hdr_field_lst(217) 2020-01-28 05:57:21.078 DEBUG: <core> [core/mem/q_malloc.c:489]: qm_free(): qm_free: freeing frag. 0x7f5ae48ecce0 alloc'ed from core: core/parser/msg_parser.c: parse_headers(319) 2020-01-28 05:57:21.078 DEBUG: <core> [core/mem/q_malloc.c:454]: qm_free(): qm_free(0x7f5ae4367010, 0x7f5ae499f980), called from core: core/parser/hf.c: free_hdr_field_lst(217) 2020-01-28 05:57:21.078 DEBUG: <core> [core/mem/q_malloc.c:489]: qm_free(): qm_free: freeing frag. 0x7f5ae499f948 alloc'ed from core: core/parser/msg_parser.c: parse_headers(319) 2020-01-28 05:57:21.078 DEBUG: <core> [core/mem/q_malloc.c:454]: qm_free(): qm_free(0x7f5ae4367010, 0x7f5ae4916f90), called from core: core/parser/parse_cseq.c: free_cseq(99) 2020-01-28 05:57:21.078 DEBUG: <core> [core/mem/q_malloc.c:489]: qm_free(): qm_free: freeing frag. 0x7f5ae4916f58 alloc'ed from core: core/parser/msg_parser.c: get_hdr_field(135) 2020-01-28 05:57:21.078 DEBUG: <core> [core/mem/q_malloc.c:454]: qm_free(): qm_free(0x7f5ae4367010, 0x7f5ae499bcf8), called from core: core/parser/hf.c: free_hdr_field_lst(217) 2020-01-28 05:57:21.078 DEBUG: <core> [core/mem/q_malloc.c:489]: qm_free(): qm_free: freeing frag. 0x7f5ae499bcc0 alloc'ed from core: core/parser/msg_parser.c: parse_headers(319) 2020-01-28 05:57:21.078 DEBUG: <core> [core/mem/q_malloc.c:454]: qm_free(): qm_free(0x7f5ae4367010, 0x7f5ae499e520), called from core: core/parser/hf.c: free_hdr_field_lst(217) 2020-01-28 05:57:21.078 DEBUG: <core> [core/mem/q_malloc.c:489]: qm_free(): qm_free: freeing frag. 0x7f5ae499e4e8 alloc'ed from core: core/parser/msg_parser.c: parse_headers(319) 2020-01-28 05:57:21.078 DEBUG: <core> [core/mem/q_malloc.c:454]: qm_free(): qm_free(0x7f5ae4367010, 0x7f5ae4a373c8), called from core: core/receive.c: receive_msg(370) 2020-01-28 05:57:21.078 DEBUG: <core> [core/mem/q_malloc.c:489]: qm_free(): qm_free: freeing frag. 0x7f5ae4a37390 alloc'ed from core: core/receive.c: receive_msg(150) 2020-01-28 05:57:21.117 CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 10 2020-01-28 05:57:21.117 DEBUG: <core> [core/tcp_main.c:3456]: handle_ser_child(): dead child 2, pid 8253 (shutting down?) 2020-01-28 05:57:21.117 DEBUG: <core> [core/io_wait.h:602]: io_watch_del(): DBG: io_watch_del (0xa52ba0, 10, -1, 0x0) fd_no=61 called 2020-01-28 05:57:21.118 ALERT: <core> [main.c:744]: handle_sigs(): child process 8253 exited by a signal 11 2020-01-28 05:57:21.118 ALERT: <core> [main.c:747]: handle_sigs(): core was generated 2020-01-28 05:57:21.118 INFO: <core> [main.c:759]: handle_sigs(): terminating due to SIGCHLD 2020-01-28 05:57:21.118 DEBUG: <core> [main.c:761]: handle_sigs(): terminating due to SIGCHLD 2020-01-28 05:57:21.118 INFO: <core> [main.c:814]: sig_usr(): signal 15 received 2020-01-28 05:57:21.118 DEBUG: <core> [main.c:825]: sig_usr(): Memory status (pkg): Best regards Virgílio Cunha

3 3

Re: [SR-Users] dlg.end_dlg on RTP timeout
by Miteshkumar Thakkar 28 Feb '20

28 Feb '20

This is really helpful development. I am facing one issue, when I use this. RTPEngine is sending two "dlg.terminate_dlg" events for single call to kamailio with same call-id but reversed to-tag and from-tag in second event. I believe this is due to two separate RTP streams. Problem here is that - in first event kamailio terminates the call, hence when second event comes, kamailio says - call-id not found and send response back to RTPEngine. But still RTPEngine keeps sending that event message for three more times. Kamailio has to respond to it with call-id not found. Which is overhead. Not recommended for production environment. How can I avoid this? Any help is appreciated. Thank you Mitesh That's great, thank you! Cheers, Daniel On 06.09.18 11:15, Richard Fuchs wrote: >* This is now supported as per * >* https://github.com/sipwise/rtpengine/commit/89084da8d820919b44a0244e16e6701… <https://github.com/sipwise/rtpengine/commit/89084da8d820919b44a0244e16e6701…> * > >* Cheers * > >* On 2018-09-05 05:39, Daniel-Constantin Mierla wrote: * >> >>* There is the dlg.terminate_dlg rpc command that requires callid, * >>* from-tag and to-tag as parameters: * >> >>* * * >>* https://kamailio.org/docs/modules/5.1.x/modules/dialog.html#dlg.r.terminate… <https://kamailio.org/docs/modules/5.1.x/modules/dialog.html#dlg.r.terminate…> * >> >>* So it expects something like: * >> >>* <?xml version="1.0" encoding="UTF-8"?> * >>* <methodCall> * >>* <methodName>dlg.terminate_dlg</methodName> * >>* <params> * >>* <param><value><string>_CALLID_VALUE__</string></value></param> * >>* <param><value><string>_FROM_TAG_VALUE__</string></value></param> * >>* <param><value><string>_TO_TAG_VALUE__</string></value></param> * >>* </params> * >>* </methodCall> * >> >>* I planned to make the from-tag and to-tag optional for quite some * >>* time, but didn't get the time for it yet. * >> >>* Cheers, * >>* Daniel * >> >>* On 05.09.18 08:52, Richard Fuchs wrote: * >>>* Yup that's exactly right. * >>> >>>* It would be fairly simple to implement an additional XMLRPC format * >>>* if there's a particular one that's more friendly towards Kamailio. * >>> >>>* Cheers * >>> >>>* On 2018-09-05 02:42, Daniel-Constantin Mierla wrote: * >>>> >>>>* Looking quickly at the readme of rtpengine application and digging * >>>>* a bit with google, it is something like rtpengine has to be started * >>>>* with * >>>> >>>>* -b http(s)://myrpcserver.ip/path -x 1 * >>>> >>>>* and then the xmlrpc request is going to be sent to that url, having * >>>>* a format like: * >>>> >>>>* <?xml version="1.0" encoding="UTF-8"?> * >>>>* <methodCall> * >>>>* <methodName>teardown</methodName> * >>>>* <params> * >>>>* <param><value><string>_CALLID_VALUE__</string></value></param> * >>>>* </params> * >>>>* </methodCall> * >>>> >>>>* Is it right? If yes, then I can try to make a sample config that * >>>>* could handle it using xmlops, xhttp and jsonrpcs modules. * >>>> >>>>* Cheers, * >>>>* Daniel * >>>> >>>> >>>>* On 05.09.18 08:24, Richard Fuchs wrote: * >>>>>* It does an XMLRPC callback. Currently there's two formats for it, * >>>>>* one is a sems sbc teardown request (using the from-tag), the other * >>>>>* is a generic "teardown" command using the call ID. * >>>>> >>>>>* Cheers * >>>>> >>>>>* On 2018-09-04 07:52, Daniel-Constantin Mierla wrote: * >>>>>> >>>>>>* Hello, * >>>>>> >>>>>>* what do you get from rtpengine on rtp timeout? An RPC call back * >>>>>>* or an http request? * >>>>>> >>>>>>* Cheers, * >>>>>>* Daniel * >>>>>> >>>>>> >>>>>>* On 04.09.18 12:48, Igor Olhovskiy wrote: * >>>>>>>* Hi all! * >>>>>>> >>>>>>>* Is there any way to end dialog in Kamailio on RTP Timeout event * >>>>>>>* on RTPEngine? * >>>>>>> >>>>>>>* Or only look at logs/redis database with external tool? * >>>>>>> >>>>>>>* Regards, Igor * >>>>>>> >>>>>>> >>>>>>>* _______________________________________________ * >>>>>>>* Kamailio (SER) - Users Mailing List * >>>>>>>* sr-users at lists.kamailio.org <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> * >>>>>>>* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> * >>>>>> >>>>>>* -- * >>>>>>* Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com> * >>>>>>* www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> * >>>>>>* Kamailio World Conference -- www.kamailioworld.com <http://www.kamailioworld.com> * >>>>>>* Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com <http://www.asipto.com> * >>>>>> >>>>>> >>>>>>* _______________________________________________ * >>>>>>* Kamailio (SER) - Users Mailing List * >>>>>>* sr-users at lists.kamailio.org <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> * >>>>>>* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> * >>>>> >>>>> >>>>>* _______________________________________________ * >>>>>* Kamailio (SER) - Users Mailing List * >>>>>* sr-users at lists.kamailio.org <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> * >>>>>* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> * >>>> >>>>* -- * >>>>* Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com> * >>>>* www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> * >>>>* Kamailio World Conference -- www.kamailioworld.com <http://www.kamailioworld.com> * >>>>* Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com <http://www.asipto.com> * >>> >>> >>>* _______________________________________________ * >>>* Kamailio (SER) - Users Mailing List * >>>* sr-users at lists.kamailio.org <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> * >>>* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> * >> >>* -- * >>* Daniel-Constantin Mierla -- www.asipto.com <http://www.asipto.com> * >>* www.twitter.com/miconda <http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> * >>* Kamailio World Conference -- www.kamailioworld.com <http://www.kamailioworld.com> * >>* Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com <http://www.asipto.com> * > > >* _______________________________________________ * >* Kamailio (SER) - Users Mailing List * >* sr-users at lists.kamailio.org <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> * >* https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users> * -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

2 11

Trouble with 302 Redirect
by Jim Leahy 27 Feb '20

27 Feb '20

Hi All, I'm having some issues trying to properly send a '302 Moved Temporarily' reply to the calling UAC (UAC1) when the remote UAC (UAC2) returns a 486 status (Do Not Disturb). The goal is to redirect UAC1 to a voicemail server when UAC2 is in DND. Here are the pertinent parts of my config: route { # drop some things right away route(DROP); # perform sanity check route(SANITYCHECK); # handle registrations if(is_method("REGISTER")) { route(REGISTRATION); exit; } # handle invites if(is_method("INVITE")) { route("INVITE"); exit; } route(RELAY); } route[INVITE] { # add this proxy to the record-route so it stays in the loop record_route(); # if we can find this user in the location DB... if(lookup("location")) { # relay the invite to the new dURI t_on_failure("FOURDIGITFAIL"); t_on_reply("FOURDIGITREPLY"); route(RELAY); # go back to the main route return; } onreply_route[FOURDIGITREPLY] { if(t_check_status("4[0-9]{2}")) { t_reply("302", "Moved Temporarily"); } } I'm having issues with the t_reply in the onreply_route. It successfully sends the reply, but I can't seem to set the Contact header properly. I'm trying to set it to the location of the user's mailbox on the voicemail sever (ie sip:1000@vmpbx.domain.com), but nothing I try works. I've tried: remove_hf("Contact"); insert_hf("Contact: sip:1000@vmpbx.domain.com"); t_reply("302", "Moved Temporarily"); But as I understand it, that just changes the header in the reply from UAC2, not the reply I'm sending to UAC1 Then I tried: append_to_reply("Contact: sip:1000@vmpbx.domain.com" ); t_reply("302", "Moved Temporarily"); But I can't use append_to_reply in an onreply block. How can I change the Contact header in the reply that's sent? Am I just going about this the wrong way? Any help would be appreciated. Thanks

5 4

Dispatcher error with rtpptoxy
by Gaurav Bmotra 12 Feb '20

12 Feb '20

hi i m using kamailio 5.2.1 in Kubernetese on Host network it was working file but now the following issue i n getting call connecting but audio both way issue here is the logs that got -------------------------------- 2(14) ERROR: {1 2 INVITE EQEiv5Mjs-eV1OCGv6Potw..} rtpproxy [rtpproxy.c:2586]: force_rtp_proxy(): incorrect port 0 in reply from rtp proxy 4(16) ERROR: {2 2 INVITE EQEiv5Mjs-eV1OCGv6Potw..} rtpproxy [rtpproxy.c:2586]: force_rtp_proxy(): incorrect port 0 in reply from rtp proxy 4(16) NOTICE: {2 2 INVITE EQEiv5Mjs-eV1OCGv6Potw..} acc [acc.c:279]: acc_log_request(): ACC: transaction answered: timestamp=1578636040;method=INVITE;from_tag=88c92018;to_tag=2c3c0a16;call_id=EQEiv5Mjs-eV1OCGv6Potw..;code=200;reason=OK;src_user=200;src_domain=testcalls.aone.one;src_ip=157.39.9.195;dst_ouser=300;dst_user=300;dst_domain=106.78.70.57 4(16) ERROR: {2 2 INVITE EQEiv5Mjs-eV1OCGv6Potw..} db_mysql [km_dbase.c:126]: db_mysql_submit_query(): driver error on query: Unknown column 'src_user' in 'field list' (1054) 4(16) ERROR: {2 2 INVITE EQEiv5Mjs-eV1OCGv6Potw..} <core> [db_query.c:243]: db_do_insert_cmd(): error while submitting query 4(16) ERROR: {2 2 INVITE EQEiv5Mjs-eV1OCGv6Potw..} acc [acc.c:477]: acc_db_request(): failed to insert into database 6(18) ERROR: {2 2 INVITE EQEiv5Mjs-eV1OCGv6Potw..} rtpproxy [rtpproxy.c:2586]: force_rtp_proxy(): incorrect port 0 in reply from rtp proxy 8(20) NOTICE: {2 3 BYE EQEiv5Mjs-eV1OCGv6Potw..} acc [acc.c:279]: acc_log_request(): ACC: transaction answered: timestamp=1578636041;method=BYE;from_tag=88c92018;to_tag=2c3c0a16;call_id=EQEiv5Mjs-eV1OCGv6Potw..;code=200;reason=OK;src_user=200;src_domain=testcalls.aone.one;src_ip=157.39.9.195;dst_ouser=300;dst_user=300;dst_domain=106.78.70.57 8(20) ERROR: {2 3 BYE EQEiv5Mjs-eV1OCGv6Potw..} db_mysql [km_dbase.c:126]: db_mysql_submit_query(): driver error on query: Unknown column 'src_user' in 'field list' (1054) 8(20) ERROR: {2 3 BYE EQEiv5Mjs-eV1OCGv6Potw..} <core> [db_query.c:243]: db_do_insert_cmd(): error while submitting query 8(20) ERROR: {2 3 BYE EQEiv5Mjs-eV1OCGv6Potw..} acc [acc.c:477]: acc_db_request(): failed to insert into database 3(15) ERROR: {1 2 INVITE LH6sikNzpP9rXXMJvH20wQ..} rtpproxy [rtpproxy.c:2586]: force_rtp_proxy(): incorrect port 0 in reply from rtp proxy 9(21) NOTICE: acc [acc.c:279]: acc_log_request(): ACC: call missed: timestamp=1578636141;method=INVITE;from_tag=6b032a77;to_tag=;call_id=LH6sikNzpP9rXXMJvH20wQ..;code=408;reason=Request Timeout;src_user=200;src_domain=testcalls.aone.one;src_ip=157.39.9.195;dst_ouser=300;dst_user=300;dst_domain=106.78.70.57 9(21) ERROR: db_mysql [km_dbase.c:126]: db_mysql_submit_query(): driver error on query: Unknown column 'src_user' in 'field list' (1054) 9(21) ERROR: <core> [db_query.c:243]: db_do_insert_cmd(): error while submitting query 9(21) ERROR: acc [acc.c:477]: acc_db_request(): failed to insert into database 9(21) NOTICE: {1 2 INVITE LH6sikNzpP9rXXMJvH20wQ..} <script>: RTF_DISPATCH: INVITE 300 [LH6sikNzpP9rXXMJvH20wQ..] 9(21) NOTICE: {1 2 INVITE LH6sikNzpP9rXXMJvH20wQ..} <script>: RTF_DISPATCH: WARNING sip: 49.14.97.169:63353 is broken and marked as inactive 3(15) ERROR: {1 2 INVITE 2gY1N8nGCT02Ut7iAEpKWg..} rtpproxy [rtpproxy.c:2586]: force_rtp_proxy(): incorrect port 0 in reply from rtp proxy 8(20) ERROR: {2 2 INVITE 2gY1N8nGCT02Ut7iAEpKWg..} rtpproxy [rtpproxy.c:2586]: force_rtp_proxy(): incorrect port 0 in reply from rtp proxy 8(20) NOTICE: {2 2 INVITE 2gY1N8nGCT02Ut7iAEpKWg..} acc [acc.c:279]: acc_log_request(): ACC: transaction answered: timestamp=1578638074;method=INVITE;from_tag=b9979f2a;to_tag=c2952a71;call_id=2gY1N8nGCT02Ut7iAEpKWg..;code=200;reason=OK;src_user=200;src_domain=testcalls.aone.one;src_ip=157.39.9.195;dst_ouser=300;dst_user=300;dst_domain=106.78.71.32 8(20) ERROR: {2 2 INVITE 2gY1N8nGCT02Ut7iAEpKWg..} db_mysql [km_dbase.c:126]: db_mysql_submit_query(): driver error on query: Unknown column 'src_user' in 'field list' (1054) ------------------------------- plz help me thank you -- *Regards:* Gaurav Kumar

3 2

Planning the release of v5.1.10
by Daniel-Constantin Mierla 10 Feb '20

10 Feb '20

Hello, I am considering to release Kamailio v5.1.10 on Thursday, Jan 30, 2020, to mark the end of official packaging from branch 5.1. At this moment the last two stable branches are 5.2 and 5.3. If anyone is aware of some commits for fixes that should be backported to branch 5.1, write to sr-dev. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - March 9-11, 2020, Berlin - www.asipto.com Kamailio World Conference - April 27-29, 2020, in Berlin -- www.kamailioworld.com

1 2

Kamailio TLS server hello without any client certificate request
by Patrick Murphy 03 Feb '20

03 Feb '20

Hey guys - I'm using the following settings on my Kamailio config: modparam("tls", "low_mem_threshold2", 1024) modparam("tls", "tls_force_run", 1) modparam("tls", "tls_disable_compression", 1) modparam("tls", "ssl_max_send_fragment", 4096) modparam("tls", "renegotiation", 0) modparam("tls", "low_mem_threshold1", 2048) modparam("tls", "require_certificate", 1) When a client attempts to connect to Kamailio, the server hello it receives does *not* contain the client certificate request. And I've noticed that kamailio starts with: tls [tls_domain.c:694]: set_verification(): TLSs<default>: No client certificate required and no checks performed tls [tls_domain.c:320]: fill_missing(): TLSs<default>: require_certificate=0 Complete version output: kamailio 5.1.1 (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. Any hints?

2 2

Bad request when INVITE relayed to another kamailio
by Zhan Bazarov 31 Jan '20

31 Jan '20

We have Kamailio-cluster via route53(round-robin) some-domain.net we have two kamailio with public IP's phone1 is registered on kam1 phone2 is registered on kam2 when we are calling from phone1 to phone2 callflow looks: phone1 => kam1 => asterisk => kam1 => t_relay(address of second kamailio:5078) => kam2 => phone2 it works perfectly, but in case when we are using polycom as phone2 - we are getting 404 response from polycom... *Invite from second kamailio * 2020/01/20 10:31:21.799327 10.199.240.19:5078 -> 37.17.41.5:49811 INVITE sip:jyu3xsfkrz6c5qn@10.3.0.116;transport=tcp SIP/2.0 Record-Route: <sip:10.199.240.19:5078;transport=tcp;r2=on;lr;nat=yes;rtp=bridge> Record-Route: <sip:10.199.240.191:5078;r2=on;lr;nat=yes;rtp=bridge> Record-Route: <sip:10.199.240.135:5078;lr> Via: SIP/2.0/TCP some-domain.net:5078;branch=z9hG4bK9ca3.93c2345f3eb1d4b0e1244e722a9bfb6e.0 Via: SIP/2.0/UDP some-domain.net:5078;rport=5078;received=10.199.240.135;branch=z9hG4bK9ca3.89b66f1dd6e86a5922180b8ed8475072.0 Via: SIP/2.0/UDP 10.199.240.179:7060;received=10.199.240.179;rport=7060;branch=z9hG4bKPj269365e0-798d-404b-bb77-2ad78472905c From: "Penny" <sip:1015@10.199.240.179>;tag=ba402508-a640-409f-ba30-dffdfe499f43 To: <sip:jyu3xsfkrz6c5qn@10.199.240.135> Contact: <sip:asterisk@10.199.240.179:7060;alias=10.199.240.179~7060~1> Call-ID: c3a406ca-9ac7-423d-9697-06d0603f48d5 CSeq: 22619 INVITE Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, MESSAGE, REFER Supported: timer, replaces, norefersub Session-Expires: 1800 Min-SE: 90 P-Asserted-Identity: "Penny" <sip:1015@10.199.240.179> Max-Forwards: 68 User-Agent: Awesome Calling Platform 3.0 Content-Type: application/sdp Content-Length: 463 *Response from POLYCOM * 2020/01/20 10:31:22.054766 37.17.41.5:49811 -> 10.199.240.19:5078 SIP/2.0 400 Bad Request Via: SIP/2.0/TCP some-domain.net:5078;branch=z9hG4bK9ca3.93c2345f3eb1d4b0e1244e722a9bfb6e.0 Via: SIP/2.0/UDP some-domain.net:5078;rport=5078;received=10.199.240.135;branch=z9hG4bK9ca3.89b66f1dd6e86a5922180b8ed8475072.0 Via: SIP/2.0/UDP 10.199.240.179:7060;received=10.199.240.179;rport=7060;branch=z9hG4bKPj269365e0-798d-404b-bb77-2ad78472905c From: "Penny" <sip:1015@10.199.240.179>;tag=ba402508-a640-409f-ba30-dffdfe499f43 To: <sip:jyu3xsfkrz6c5qn@10.199.240.135>;tag=8BC58304-83D9B045 CSeq: 22619 INVITE Call-ID: c3a406ca-9ac7-423d-9697-06d0603f48d5 Record-Route: <sip:10.199.240.19:5078;transport=tcp;r2=on;lr;nat=yes;rtp=bridge>, <sip:10.199.240.19:5078;r2=on;lr;nat=yes;rtp=bridge>, <sip:10.199.240.235:5078;lr> User-Agent: PolycomVVX-VVX_450-UA/5.8.0.12848 Accept-Language: en Content-Length: 0 Any ideas how to fix it? -- Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html

3 6

$vn vs $var
by Alex Balashov 31 Jan '20

31 Jan '20

Hi, I must have missed the discussion about it somewhere, but what is the inspiration for the new $vn variable container? According to the documentation, the only difference is that it can hold $null values, whereas variables initialised in $var to $null are coerced into an integer value of 0. But why was this a concern? Why is it necessary? Is it not confusing to users? Thanks, -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

2 1

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

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