sr-dev September 2020

sr-dev@lists.kamailio.org

12 participants
269 discussions

[kamailio/kamailio] topos module seems to break re-SUBSCRIBE routing to downstream destinations (#1724)

by George Diamantopoulos

### Description Kamailio seems to fail to properly route in-dialog SUBSCRIBE with the topos module enabled. In this configuration, SUBSCRIBEs are expected to be delivered to a downstream UAS, an asterisk instance in the internal network. record_route() is executed for all initial requests, including SUBSCRIBEs. Routing is performed correctly with the topos module disabled, no other modifications were needed.  ### Troubleshooting I haven't been able to work around this issue in any other way other than disabling the topos module. #### Reproduction The configuration used is a heavily modified version of the example configuration file, but the handling of SUBSCRIBEs is generally simple. The initial SUBSCRIBE is subject to some tests, the R-URI is edited and dispatched to a farm of asterisk servers based on some criteria. Record Routing is enforced, so subsequent in-dialog re-SUBSCRIBEs are expected to be routed with loose_route(), which doesn't seem to handle things properly.  #### Debugging Data I'm attaching kamailio logs with debug=4, cfg_trace  #### Log Messages See attachments  #### SIP Traffic Please see: https://www.cloudshark.org/captures/d2643aae7f2a  ### Possible Solutions Using topoh instead for topos, but unfortunately this will break communication for other reasons (messages too large/UDP fragmentation for some peers). ### Additional Information * **Kamailio Version** Tried with kamailio 5.1.6 and kamailio 5.3.0-dev0 deb.kamailio.org repositories were used to acquire binaries for both versions * **Operating System**: Debian Stretch  [resubscribe.log](https://github.com/kamailio/kamailio/files/2586440/resubsc… -- 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/1724

3 years, 6 months

[kamailio/kamailio] uri_restore_rcv_alias() tried twice for local request (#2014)

by Alex Hermann

### Description While debugging an issue with locally generated in-dialog requests I stumbled upon some weirdness with the alias functionality from the nathelper module. The dialog modules tries to handle an alias parameter when sending an in-dialog request by calling ```uri_restore_rcv_alias()``` in the function ```build_dlg_t()```. A few instructions later, the same is attempted by the tm module in the function ```req_within()```. It seems to me that the attempt by the dialog module is redundant and can be removed. And while at it, IMHO it should be removed from the tm module too. This is functionality introduced by the nathelper module. Nowhere in the documentation it is mentioned there is some automatic handling of the alias parameter. If handling is needed for local requests, the script writer can call ```handle_uri_alias()``` from within local_route. If the functionality has to stay, may I suggest that the code in the nathelper module makes use of the ```uri_restore_rcv_alias()``` function instead of having its own duplicate implementation. Less maintenance, easier debugging. -- 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/2014

3 years, 6 months

[kamailio/kamailio] rtpengine: stats for rtpengine command and reply from rtpengine (#1699)

by Surendra Tiwari

### Description rightnow, there is no stats about command sent to rtpengine and getting reply from rtpengine. There should be a stats that will tell that number of offer request sent: number of answer request sent: number of delete request sent: number of failed request for offer [after retry]: number of failed request for answer [after retry]: number of failed request for delete [after retry]: This will help to identify actual number of failed request.  ### Troubleshooting #### Reproduction  #### Debugging Data  ``` (paste your debugging data here) ``` #### Log Messages  ``` (paste your log messages here) ``` #### SIP Traffic  ``` (paste your sip traffic here) ``` ### Possible Solutions  ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` (paste your output here) ``` * **Operating System**:  ``` (paste your output here) ``` -- 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/1699

3 years, 6 months

[kamailio/kamailio] 100% CPU usage after NTP date update (#2046)

by Benjamin Marty

#### Reproduction Install newest Kamailio 5.2. Change date e.g. 2 Years into the future. (Make sure you have no daemon running which prohibits those operations): ``` sudo date -s "2014-12-25 $(date +%H:%M:%S)" ``` ``` sudo date -s "2016-12-25 $(date +%H:%M:%S)" ``` Kamailio now uses the whole CPU to do stuff: ``` top - 08:10:35 up 14 days, 1:29, 2 users, load average: 3.77, 1.83, 1.05 Tasks: 212 total, 11 running, 201 sleeping, 0 stopped, 0 zombie %Cpu(s): 95.9 us, 1.5 sy, 2.2 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.4 si, 0.0 st MiB Mem : 926.1 total, 116.3 free, 382.5 used, 427.3 buff/cache MiB Swap: 100.0 total, 40.4 free, 59.6 used. 423.4 avail Mem PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13264 root 20 0 89720 3944 2676 R 44.9 0.4 0:05.15 kamailio 13266 root 20 0 89720 4000 2736 R 37.3 0.4 0:04.63 kamailio 13267 root 20 0 89720 4912 3488 R 36.0 0.5 0:04.37 kamailio 13270 root 20 0 89720 4540 3240 R 36.0 0.5 0:05.85 kamailio 13269 root 20 0 89720 4000 2736 R 34.7 0.4 0:04.81 kamailio 13265 root 20 0 89720 3944 2680 R 34.4 0.4 0:04.61 kamailio 13261 root 20 0 89720 3952 2676 R 32.2 0.4 0:04.44 kamailio 13262 root 20 0 89720 3944 2676 R 31.8 0.4 0:04.72 kamailio 13256 root 20 0 89720 4752 3540 R 30.3 0.5 0:07.04 kamailio 13268 root 20 0 89720 4000 2736 R 30.3 0.4 0:04.49 kamailio 18021 root 20 0 40116 11884 5728 D 13.7 1.3 0:01.11 apt-get ``` There are multiple mailing list entries regarding this issue: https://lists.kamailio.org/pipermail/sr-users/2015-October/090465.html https://lists.kamailio.org/pipermail/sr-users/2015-November/090487.html https://lists.kamailio.org/pipermail/sr-users/2019-June/105967.html https://lists.kamailio.org/pipermail/sr-users/2019-August/106428.html I was able to get rid of the issue with uncommenting the mentioned part of the code. But I'm quite sure that's not a fix :) ![image](https://user-images.githubusercontent.com/11159719/63680341-b6d67880-c7f3-11e9-825b-529e7ec26b2e.png) -- 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/2046

3 years, 6 months

[kamailio/kamailio] commit 0436af5abd8b73e breaks startup for jsonrpcs module (#2391)

by Henning Westerholt

The commit 0436af5abd8b73e breaks startup for jsonrpcs module. Logs: ``` Jul 5 10:04:41 kam01 kamailio[4951]: ERROR: jsonrpcs [jsonrpcs_sock.c:358]: jsonrpc_dgram_init_server(): failed to change the owner/group for /var/run/kamailio/kamailio_rpc.sock to 33.0;Operation not permitted[1] Jul 5 10:04:41 kam01 kamailio[4951]: CRITICAL: jsonrpcs [jsonrpcs_sock.c:423]: jsonrpc_dgram_init_socks(): initializing datagram server function returned error Jul 5 10:04:41 kam01 kamailio[4951]: ERROR: jsonrpcs [jsonrpcs_sock.c:246]: jsonrpc_dgram_mod_init(): init datagram sockets function failed Jul 5 10:04:41 kam01 kamailio[4951]: ERROR: jsonrpcs [jsonrpcs_mod.c:1150]: mod_init(): cannot initialize datagram transport Jul 5 10:04:41 kam01 kamailio[4951]: ERROR: <core> [core/sr_module.c:849]: init_mod(): Error while initializing module jsonrpcs (/usr/lib/x86_64-linux-gnu/kamailio/modules/jsonrpcs.so) ``` Relevant cfg: ``` loadmodule "jsonrpcs.so" modparam("jsonrpcs", "pretty_format", 1) modparam("jsonrpcs", "dgram_user", "www-data") modparam("jsonrpcs", "dgram_group", "root") modparam("jsonrpcs", "transport", 7) ``` Previously Kamailio was started as root, and then configured with -u $USER and -g $GROUP to drop privileges to the lower user/group. During startup Kamailio could create the socket with the correct permissions. The mentioned commit changes this to: start Kamailio directly as user Kamailio and group Kamailio, which don't have privileges create the sockets with the correct permissions. Not sure about the motivation about this change, so I don't want to simple revert it. Maybe @sergey-safarov or other developers can comment. -- 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/2391

3 years, 6 months

[kamailio/kamailio] RR param static buffer not emptied, when using record_route_advertised_address() (#2486)

by thomas-lentz

### Description When specifying a _record_route_advertised_address()_ before using the uac_replace function (for changing the FROM and TO Header field URIs), the rr param static buffer doesn't get emptied and a fallowing CALL (not a request in the same call) contains the rr params of the first call placed after restarting kamailio (to get the buffer resetted). ### Troubleshooting Restarting kamailio will reset the wrong buffer pointer and gets you another functioning call. Alternatively place the _record_route_advertised_address()_ after using uac_replace function. #### Reproduction use record_route_advertised_address() before doing a uac_replace. This will get the vst and vsf parameters doubled in the rr of the second call after kamailio is restarted. When you place a call the first call proxied will carry only one set of vsf & vst parameters in the RR. The second call will carry the vst & vsf of the first call and a set of vst & vsf of the second call. If the uac_replace is replacing the same URIs the contents of the two sets of vsf and vst parameters in the RR Header will be identical. uac.so config: loadmodule "uac.so" modparam("uac", "restore_mode","auto"); #### Analysis record_route() empties the RR param static buffer as follows, if it contains other message's params: if (rr_param_buf.len && rr_param_msg!=_m->id) { /* rr_params were set for a different message -> reset buffer */ rr_param_buf.len = 0; } But unfortunately, record_route_advertised_address() / record_route_preset() does not do this – it does NOT check/clean the buffer before adding RR. So if the static buffer contains old entries (e.g. from an old call's subsequent request), wrong rr parameters are added. This happens with uac module: restore_uri() is called for subsequent requests (via callback). restore_uri() calls (unnecessarily): if ( uac_rrb.add_rr_param(msg, &add_to_rr)!=0 ) { LM_ERR("add rr param failed\n"); goto failed; } So, if record_route has not yet been performed at this stage, add_rr_param() adds an entry to the static rr param buffer. (for subsequent request, record_route won't be performed) If, for a following call, record_route_advertised_address() / record_route_preset() is called, the buffer is not checked/emptied, and old/wrong rr params are added.--> ``` #### SIP Traffic ``` Record-Route URI [truncated]: sip:my.node.com;transport=tls;r2=on;ftag=2ccb63ad;lr;vsf=AAAAAAAAAAAAAAAAAAAAADkIA0Mdsdfsdfhc2guY29tO3VzZXI9cGhvN0LmNvbQbmU-;vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMQEEEESwksdfsdfhddCBteAgccAQN0LmNvbQ- Record-Route Host Part: my.node.com Record-Route URI parameter: transport=tls Record-Route URI parameter: r2=on Record-Route URI parameter: ftag=2ccb63ad Record-Route URI parameter: lr Record-Route URI parameter: vsf=AAAAAAAAAAAAAAAAAAAAADkIA0Mdsdfsdfhc2guY29tO3VzZXI9cGhvN0LmNvbQbmU- Record-Route URI parameter: vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMQEEEESwksdfsdfhddCBteAgccAQN0LmNvbQ-- Record-Route URI parameter: vst=AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAMQEEEESwksdfsdfhddCBteAgccAQN0LmNvbQ-- Record-Route URI parameter: vsf=AAAAAAAAAAAAAAAAAAAAADkIA0Mdsdfsdfhc2guY29tO3VzZXI9cGhvN0LmNvbQbmU- Record-Route URI parameter: did=4a8.56a2 URI, vsf & vst anonymised ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.2.7 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, 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, TLS_PTHREAD_MUTEX_SHARED ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144 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 8.3.0 ``` * **Operating System**: ``` 4.19.0-10-amd64 #1 SMP Debian 4.19.132-1 (2020-07-24) 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/2486

3 years, 6 months

[kamailio/kamailio] NATHELPER: fix_nated_sdp does not support a=rtcp headers (#2459)

by Olle E. Johansson

### Description fix_nated_sdp() function with an IP address as argument supports modifying the media line and the connection line but not a=rtcp. It would be helpful if it did that line too. ### Expected behavior a=rtcp:<port> IN ip4 <new IP> #### Actual observed behavior No modification -- 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/2459

3 years, 6 months

[kamailio/kamailio] add rtpproxy in kamailio/kamailio-ci:master-alpine (#2109)

by Gaurav Bmotra

hi can any one help me to add rtpproxy in kamailio/kamailio-ci:master-alpine thank you -- 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/2109

3 years, 6 months

[kamailio/kamailio] Can't install kamailio-sipcapture-daemon-config package due to missing dependency (#1861)

by pwakano

kamailio-sipcapture-daemon-config can't be installed because it depends on the kamailio-sipcapture package, which can't be found...  Use the http://download.opensuse.org/repositories/home:/kamailio:/v5.2.x-rpms/CentO… repo and try to install the kamailio-sipcapture-daemon-config. The dependency can't be resolved and so the package does not install. It is not clear if the dependency is missing or if it is not valid. ``` # yum install kamailio-sipcapture-daemon-config Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: mirror.optus.net * epel: mirror.optus.net * extras: mirror.intergrid.com.au * updates: mirror.intergrid.com.au Resolving Dependencies --> Running transaction check ---> Package kamailio-sipcapture-daemon-config.x86_64 0:5.2.1-1.el7.centos will be installed --> Processing Dependency: kamailio-sipcapture = 5.2.1 for package: kamailio-sipcapture-daemon-config-5.2.1-1.el7.centos.x86_64 --> Finished Dependency Resolution Error: Package: kamailio-sipcapture-daemon-config-5.2.1-1.el7.centos.x86_64 (home_kamailio_v5.2.x-rpms) Requires: kamailio-sipcapture = 5.2.1 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest # yum deplist kamailio-sipcapture-daemon-config Loaded plugins: fastestmirror Loading mirror speeds from cached hostfile * base: mirror.optus.net * epel: mirror.optus.net * extras: mirror.intergrid.com.au * updates: mirror.intergrid.com.au package: kamailio-sipcapture-daemon-config.x86_64 5.2.1-1.el7.centos dependency: /bin/sh provider: bash.x86_64 4.2.46-31.el7 dependency: kamailio-sipcapture = 5.2.1 Unsatisfied dependency ```      * **Operating System**:  ``` # uname -a Linux voice-conn-kamailio-1 3.10.0-957.5.1.el7.x86_64 #1 SMP Fri Feb 1 14:54:57 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux # cat /etc/redhat-release CentOS Linux release 7.6.1810 (Core) ``` -- 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/1861

3 years, 6 months

[kamailio/kamailio] The kamailio 5.2.1 crashs (#2468)

by pkv12

### Description The kamailio 5.2.1 crashed ### Troubleshooting pbx server sending INVITE to kamailio and kamailio prepare SIP packet for send to VOIP operator by domain kamailio tries to resolv the domain and in this time pbx server send to kamailio the CANCEL. kamailio canceling this dialog and after a while, it gives an error that the domain cannot be resolved and prepeare 478 answer for pbx server. But data for send is apsent and kamailio is segfailt kamailio is started with option use_dns_cache=no #### Reproduction if the resolv of the domain direction occurs later than the cancel message for the current dialog #### Debugging Data ``` GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-100.el7_4.1 Copyright (C) 2013 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-redhat-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... [New LWP 11633] Reading symbols from /usr/sbin/kamailio...Reading symbols from /usr/lib/debug/usr/sbin/kamailio.debug...done. done. Missing separate debuginfo for /usr/lib64/libcom_err.so.2 Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/a3/832734347dca522438308c9f08f45524c65c9b Missing separate debuginfo for Try: yum --enablerepo='*debug*' install /usr/lib/debug/.build-id/22/8adfe0d8c0852bf24f80b24803da9e25f5b21e [Thread debugging using libthread_db enabled] Using host libthread_db library "/usr/lib64/libthread_db.so.1". Core was generated by `/usr/sbin/kamailio -P /var/run/kamailio/kamailio.pid -f /etc/kamailio/kamailio.'. Program terminated with signal 11, Segmentation fault. #0 0x00007f47ff3bfbdf in _reply (trans=0x7f47016be920, p_msg=0x0, code=478, reason=0x7fffc8309960, lock=1) at t_reply.c:649 649 if (code>=180 && p_msg->to (gdb) set print pretty on (gdb) set print elements 0 (gdb) set height 0 (gdb) bt full #0 0x00007f47ff3bfbdf in _reply (trans=0x7f47016be920, p_msg=0x0, code=478, reason=0x7fffc8309960, lock=1) at t_reply.c:649 len = 135 buf = 0x80f7aa <__FUNCTION__.6461> "get_hdr_field" dset = 0x7f4800730ca8 "\001" bm = { to_tag_val = { s = 0x7fffc83099a0 "\001", len = 7009219 } } dset_len = 0 #1 0x00007f47ff3c7ae3 in t_reply (t=0x7f47016be920, p_msg=0x0, code=478, text=0x7fffc83099c0 "Unresolvable destination (478/TM)") at t_reply.c:1609 reason = { s = 0x7fffc83099c0 "Unresolvable destination (478/TM)", len = 33 } #2 0x00007f47ff40752f in kill_transaction (trans=0x7f47016be920, error=-478) at t_funcs.c:176 err_buffer = "Unresolvable destination (478/TM)\000\000\000\006\000\000\000\300\333+\371F\177\000\000\000\000\000\000\000\000\000\000.\001\000\000\000\240\232\060\310\377\177\000\000\324P#\371F\177\000\000\220ŀ\000\000\000\000\000R\270n\000\000\000\000\000`\232\060\310\377\177\000\000\210\037.\000H\177\000\000\211զ\000\000\000\000\000\rӦ\000\000\000\000" sip_err = 478 reply_ret = 5771 ret = 33 __FUNCTION__ = "kill_transaction" #3 0x00007f47ff380ed5 in t_unref (p_msg=0x7f48002e24f0) at t_lookup.c:1488 kr = REQ_ERR_DELAYED __FUNCTION__ = "t_unref" #4 0x00007f47ff41ccbc in w_t_unref (foo=0x7f48002e24f0, flags=2147483649, bar=0x0) at tm.c:684 No locals. #5 0x000000000055034d in exec_post_script_cb (msg=0x7f48002e24f0, type=REQUEST_CB_TYPE) at core/script_cb.c:182 cb = 0x7f4800289210 flags = 2147483649 __FUNCTION__ = "exec_post_script_cb" #6 0x00000000005cc77b in receive_msg ( buf=0xa6d1a0 <buf.6868> "INVITE sip:0972678971@y.y.y.y:5060 SIP/2.0\r\nVia: SIP/2.0/UDP x.x.x.x:5062;rport;branch=z9hG4bKPjcf4a2178-296c-40ac-99e1-0e038f278451\r\nFrom: \"380674606869\" <sip:380674606869@x.x.x.x>;tag=238ff2c1-ef95-4064-8541-c6e413343f3c\r\nTo: <sip:0972678971@y.y.y.y>\r\nContact: <sip:asterisk@x.x.x.x:5062>\r\nCall-ID: d03a799f-bb2a-4dc1-864a-b80d82d38705\r\nCSeq: 20737 INVITE\r\nAllow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE\r\nSupported: 100rel, timer, replaces, norefersub\r\nSession-Expires: 1800\r\nMin-SE: 90\r\nX-SEND-TO-TRUNK: ukrteltrunk\r\nMax-Forwards: 69\r\nUser-Agent: Asterisk PBX 13.26.0\r\nContent-Type: application/sdp\r\nContent-Length: 284\r\n\r\nv=0\r\no=- 812296846 812296846 IN IP4 x.x.x.x\r\ns=Asterisk\r\nc=IN IP4 x.x.x.x\r\nt=0 0\r\nm=audio 16438 RTP/AVP 8 0 3 101\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:3 GSM/8000\r\na=rtpmap:101 telephone-event/8000\r\na=fmtp:101 0-16\r\na=ptime:20\r\na=maxptime:150\r\na=sendrecv\r\n", len=1001, rcv_info=0x7fffc830a120) at core/receive.c:362 msg = 0x7f48002e24f0 ctx = { rec_lev = 0, run_flags = 0, last_retcode = 1, jmp_env = {{ __jmpbuf = {783203822, 2071767658820475464, 4295072, 140736552019552, 0, 0, 2071767658933721672, -2071667646532085176}, __mask_was_saved = 0, __saved_mask = { __val = {0, 0, 0, 0, 0, 0, 0, 0, 0, 167503724544, 10998176, 140736552018216, 0, 55834574851, 783203822, 4295072} } }} } bctx = 0x0 ret = 0 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 = 0xa6d1a0 <buf.6868> "INVITE sip:0972678971@y.y.y.y:5060 SIP/2.0\r\nVia: SIP/2.0/UDP x.x.x.x:5062;rport;branch=z9hG4bKPjcf4a2178-296c-40ac-99e1-0e038f278451\r\nFrom: \"380674606869\" <sip:380674606869@x.x.x.x>;tag=238ff2c1-ef95-4064-8541-c6e413343f3c\r\nTo: <sip:0972678971@y.y.y.y>\r\nContact: <sip:asterisk@x.x.x.x:5062>\r\nCall-ID: d03a799f-bb2a-4dc1-864a-b80d82d38705\r\nCSeq: 20737 INVITE\r\nAllow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE\r\nSupported: 100rel, timer, replaces, norefersub\r\nSession-Expires: 1800\r\nMin-SE: 90\r\nX-SEND-TO-TRUNK: ukrteltrunk\r\nMax-Forwards: 69\r\nUser-Agent: Asterisk PBX 13.26.0\r\nContent-Type: application/sdp\r\nContent-Length: 284\r\n\r\nv=0\r\no=- 812296846 812296846 IN IP4 x.x.x.x\r\ns=Asterisk\r\nc=IN IP4 x.x.x.x\r\nt=0 0\r\nm=audio 16438 RTP/AVP 8 0 3 101\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:3 GSM/8000\r\na=rtpmap:101 telephone-event/8000\r\na=fmtp:101 0-16\r\na=ptime:20\r\na=maxptime:150\r\na=sendrecv\r\n", len = 1001 } netinfo = { data = { s = 0xa6d1a0 <buf.6868> "INVITE sip:0972678971@y.y.y.y:5060 SIP/2.0\r\nVia: SIP/2.0/UDP x.x.x.x:5062;rport;branch=z9hG4bKPjcf4a2178-296c-40ac-99e1-0e038f278451\r\nFrom: \"380674606869\" <sip:380674606869@x.x.x.x>;tag=238ff2c1-ef95-4064-8541-c6e413343f3c\r\nTo: <sip:0972678971@y.y.y.y>\r\nContact: <sip:asterisk@x.x.x.x:5062>\r\nCall-ID: d03a799f-bb2a-4dc1-864a-b80d82d38705\r\nCSeq: 20737 INVITE\r\nAllow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE\r\nSupported: 100rel, timer, replaces, norefersub\r\nSession-Expires: 1800\r\nMin-SE: 90\r\nX-SEND-TO-TRUNK: ukrteltrunk\r\nMax-Forwards: 69\r\nUser-Agent: Asterisk PBX 13.26.0\r\nContent-Type: application/sdp\r\nContent-Length: 284\r\n\r\nv=0\r\no=- 812296846 812296846 IN IP4 x.x.x.x\r\ns=Asterisk\r\nc=IN IP4 x.x.x.x\r\nt=0 0\r\nm=audio 16438 RTP/AVP 8 0 3 101\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:3 GSM/8000\r\na=rtpmap:101 telephone-event/8000\r\na=fmtp:101 0-16\r\na=ptime:20\r\na=maxptime:150\r\na=sendrecv\r\n", len = 1001 }, rcv = 0x7fffc830a120, dst = 0x0 } keng = 0x0 evp = { data = 0x7fffc8309ca0, rcv = 0x7fffc830a120, dst = 0x0 } cidlockidx = 0 cidlockset = 0 errsipmsg = 0 __FUNCTION__ = "receive_msg" #7 0x00000000004c8ad7 in udp_rcv_loop () at core/udp_server.c:541 len = 1001 buf = "INVITE sip:0972678971@y.y.y.y:5060 SIP/2.0\r\nVia: SIP/2.0/UDP x.x.x.x:5062;rport;branch=z9hG4bKPjcf4a2178-296c-40ac-99e1-0e038f278451\r\nFrom: \"380674606869\" <sip:380674606869@x.x.x.x>;tag=238ff2c1-ef95-4064-8541-c6e413343f3c\r\nTo: <sip:0972678971@y.y.y.y>\r\nContact: <sip:asterisk@x.x.x.x:5062>\r\nCall-ID: d03a799f-bb2a-4dc1-864a-b80d82d38705\r\nCSeq: 20737 INVITE\r\nAllow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE\r\nSupported: 100rel, timer, replaces, norefersub\r\nSession-Expires: 1800\r\nMin-SE: 90\r\nX-SEND-TO-TRUNK: ukrteltrunk\r\nMax-Forwards: 69\r\nUser-Agent: Asterisk PBX 13.26.0\r\nContent-Type: application/sdp\r\nContent-Length: 284\r\n\r\nv=0\r\no=- 812296846 812296846 IN IP4 x.x.x.x\r\ns=Asterisk\r\nc=IN IP4 x.x.x.x\r\nt=0 0\r\nm=audio 16438 RTP/AVP 8 0 3 101\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:3 GSM/8000\r\na=rtpmap:101 telephone-event/8000\r\na=fmtp:101 0-16\r\na=ptime:20\r\na=maxptime:150\r\na=sendrecv\r\n\000\070\060\060\060\r\na=rtpmap:3 GSM/8000\r\na=rtpmap:101 telephone-event/8000\r\na=fmtp:101 0-16\r\na=ptime:20\r\na=maxptime:150\r\na=sendrecv\r\n\000AVP 8 0 3 101\r\na=rtpmap:8 PCMA/8000\r\na=rtpmap:0 PCMU/8000\r\na=rtpmap:3 GSM/8000\r\na=rtpmap:101 telephone-event/8000\r\na=fmtp:101 0-16\r\na=ptime:20\r\na=maxptime:150\r\na=sendrecv\r\n\000yes\r\na=rtpmap:98 telephone-event/8000\r\na=fmtp:98 0-15\r\na=ptime:20\r\na=sendrecv\r\n\000\n\000vent/8000\r\na=fmtp:98 0-15\r\na=ptime:20\r\na=sendrecv\r\n\000\r\na=ptime:20\r\na=sendrecv\r\n", '\000' <repeats 64080 times> tmp = 0xa7d1a0 <buff.5595> "188.163.212.3" from = 0x7f47ffb77c20 fromlen = 16 ri = { src_ip = { af = 2, len = 4, u = { addrl = {870309723, 140736552018432}, addr32 = {870309723, 0, 3358630400, 32767}, addr16 = {57179, 13279, 0, 0, 41472, 51248, 32767, 0}, addr = "[\337\337\063\000\000\000\000\000\242\060\310\377\177\000" } }, dst_ip = { af = 2, len = 4, u = { addrl = {1510032313, 0}, addr32 = {1510032313, 0, 0, 0}, addr16 = {17337, 23041, 0, 0, 0, 0, 0, 0}, addr = "\271C\001Z", '\000' <repeats 11 times> } }, src_port = 5062, dst_port = 5060, proto_reserved1 = 0, proto_reserved2 = 0, src_su = { s = { sa_family = 2, sa_data = "\023\306[\337\337\063\000\000\000\000\000\000\000" }, sin = { sin_family = 2, sin_port = 50707, sin_addr = { s_addr = 870309723 }, sin_zero = "\000\000\000\000\000\000\000" }, sin6 = { sin6_family = 2, sin6_port = 50707, sin6_flowinfo = 870309723, 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 = 0x7f47ffb76bb0, proto = 1 '\001' } evp = { data = 0x0, rcv = 0x0, dst = 0x0 } printbuf = '\000' <repeats 17 times>, "\273}\000\000\000\000\000\326\301b\312|\000\000\000\344\034~\000\000\000\000\000V\274}\000\000\000\000\000\060\000\000\000\000\000\000\000\020`\255\377G\177\000\000\000\000\000\000\024\000\000\000\240Qx", '\000' <repeats 13 times>, "\264Qx\000\000\000\000\000.\000\000\000\000\240\211A\000\000\000\000\000\240\237\060\310\377\177\000\000\354\315c\000\000\000\000\000Xw\267\377G\177\000\000\220\241\262", '\000' <repeats 17 times>, "\004\000\000\000@\240\060\310\377\177\000\000P\326c\000\000\000\000\000\177", '\000' <repeats 15 times>, "\002", '\000' <repeats 19 times>, "\024\000\000\000\240Qx", '\000' <repeats 13 times>, "\200\241\262\000\n\000\000\000\240Qx\000\000\000\000\000\200\241\262\000\000\000\000\000@\240\060\310\377\177\000\000Xw\267\377G\177\000\000\000\000\000\000\000\000\000\000.\000\000\000\000\240\211A\000\000\000\000\000`\246\060\310\377\177", '\000' <repeats 18 times>, "p\240\060\310\377\177\000\000d\341c\000\000\000\000\000\240Qx\000\000\000\000\000\200\241\262", '\000' <repeats 13 times>, "\024\000\000\000\n\000\000\000\000\242\060\310\377\177\000\000H}J\000\000\000\000\000\240\211A\000\000\000\000\000`\246\060\310\377\177", '\000' <repeats 19 times>, "\241\060\310\377\177\000\000\\yq\000\001\000\000\000\240Qx\000\000\000\000\000\024\000\000\000G\177\000\000\000\000\000\000\000\000\000\000$B\262\000\000\000\000\000$F\262\000\000\000\000\000\\\022\001\377F\177\000\000\240\211A\000\000\000\000\000`\246\060\310\377\177", '\000' <repeats 17 times> i = 10 j = 4776853 l = 1178866774 __FUNCTION__ = "udp_rcv_loop" #8 0x0000000000424e5c in main_loop () at main.c:1645 i = 0 pid = 0 si = 0x7f47ffb76bb0 si_desc = "udp receiver child=0 sock=y.y.y.y:5060\000\000H\177\000\000\260\242\060\310\377\177\000\000\371\233h\000\000\000\000\000\240\211A\000\000\000\000\000\310F\264\376F\177", '\000' <repeats 14 times>, "\001\000\000\000\000\243\060\310\377\177\000\000(&\001\377F\177\000\000\310\064\020\367F\177\000\000\260Z\374\377G\177\000" nrprocs = 8 woneinit = 0 __FUNCTION__ = "main_loop" #9 0x000000000042c4e9 in main (argc=13, argv=0x7fffc830a668) at main.c:2675 cfg_stream = 0xdce010 c = -1 r = 0 tmp = 0x7fffc830af30 "" tmp_len = 0 port = 0 proto = 0 options = 0x7697a0 ":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 = 995796597 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 0 n_lst = 0x0 p = 0x0 st = { st_dev = 19, st_ino = 54007, st_nlink = 2, st_mode = 16832, st_uid = 989, st_gid = 987, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 4096, st_blocks = 0, st_atim = { tv_sec = 1558706870, tv_nsec = 104275123 }, st_mtim = { tv_sec = 1598532057, tv_nsec = 575105503 }, st_ctim = { tv_sec = 1598532057, tv_nsec = 575105503 }, __unused = {0, 0, 0} } __FUNCTION__ = "main" (gdb) info locals cfg_stream = 0xdce010 c = -1 r = 0 tmp = 0x7fffc830af30 "" tmp_len = 0 port = 0 proto = 0 options = 0x7697a0 ":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 = 995796597 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 0 n_lst = 0x0 p = 0x0 st = { st_dev = 19, st_ino = 54007, st_nlink = 2, st_mode = 16832, st_uid = 989, st_gid = 987, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 4096, st_blocks = 0, st_atim = { tv_sec = 1558706870, tv_nsec = 104275123 }, st_mtim = { tv_sec = 1598532057, tv_nsec = 575105503 }, st_ctim = { tv_sec = 1598532057, tv_nsec = 575105503 }, __unused = {0, 0, 0} } __FUNCTION__ = "main" (gdb) list 644 if (dset) { 645 add_lump_rpl(p_msg, dset, dset_len, LUMP_RPL_HDR); 646 } 647 } 648 649 if (code>=180 && p_msg->to 650 && (get_to(p_msg)->tag_value.s==0 651 || get_to(p_msg)->tag_value.len==0)) { 652 calc_crc_suffix( p_msg, tm_tag_suffix ); 653 buf = build_res_buf_from_sip_req(code, reason, &tm_tag, p_msg, (gdb) frame 0 #0 0x00007f47ff3bfbdf in _reply (trans=0x7f47016be920, p_msg=0x0, code=478, reason=0x7fffc8309960, lock=1) at t_reply.c:649 649 if (code>=180 && p_msg->to (gdb) info locals len = 135 buf = 0x80f7aa <__FUNCTION__.6461> "get_hdr_field" dset = 0x7f4800730ca8 "\001" bm = { to_tag_val = { s = 0x7fffc83099a0 "\001", len = 7009219 } } dset_len = 0 (gdb) p p_msg $1 = (struct sip_msg *) 0x0 (gdb) p p_msg->to Cannot access memory at address 0xa0 ``` #### Log Messages ``` Aug 28 14:09:45 ua1api [11633]: NOTICE: d03a799f-bb2a-4dc1-864a-b80d82d38705 -=> INCOMING REQUEST: method:INVITE si:x.x.x.x sp:5062 fU:380674606869 => rU:0972678971 proto:udp fu:sip:380674606869@x.x.x.x => ru:sip:0972678971@1 85.67.1.90:5060 ... Aug 28 14:09:51 ua1api [11654]: NOTICE: d03a799f-bb2a-4dc1-864a-b80d82d38705 -=> INCOMING REQUEST: method:CANCEL si:x.x.x.x sp:5062 fU:380674606869 => rU:0972678971 proto:udp fu:sip:380674606869@x.x.x.x => ru:sip:0972678971@y.y.y.y:5060 ... Aug 28 14:10:05 ua1api [11633]: ERROR: <core> [core/resolve.c:1685]: sip_hostport2su(): could not resolve hostname: "sip-trunk.ukrtelecom.ua" Aug 28 14:10:05 ua1api [11633]: ERROR: tm [ut.h:309]: uri2dst2(): failed to resolve "sip-trunk.ukrtelecom.ua" Aug 28 14:10:05 ua1api [11633]: ERROR: tm [t_fwd.c:1735]: t_forward_nonack(): failure to add branches Aug 28 14:10:05 ua1api [11633]: NOTICE: d03a799f-bb2a-4dc1-864a-b80d82d38705 -=> T_RELAY: result: -478 Aug 28 14:13:25 ua1api [11680]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 15 Aug 28 14:13:25 ua1api [11605]: ALERT: <core> [main.c:756]: handle_sigs(): child process 11633 exited by a signal 11 Aug 28 14:13:25 ua1api [11605]: ALERT: <core> [main.c:759]: handle_sigs(): core was generated ``` #### SIP Traffic ``` <--- size: 1100 -- SIP from: UDP:x.x.x.x:5062 => to: UDP:y.y.y.y:5060 ---> INVITE sip:0972678971@y.y.y.y:5060 SIP/2.0 Via: SIP/2.0/UDP x.x.x.x:5062;rport;branch=z9hG4bKPjcf4a2178-296c-40ac-99e1-0e038f278451 From: "380674606869" <sip:380674606869@x.x.x.x>;tag=238ff2c1-ef95-4064-8541-c6e413343f3c To: <sip:0972678971@y.y.y.y> Contact: <sip:asterisk@x.x.x.x:5062> Call-ID: d03a799f-bb2a-4dc1-864a-b80d82d38705 CSeq: 20737 INVITE Allow: OPTIONS, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REGISTER, REFER, MESSAGE Supported: 100rel, timer, replaces, norefersub Session-Expires: 1800 Min-SE: 90 X-SEND-TO-TRUNK: ukrteltrunk Max-Forwards: 70 User-Agent: Asterisk PBX 13.26.0 Content-Type: application/sdp Content-Length: 284 v=0 o=- 812296846 812296846 IN IP4 x.x.x.x s=Asterisk c=IN IP4 x.x.x.x t=0 0 m=audio 16438 RTP/AVP 8 0 3 101 a=rtpmap:8 PCMA/8000 a=rtpmap:0 PCMU/8000 a=rtpmap:3 GSM/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 a=maxptime:150 a=sendrecv <--- size: 493 -- SIP from: UDP:y.y.y.y:5060 => to: UDP:x.x.x.x:5062 ---> SIP/2.0 100 Trying -- your call is important to us Via: SIP/2.0/UDP x.x.x.x:5062;rport=5062;branch=z9hG4bKPjcf4a2178-296c-40ac-99e1-0e038f278451;received=x.x.x.x From: "380674606869" <sip:380674606869@x.x.x.x>;tag=238ff2c1-ef95-4064-8541-c6e413343f3c To: <sip:0972678971@y.y.y.y> Call-ID: d03a799f-bb2a-4dc1-864a-b80d82d38705 CSeq: 20737 INVITE Content-Length: 0 <--- size: 537 -- SIP from: UDP:x.x.x.x:5062 => to: UDP:y.y.y.y:5060 ---> CANCEL sip:0972678971@y.y.y.y:5060 SIP/2.0 Via: SIP/2.0/UDP x.x.x.x:5062;rport;branch=z9hG4bKPjcf4a2178-296c-40ac-99e1-0e038f278451 From: "380674606869" <sip:380674606869@x.x.x.x>;tag=238ff2c1-ef95-4064-8541-c6e413343f3c To: <sip:0972678971@y.y.y.y> Call-ID: d03a799f-bb2a-4dc1-864a-b80d82d38705 CSeq: 20737 CANCEL Reason: Q.850;cause=0 Max-Forwards: 70 User-Agent: Asterisk PBX 13.26.0 Content-Length: 0 <--- size: 404 -- SIP from: UDP:y.y.y.y:5060 => to: UDP:x.x.x.x:5062 ---> SIP/2.0 487 Request canceled Via: SIP/2.0/UDP x.x.x.x:5062;rport=5062;branch=z9hG4bKPjcf4a2178-296c-40ac-99e1-0e038f278451;received=x.x.x.x From: "380674606869" <sip:380674606869@x.x.x.x>;tag=238ff2c1-ef95-4064-8541-c6e413343f3c To: <sip:0972678971@y.y.y.y>;tag=29c79435251d3407255ea131eaa41394-e324 Call-ID: d03a799f-bb2a-4dc1-864a-b80d82d38705 CSeq: 20737 INVITE Content-Length: 0 <--- size: 418 -- SIP from: UDP:y.y.y.y:5060 => to: UDP:x.x.x.x:5062 ---> SIP/2.0 200 ok -- no more pending branches Via: SIP/2.0/UDP x.x.x.x:5062;rport=5062;branch=z9hG4bKPjcf4a2178-296c-40ac-99e1-0e038f278451;received=x.x.x.x From: "380674606869" <sip:380674606869@x.x.x.x>;tag=238ff2c1-ef95-4064-8541-c6e413343f3c To: <sip:0972678971@y.y.y.y>;tag=29c79435251d3407255ea131eaa41394-e324 Call-ID: d03a799f-bb2a-4dc1-864a-b80d82d38705 CSeq: 20737 CANCEL Content-Length: 0 <--- size: 550 -- SIP from: UDP:x.x.x.x:5062 => to: UDP:y.y.y.y:5060 ---> ACK sip:0972678971@y.y.y.y:5060 SIP/2.0 Via: SIP/2.0/UDP x.x.x.x:5062;rport;branch=z9hG4bKPjcf4a2178-296c-40ac-99e1-0e038f278451 From: "380674606869" <sip:380674606869@x.x.x.x>;tag=238ff2c1-ef95-4064-8541-c6e413343f3c To: <sip:0972678971@y.y.y.y>;tag=29c79435251d3407255ea131eaa41394-e324 Call-ID: d03a799f-bb2a-4dc1-864a-b80d82d38705 CSeq: 20737 ACK Max-Forwards: 70 User-Agent: Asterisk PBX 13.26.0 Content-Length: 0 ``` ### Additional Information * **Kamailio Version** - output of `kamailio -v` ``` version: kamailio 5.2.1 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, 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_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: compiled on 11:49:01 Jan 30 2019 with gcc 4.8.5 ``` * **Operating System**: ``` CentOS Linux release 7.4.1708 (Core) Linux ua1api.ringostat.net 3.10.0-693.21.1.el7.x86_64 #1 SMP Wed Mar 7 19:03:37 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/2468

3 years, 7 months

← Newer
1
...
6
7
8
9
10
11
12
...
27
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev September 2020