March 2019 - sr-users - kamailio.org

UAC Module OPTIONS requests
by Greg Adams 06 Mar '19

06 Mar '19

Hey there, I'm wondering if any is able to help me. Trying to figure out how one might send OPTIONS request (ie the keepalive module) for registrations originating from the uac module? Have managed to figure out tcp keep alives but for some reason my connection is being closed even though they are sending, so hoping to try sending OPTIONS and see if that does it. It looks like the keepalive module only has an internal api doesn't actually expose the method to enable keepalives on individual TCP connections. Any help would be greatly appreciated!

2 1

Kamailio not recognizing SIP requests
by Sergio Charrua 06 Mar '19

06 Mar '19

Hi all! got a Kamailio doing load balancing to multiple Asterisk boxes. Kamailio is connected to a carrier's SIP trunk, and distributes calls to Asterisk. Receiving calls from carrier's SIP trunk works perfectly: kamailio will use dispatcher module to distribute calls between Asterisk boxes. No problems! Kamailio is also connected to the WWW, receiving calls from any authorized IP (whitelisted in Firewall). The problem is that if I get a call from the WWW and a from whitelisted IP, kamailio does not detect any INVITE (note that the IP address is not registered). here is the SIP Request (IPs are obfuscated) INVITE sip:+351234567890@10.19.139.66 SIP/2.0 Record-Route: <sip:11.22.33.44:5060 ;r2=on;transport=udp;ftag=11592086_6772d868_135fa74b-2c83-4d5f-9882-4125b131c703;l Record-Route: <sip:222.33.44.55:5060 ;r2=on;transport=udp;ftag=11592086_6772d868_135fa74b-2c83-4d5f-9882-4125b131c703r> CSeq: 1 INVITE From: <sip:+351999999999@somewhere.com >;tag=11592086_6772d868_135fa74b-2c83-4d5f-9882-4125b131c703 To: <sip:+351234567890@10.19.139.66> Max-Forwards: 65 P-Asserted-Identity: "+351999999999" <sip:+351999999999@sip.somewhere.com> Date: Tue, 05 Mar 2019 15:55:24 GMT Min-SE: 120 Call-ID: 799ee9a8cd02e066e2811d8052759715(a)0.0.0.0 Via: SIP/2.0/UDP 11.22.33.44:5060;branch=z9hG4bK6b36.f67ca7e4.0 Via: SIP/2.0/UDP 222.33.44.55:5060 ;branch=z9hG4bK135fa74b-2c83-4d5f-9882-4125b131c703_6772d868_106-113479085018764135 Contact: "+351999999999" <sip:+351999999999@222.33.44.55:5060;transport=udp> Allow: INVITE,ACK,CANCEL,OPTIONS,BYE User-Agent: SomeSIPGateway Content-Type: application/sdp X-SIPGW-CallSid: CA6a5691a75bb7b915c09c7931e253f542 Content-Length: 262 v=0 o=root 1219665045 1219665045 IN IP4 55.66.77.88 s=SomeSIPGateway c=IN IP4 55.66.77.88 t=0 0 m=audio 14326 RTP/AVP 0 8 101 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=sendrecv SIP Messages using SNGrep: 11.22.33.44:5060 10.19.139.66:5060 ----------+--------- ----------+--------- 15:55:25.980727 | INVITE (SDP) | +0.596007 | --------------------------> | 15:55:26.576734 | INVITE (SDP) | +1.003393 | ------------------------>>> | 15:55:27.580127 | INVITE (SDP) | +1.978513 | ------------------------>>> | 15:55:29.558640 | INVITE (SDP) | | ------------------------>>> | I've checked that Kamailio is listennig to all interfaces (OK) and to port 5060 (OK). As we can see above, SNGrep shows the incoming message to Kamailio (10.19.139.66) but it gets stuck there as there are no other messages. Kamailio.log doesn't show anything too, just like if the request (INVITE) is not recognizes a a SIP message. all other use cases work fine : - from SIP Carrier's trunk OK - from registered SIP user OK - from registered SIP Trunk ok only from a not registered SIP trunk I get this behaviour.... Any clue? Thanks in advance, *Sérgio * www.voip.pt

2 1

ACKs + BYEs coming from the wrong interface/ip
by Boden Garman 06 Mar '19

06 Mar '19

Hello list! I am trying to troubleshoot an issue we are having where we sometimes see an ACK in response to a 200 OK (SDP) come from the a different IP address to the rest of dialogue. The client ignore the traffic from the different IP and the call set up fails. Kamailio is multihomed on two IPs and this client is registered with the first IP address. I have done some searching on this and seen a few others with the issue, it seems like it's the ACK in the loose_route() section of WITHINDLG in the default kamailio.cfg file. I tried the force_send_socket solution one other person suggested but this caused issues with other kinds of dialogues, perhaps I did it incorrectly? Thanks for your time Boden Here is my attempt to solve the issue and config snippets mhomed=1 # ----- rr params ----- # set next param to 1 to add value to ;lr param (helps with some UAs) modparam("rr", "enable_full_lr", 1) # do not append from tag to the RR (no need for this script) modparam("rr", "append_fromtag", 1) # Handle requests within SIP dialogs route[WITHINDLG] { if (!has_totag()) return; # sequential request within a dialog should # take the path determined by record-routing if (loose_route()) { route(DLGURI); # this is the attempt to use the right IP if ($(route_uri{uri.host}) == VRRP_IP) { force_send_socket(VRRP_IP); } else if ($(route_uri{uri.host}) == KAM01_IP) { force_send_socket(KAM01_IP); } if (is_method("BYE")) { setflag(FLT_ACC); # do accounting ... setflag(FLT_ACCFAILED); # ... even if the transaction fails } else if (is_method("ACK")) { # ACK is forwarded statelessly route(NATMANAGE); } else if (is_method("NOTIFY")) { # Add Record-Route for in-dialog NOTIFY as per RFC 6665. record_route(); } route(RELAY); exit; } if (is_method("SUBSCRIBE") && uri == myself) { # in-dialog subscribe requests route(PRESENCE); exit; } if (is_method("ACK")) { if (t_check_trans()) { # no loose-route, but stateful ACK; # must be an ACK after a 487 # or e.g. 404 from upstream server route(RELAY); exit; } else { # ACK without matching transaction ... ignore and discard exit; } } sl_send_reply("404", "Not here"); exit; } For example (please excuse formatting) xxx.xx.xxx.97:5060 xxx.xx.xxx.96:5060 yyy.yyy.102.96:58308 xxx.xx.xxx.27:5060 ----------w--------- ----------w--------- ----------w--------- ----------w--------- x INVITE (SDP) x x x x --------------------------> x x x x 100 trying -- your call is x x x x <-------------------------- x x x x x INVITE (SDP) x x x x --------------------------> x x x x 100 Trying x x x x <-------------------------- x x x x 180 Ringing x x x x <-------------------------- x x x 180 Ringing x x x x <-------------------------- x x x x x 200 OK (SDP) x x x x <-------------------------- x x x 200 OK (SDP) x x x x <-------------------------- x x x x ACK x x x x --------------------------> x x x x x x ACK x x x x <-------------------------- x x x 200 OK (SDP) x x x x <<<------------------------ x x

1 0

Kamctl / kamcmd
by Daniel W. Graham 05 Mar '19

05 Mar '19

Are there any known compatibility issues with kamctl and mysql 8.0.x? Getting access denied when executing kamctl command. Kamcmd just hangs when executed. Kamctlrc is setup proper and connection can be made direct from shell to database using the same credentials. -dan

3 11

Selects and KEMI
by Alexandru Covalschi 05 Mar '19

05 Mar '19

Is there any way to use selects in KEMI? I understand it's syntax sugar, but maybe there's a workaround. ________________________________ Regards, Alexandru Covalschi VoIP Engineer and System Administrator tel: +380 97 24 75445

1 0

it's auth module send clear text password?
by PICCORO McKAY Lenz 05 Mar '19

05 Mar '19

if kamailio doe snot use TLS all the mechanish in atuh module are send the pasword nude to the network? Lenz McKAY Gerardo (PICCORO) http://qgqlochekone.blogspot.com

3 4

evapi_async + python3 KEMI
by Alexandru Covalschi 05 Mar '19

05 Mar '19

Hello list, I'm trying to use async evapi with app_python3 KEMI, but I don't know how to get t_suspend variables. What am I doing is connecting to evapi via telnet and making a call, which successfully reaches that point: if KSR.evapi.async_relay(str(KSR.pv.get("$T(id_label)"))): KSR.xlog.xinfo("processing suspended in transaction [" + str(KSR.pv.get("$T(id_index)")) + ":" + str(KSR.pv.get("$T(id_label)")) +"]\n"); I have the id_label in the log, but in telnet I have None. How can I get transaction index and label transferred using python3 KEMI? Shall I use KSR.x.modf (in that case I'm losing almost all KEMI benefits)?.. ________________________________ Regards, Alexandru Covalschi VoIP Engineer and System Administrator tel: +380 97 24 75445

2 3

Cannot start kamailio with TLS
by Adesh Pandey 04 Mar '19

04 Mar '19

Hi Guys, After enabling TLS i am getting following error in Kamailio 5.1 /usr/sbin/kamailio[2214]: ERROR: tls [tls_util.h:42]: tls_err_ret(): load_cert:error:20074002:BIO routines:file_ctrl:system lib /usr/sbin/kamailio[2214]: ERROR: tls [tls_util.h:42]: tls_err_ret(): load_cert:error:140DC002:SSL routines:use_certificate_chain_file:system lib /usr/sbin/kamailio[2214]: ERROR: <core> [core/sr_module.c:940]: init_mod_child(): error while initializing module tls (/usr/lib/x86_64-linux-gnu/kamailio/modules/tls.so) (idx: 0 rank: -127 desc: [main]) My tls.conf is as follows: [server:default] method = TLSv1+ verify_certificate = no require_certificate = no private_key = /etc/kamailio/keys/my.key.pem certificate = /etc/kamailio/keys/my.crt.pem #ca_list = /etc/kamailio/tls/cacert.pem #crl = /etc/kamailio/tls/crl.pem # This is the default client domain, settings # in this domain will be used for all outgoing # TLS connections that do not match any other # client domain in this configuration file. # We require that servers present valid certificate. # [client:default] #method = TLSv1 verify_certificate = yes require_certificate = yes Please hep me to understand and fix the issue.

2 2

tm.so --> segfault at 3135352e36 ip 00007f761bb57ed1 sp 00007fff9db8b1c0 error 4 in tm.so
by Abdoul Osséni 04 Mar '19

04 Mar '19

Hello, Hello dear list, Today, I have had mutiples crashes. It seems it linked to tm.so module. -rw------- 1 root kamailio 4299702272 Feb 25 13:08 core.kamailio.sig11.29204 -rw------- 1 root kamailio 1453023232 Feb 25 13:12 core.kamailio.sig11.29203 -rw------- 1 root kamailio 1416065024 Feb 25 13:12 core.kamailio.sig11.29207 -rw------- 1 root kamailio 4299681792 Feb 25 13:16 core.kamailio.sig11.19047 -rw------- 1 root kamailio 2108506112 Feb 25 13:20 core.kamailio.sig11.19043 -rw------- 1 root kamailio 4299689984 Feb 25 13:34 core.kamailio.sig11.19247 -rw------- 1 root kamailio 4299681792 Feb 25 13:34 core.kamailio.sig11.19246 -rw------- 1 root kamailio 4299698176 Feb 25 13:35 core.kamailio.sig11.19248 -rw------- 1 root kamailio 4299689984 Feb 25 13:35 core.kamailio.sig11.19243 -rw------- 1 root kamailio 4299685888 Feb 25 13:35 core.kamailio.sig11.19244 -rw------- 1 root kamailio 4299689984 Feb 25 13:36 core.kamailio.sig11.19242 root@sbc:/var/cores# gdb /usr/local/sbin/kamailio core.kamailio.sig11.29204 GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1 Copyright (C) 2014 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html > This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/local/sbin/kamailio...done. [New LWP 29204] warning: .dynamic section for "/lib/x86_64-linux-gnu/libpthread.so.0" is not at the expected address (wrong library or version mismatch?) Warning: couldn't activate thread debugging using libthread_db: Cannot find new threads: generic error warning: File "/lib/x86_64-linux-gnu/libthread_db-1.0.so" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". To enable execution of this file add add-auto-load-safe-path /lib/x86_64-linux-gnu/libthread_db-1.0.so line to your configuration file "/root/.gdbinit". To completely disable this security protection add set auto-load safe-path / line to your configuration file "/root/.gdbinit". For more information about this security protection see the "Auto-loading safe path" section in the GDB manual. E.g., run from the shell: info "(gdb)Auto-loading safe path" warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. Warning: couldn't activate thread debugging using libthread_db: Cannot find new threads: generic error warning: File "/lib/x86_64-linux-gnu/libthread_db-1.0.so" auto-loading has been declined by your `auto-load safe-path' set to "$debugdir:$datadir/auto-load". warning: Unable to find libthread_db matching inferior's thread library, thread debugging will not be available. Core was generated by `/usr/local/sbin/kamailio -P /var/run/kamailio/kamailio.pid -f /usr/local/etc/ka'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f68b9bb4515 in reply_received (p_msg=0x7f693ccd5cc8) at t_reply.c:2240 2240 last_uac_status=uac->last_received; (gdb) Any ideas? Regards Abdoul

3 8

crash at 480 reply to INVITE
by Juha Heinanen 04 Mar '19

04 Mar '19

Kamailio 5.2 crashed when it received 480 reply to INVITE. Below is backtrace from the core file. The crash happens in t_reply.c on the last line of this block: uac=&t->uac[branch]; LM_DBG("org. status uas=%d, uac[%d]=%d local=%d is_invite=%d)\n", t->uas.status, branch, uac->last_received, is_local(t), is_invite(t)); last_uac_status=uac->last_received; Earlier it was checked that the transaction was found. Its uac[0] seems to be broken. -- Juha ----------------------------------------- Program terminated with signal SIGSEGV, Segmentation fault. #0_ 0x00007f1073e234c3 in reply_received (p_msg=0x7f1076b605f0) at t_reply.c:2240 2240_ _ _ t_reply.c: No such file or directory. (gdb) bt full #0_ 0x00007f1073e234c3 in reply_received (p_msg=0x7f1076b605f0) at t_reply.c:2240 _ _ _ _ _ _ _ msg_status = 480 _ _ _ _ _ _ _ last_uac_status = 1590315756 _ _ _ _ _ _ _ ack = 0x50550c4 <error: Cannot access memory at address 0x50550c4> _ _ _ _ _ _ _ ack_len = 4 _ _ _ _ _ _ _ branch = 0 _ _ _ _ _ _ _ reply_status = 29 _ _ _ _ _ _ _ onreply_route = 9941216 _ _ _ _ _ _ _ cancel_data = {cancel_bitmap = 0, reason = {cause = 0, u = {text = {s = 0x0, len = 1590087991}, e2e_cancel = 0x0, packed_hdrs = {s = 0x0, len = 1590087991}}}} _ _ _ _ _ _ _ uac = 0x0 _ _ _ _ _ _ _ t = 0x7f105dfe6480 _ _ _ _ _ _ _ lack_dst = {send_sock = 0x555b5f02720f <buf+431>, to = {s = {sa_family = 29127, sa_data = "XXX"}, sin = {sin_family = 29127, sin_port = 24322, sin_addr = {s_addr = 21851}, sin_zero = "XXX"}, sin6 = { _ _ _ _ _ _ _ _ _ _ _ _ _ sin6_family = 29127, sin6_port = 24322, sin6_flowinfo = 21851, sin6_addr = {__in6_u = {__u6_addr8 = "XXX", __u6_addr16 = {XXX, XXX, XXX, XXX, XXX, XXX, XXX, XXX}, __u6_addr32 = {XXX, XXX, XXX, _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ XXX}}}, sin6_scope_id = 1980563656}}, id = 32528, proto = 112 'p', send_flags = {f = 30268, blst_imask = 32528}} _ _ _ _ _ _ _ backup_user_from = 0x0 _ _ _ _ _ _ _ backup_user_to = 0xXXX <qm_info+46> _ _ _ _ _ _ _ backup_domain_from = 0xXXX _ _ _ _ _ _ _ backup_domain_to = 0xXXX _ _ _ _ _ _ _ backup_uri_from = 0x0 _ _ _ _ _ _ _ backup_uri_to = 0xXXX _ _ _ _ _ _ _ backup_xavps = 0x45ed834e3 _ _ _ _ _ _ _ replies_locked = 1 _ _ _ _ _ _ _ branch_ret = 1593995512 _ _ _ _ _ _ _ prev_branch = 21851 _ _ _ _ _ _ _ blst_503_timeout = 340003632 _ _ _ _ _ _ _ hf = 0x7f1076490810 _ _ _ _ _ _ _ onsend_params = {req = 0x7f10763c4898, rpl = 0x7f10763c4888, param = 0x97b5f0, code = 10751248, flags = 0, branch = 0, t_rbuf = 0xaf95c0, dst = 0x7f1076db4fc0 <__syslog>, send_buf = {s = 0x555b5ed834e3 "INFO", len = 134217728}} _ _ _ _ _ _ _ ctx = {rec_lev = 1593995791, run_flags = 21851, last_retcode = 1593995708, jmp_env = {{__jmpbuf = {48, 139708676767760, 93849330384899, -7479270984431321856, 93850924380609, 139708690288576, 93850921612515, 134217728}, __mask_was_saved = 12582912, __saved_mask = { _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __val = {6, 140720648489936, 139708687844848, 140720648490064, 93850920720905, 93850924380373, 139708676767760, 140720648489904, 139708469727337, 139708679781296, 139708687844848, 139708684105760, 140720648490560, 5888963087, 93849330384896, 11507136}}}}} _ _ _ _ _ _ _ bctx = 0x7f10760d0010 _ _ _ _ _ _ _ keng = 0x0 _ _ _ _ _ _ _ __func__ = "reply_received" #1_ 0x0000555b5eadf4dc in do_forward_reply (msg=0x7f1076b605f0, mode=0) at core/forward.c:747 _ _ _ _ _ _ _ new_buf = 0x0 _ _ _ _ _ _ _ dst = {send_sock = 0x0, to = {s = {sa_family = 0, sa_data = '\000' <repeats 13 times>}, sin = {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "XXX"}, sin6 = {sin6_family = 0, sin6_port = 0, sin6_flowinfo = 0, sin6_addr = { _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ __in6_u = {__u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}}, id = 0, proto = 0 '\000', send_flags = {f = 0, blst_imask = 0}} _ _ _ _ _ _ _ new_len = 0 _ _ _ _ _ _ _ r = 1 _ _ _ _ _ _ _ ip = {af = XXX, len = 32528, u = {addrl = {XXX, 95}, addr32 = {XXX, XXX, XXX, 0}, addr16 = {XXX, XXX, XXX, XXX, XXX, XXX, XXX, XXX}, addr = "XXX"}} _ _ _ _ _ _ _ s = 0x7ffc14440c68 "" _ _ _ _ _ _ _ len = 32764 _ _ _ _ _ _ _ __func__ = "do_forward_reply" #2_ 0x0000555b5eae12f9 in forward_reply (msg=0x7f1076b605f0) at core/forward.c:852 No locals. #3_ 0x0000555b5eb5b679 in receive_msg ( _ _ _ buf=0x555b5f027060 <buf> "SIP/2.0 480 Request Terminated\r\nVia: SIP/2.0/UDP XXX;branch=z9hG4bKe951.40cf95b28fe54d0cbda88a8fa4c91d48.0\r\nVia: SIP/2.0/UDP XXX:5060;branch=z9hG4bK04B95fa49ac99a7fa91\r\nTo: <sip:XXX"..., len=431, _ _ _ rcv_info=0x7ffc14440ff0) at core/receive.c:433 _ _ _ _ _ _ _ msg = 0x7f1076b605f0 _ _ _ _ _ _ _ ctx = {rec_lev = 0, run_flags = 0, last_retcode = 1, jmp_env = {{__jmpbuf = {139708690288576, 9004276570109933907, 93850921612515, 134217728, 12582912, 6, 9004276570114128211, 3007006209029601619}, __mask_was_saved = 0, __saved_mask = {__val = {0, 0, 0, 1, _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ 139708266465728, 0, 0, 4634971920, 139708266465728, 140720648490768, 93850918093314, 120, 93850918093450, 139708680838560, 139708680838560, 140720648490832}}}}} _ _ _ _ _ _ _ bctx = 0x0 _ _ _ _ _ _ _ ret = 1 _ _ _ _ _ _ _ stats_on = 0 _ _ _ _ _ _ _ tvb = {tv_sec = 0, tv_usec = 0} _ _ _ _ _ _ _ tve = {tv_sec = 0, tv_usec = 0} _ _ _ _ _ _ _ tz = {tz_minuteswest = 0, tz_dsttime = 0} _ _ _ _ _ _ _ diff = 0 _ _ _ _ _ _ _ inb = {s = 0x555b5f027060 <buf> "SIP/2.0 480 Request Terminated\r\nVia: SIP/2.0/UDP XXX;branch=z9hG4bKe951.40cf95b28fe54d0cbda88a8fa4c91d48.0\r\nVia: SIP/2.0/UDP XXX:5060;branch=z9hG4bK04B95fa49ac99a7fa91\r\nTo: <sip:XXX"..., len = 431} _ _ _ _ _ _ _ netinfo = {data = {s = 0x0, len = 0}, rcv = 0x0, dst = 0x0} _ _ _ _ _ _ _ keng = 0x0 _ _ _ _ _ _ _ evp = {data = 0x7ffc14440df0, rcv = 0x7ffc14440ff0, dst = 0x0} _ _ _ _ _ _ _ cidlockidx = 0 _ _ _ _ _ _ _ cidlockset = 0 _ _ _ _ _ _ _ errsipmsg = 0 _ _ _ _ _ _ _ __func__ = "receive_msg" #4_ 0x0000555b5ea30dc4 in udp_rcv_loop () at core/udp_server.c:541 _ _ _ _ _ _ _ len = 431 _ _ _ _ _ _ _ buf = "SIP/2.0 480 Request Terminated\r\nVia: SIP/2.0/UDP XXX;branch=z9hG4bKe951.40cf95b28fe54d0cbda88a8fa4c91d48.0\r\nVia: SIP/2.0/UDP XXX:5060;branch=z9hG4bK04B95fa49ac99a7fa91\r\nTo: <sip:XXX"... _ _ _ _ _ _ _ tmp = 0x8000000 <error: Cannot access memory at address 0x8000000> _ _ _ _ _ _ _ from = 0x7f10764b1da0 _ _ _ _ _ _ _ fromlen = 16 _ _ _ _ _ _ _ ri = {src_ip = {af = 2, len = 4, u = {addrl = {XXX, XXX}, addr32 = {XXX, XXX, XXX, XXX}, addr16 = {XXX, XXX, XXX, XXX, XXX, XXX, XXX, XXX}, addr = "XXX"}}, dst_ip = { _ _ _ _ _ _ _ _ _ _ _ af = 2, len = 4, u = {addrl = {XXX, 0}, addr32 = {XXX, 0, 0, 0}, addr16 = {XXX, XXX, 0, 0, 0, 0, 0, 0}, addr = "XXX", '\000' <repeats 11 times>}}, src_port = 5060, dst_port = 5060, proto_reserved1 = 0, proto_reserved2 = 0, src_su = {s = { _ _ _ _ _ _ _ _ _ _ _ _ _ sa_family = 2, sa_data = "XXX"}, sin = {sin_family = 2, sin_port = 50195, sin_addr = {s_addr = XXX}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 2, sin6_port = 50195, sin6_flowinfo = 1345864889, _ _ _ _ _ _ _ _ _ _ _ _ _ sin6_addr = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}}, bind_address = 0xXXX, proto = 1 '\001'} _ _ _ _ _ _ _ evp = {data = 0x0, rcv = 0x0, dst = 0x0} _ _ _ _ _ _ _ printbuf = "XXX"... _ _ _ _ _ _ _ i = 1981052368 _ _ _ _ _ _ _ j = 5 _ _ _ _ _ _ _ l = 0 _ _ _ _ _ _ _ __func__ = "udp_rcv_loop" #5_ 0x0000555b5e9c8e32 in main_loop () at main.c:1645 _ _ _ _ _ _ _ i = 4 _ _ _ _ _ _ _ pid = 0 _ _ _ _ _ _ _ si = 0x7f1076130940 _ _ _ _ _ _ _ si_desc = "udp receiver child=4 sock=XXX:5060XXX" _ _ _ _ _ _ _ nrprocs = 8 _ _ _ _ _ _ _ woneinit = 1 _ _ _ _ _ _ _ __func__ = "main_loop" #6_ 0x0000555b5e9d0fdd in main (argc=17, argv=0x7ffc14441698) at main.c:2675 _ _ _ _ _ _ _ cfg_stream = 0x555b5fe5c010 _ _ _ _ _ _ _ c = -1 _ _ _ _ _ _ _ r = 0 _ _ _ _ _ _ _ tmp = 0x7ffc14442f30 "" _ _ _ _ _ _ _ tmp_len = 340006256 _ _ _ _ _ _ _ port = 32764 _ _ _ _ _ _ _ proto = 340006352 _ _ _ _ _ _ _ options = 0x555b5ed33020 ":f:cm:M:dVIhEeb:l:L:n:vKrRDTN:W:w:t:u:g:P:G:SQ:O:a:A:x:X:Y:" _ _ _ _ _ _ _ ret = -1 _ _ _ _ _ _ _ seed = 1181662442 _ _ _ _ _ _ _ rfd = 4 _ _ _ _ _ _ _ debug_save = 0 _ _ _ _ _ _ _ debug_flag = 0 _ _ _ _ _ _ _ dont_fork_cnt = 0 _ _ _ _ _ _ _ n_lst = 0x0 _ _ _ _ _ _ _ p = 0xffffffff <error: Cannot access memory at address 0xffffffff> _ _ _ _ _ _ _ st = {st_dev = 19, st_ino = 17502, st_nlink = 2, st_mode = 16832, st_uid = 115, st_gid = 123, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1547850959, tv_nsec = 183989794}, st_mtim = {tv_sec = 1547851014, _ _ _ _ _ _ _ _ _ _ _ tv_nsec = 719730801}, st_ctim = {tv_sec = 1547851014, tv_nsec = 955611149}, __glibc_reserved = {0, 0, 0}} _ _ _ _ _ _ _ __func__ = "main"

2 20