<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* https://lists.kamailio.org/mailman3/postorius/lists/sr-users.lists.kamailio…
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* https://lists.kamailio.org/mailman3/postorius/lists/sr-dev.lists.kamailio.o…
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
<!--
Explain what you did, what you expected to happen, and what actually happened.
-->
nat module crashes if app_lua initialize fail.
### Troubleshooting
#### Reproduction
<!--
If the issue can be reproduced, describe how it can be done.
-->
kamailio.cfg
```txt
### kamailio5.6.4
debug=2
log_stderror=no
memdbg=5
memlog=5
log_facility=LOG_LOCAL0
log_prefix="{$mt $hdr(CSeq) $ci} "
children=4
auto_aliases=no
enable_sctp=no
# listen=udp:192.168.31.63:5060
# mpath="/usr/local/lib/kamailio/modules/"
loadmodule "kex.so"
loadmodule "corex.so"
loadmodule "tm.so"
loadmodule "tmx.so"
loadmodule "sl.so"
loadmodule "pv.so"
loadmodule "xlog.so"
loadmodule "ctl.so"
loadmodule "cfg_rpc.so"
loadmodule "nats.so"
loadmodule "app_lua.so"
# modparam("ctl", "binrpc", "unix:/run/kamailio/kamailio_ctl")
modparam("nats", "nats_url", "nats://127.0.0.1:4222")
modparam("nats", "num_publish_workers", 1)
modparam("nats", "subject_queue_group", "sipserver:group")
modparam("app_lua", "load", "/etc/kamailio/kamailio.lua")
request_route {
sl_send_reply("200", "OK");
}
```
kamailio.lua
```lua
cjson = require "cjson" -- but without cjson
```
#### Debugging Data
<!--
If you got a core dump, use gdb to extract troubleshooting data - full backtrace,
local variables and the list of the code at the issue location.
gdb /path/to/kamailio /path/to/corefile
bt full
info locals
list
If you are familiar with gdb, feel free to attach more of what you consider to
be relevant.
-->
gdb kamailio core
```txt
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Core was generated by `kamailio'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f6691e9c62b in ?? () from /lib/x86_64-linux-gnu/libuv.so.1
[Current thread is 1 (Thread 0x7f6692ac9740 (LWP 82969))]
bt
#0 0x00007f6691e9c62b in ?? () from /lib/x86_64-linux-gnu/libuv.so.1
#1 0x00007f6691ea3856 in ?? () from /lib/x86_64-linux-gnu/libuv.so.1
#2 0x00007f6691ea398f in uv_poll_stop () from /lib/x86_64-linux-gnu/libuv.so.1
#3 0x00007f6691f48b81 in nats_destroy_workers () at nats_mod.c:601
#4 0x00007f6691f48c01 in mod_destroy () at nats_mod.c:614
#5 0x000055dad0bb4752 in destroy_modules () at core/sr_module.c:842
#6 0x000055dad0977132 in cleanup (show_status=0) at main.c:561
#7 0x000055dad0978d97 in shutdown_children (sig=15, show_status=0) at main.c:704
#8 0x000055dad0993c7b in main (argc=1, argv=0x7ffd4ca63688) at main.c:3093
bt full
#0 0x00007f6691e9c62b in ?? () from /lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#1 0x00007f6691ea3856 in ?? () from /lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#2 0x00007f6691ea398f in uv_poll_stop () from /lib/x86_64-linux-gnu/libuv.so.1
No symbol table info available.
#3 0x00007f6691f48b81 in nats_destroy_workers () at nats_mod.c:601
i = 0
worker = 0x7f668dceee10
pub_worker = 0x7f668dceeeb0
__func__ = "nats_destroy_workers"
#4 0x00007f6691f48c01 in mod_destroy () at nats_mod.c:614
__func__ = "mod_destroy"
#5 0x000055dad0bb4752 in destroy_modules () at core/sr_module.c:842
t = 0x7f6692368870
foo = 0x7f6692366d20
__func__ = "destroy_modules"
#6 0x000055dad0977132 in cleanup (show_status=0) at main.c:561
memlog = 0
__func__ = "cleanup"
#7 0x000055dad0978d97 in shutdown_children (sig=15, show_status=0) at main.c:704
__func__ = "shutdown_children"
#8 0x000055dad0993c7b in main (argc=1, argv=0x7ffd4ca63688) at main.c:3093
cfg_stream = 0x55dad295c380
c = -1
r = 0
tmp = 0x100000000 <error: Cannot access memory at address 0x100000000>
tmp_len = 0
port = 895
proto = 0
ahost = 0x0
aport = 0
options = 0x55dad0db4278 ":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 = 193248401
rfd = 4
debug_save = 0
debug_flag = 0
dont_fork_cnt = 0
n_lst = 0xc000
p = 0x0
--Type <RET> for more, q to quit, c to continue without paging--
st = {st_dev = 22, st_ino = 830, st_nlink = 2, st_mode = 16832, st_uid = 0, st_gid = 0, __pad0 = 0, st_rdev = 0, st_size = 60, st_blksize = 4096, st_blocks = 0,
st_atim = {tv_sec = 1679270080, tv_nsec = 182554285}, st_mtim = {tv_sec = 1679531455, tv_nsec = 805444368}, st_ctim = {tv_sec = 1679531455, tv_nsec = 805444368},
__glibc_reserved = {0, 0, 0}}
tbuf = "\000\000\000\000\000\000\000\000\377\377\377\377\000\000\000\000x\230ْf\177\000\000кܒf\177", '\000' <repeats 42 times>, "pvْf\177\000\000\r\000\000\000\000\000\000\000\230\341ɒf\177\000\000\230\066\246L\375\177\000\000H\355\350\320\332U\000\000 \260ܒf\177\000\000\256\217ڒf\177\000\000\001", '\000' <repeats 15 times>, "x\230ْf\177\000\000\300\370ڒf\177\000\000\274\032\255\222f\177\000\000\000\066\246L\375\177\000\000\001", '\000' <repeats 15 times>, "\230\066\246L\375\177\000\000ڱڒf\177\000\000\000\000\000\000\000\000\000\000"...
option_index = 0
long_options = {{name = 0x55dad0db66e6 "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x55dad0db1524 "version", has_arg = 0, flag = 0x0, val = 118}, {
name = 0x55dad0db66eb "alias", has_arg = 1, flag = 0x0, val = 1024}, {name = 0x55dad0db66f1 "subst", has_arg = 1, flag = 0x0, val = 1025}, {
name = 0x55dad0db66f7 "substdef", has_arg = 1, flag = 0x0, val = 1026}, {name = 0x55dad0db6700 "substdefs", has_arg = 1, flag = 0x0, val = 1027}, {
name = 0x55dad0db670a "server-id", has_arg = 1, flag = 0x0, val = 1028}, {name = 0x55dad0db6714 "loadmodule", has_arg = 1, flag = 0x0, val = 1029}, {
name = 0x55dad0db671f "modparam", has_arg = 1, flag = 0x0, val = 1030}, {name = 0x55dad0db6728 "log-engine", has_arg = 1, flag = 0x0, val = 1031}, {
name = 0x55dad0db6733 "debug", has_arg = 1, flag = 0x0, val = 1032}, {name = 0x55dad0db6739 "cfg-print", has_arg = 0, flag = 0x0, val = 1033}, {
name = 0x55dad0db6743 "atexit", has_arg = 1, flag = 0x0, val = 1034}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}}
__func__ = "main"
```
#### Log Messages
<!--
Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
(paste your log messages here)
```
#### SIP Traffic
<!--
If the issue is exposed by processing specific SIP messages, grab them with ngrep or save in a pcap file, then add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
(paste your sip traffic here)
```
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
kamailio 5.6.4 (x86_64/linux) a004cf
```
* **Operating System**:
<!--
Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...;
Kernel details (output of `lsb_release -a` and `uname -a`)
-->
```
Debian11
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3401
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3401(a)github.com>
### Description
In some situations the other side UA must reply with an inactive media stream. E.g. if video was added but not supported by the other side. The UAS then must answer with an m=video 0 RTP/.. line.
It seams that the video section must contain a c= line with an IP address for rtpengine to function. If there is no c line (no IP address) the SDP body cannot be parsed and thus no RTP proxy is invoked.
### Troubleshooting
Not easy to reproduce since the answer must bei "wrong". Is it correct to reply an SDP body (media = video) like this?
```
m=video 0 RTP/AVPF 96
a=label:1
a=inactive
a=mid:1
```
Maybe not (but Audiocodes SBC lates LTS version does it) - so we are dependent on other side now that this service works.
#### Reproduction
reInvite with Video to a UA that has no video Support (e.g. Bria -> Snom). Drop the c line in the video part with some textops in 200 OK (just to reproduce of course).
A -> B, connect the call
A -> + video, B has no video support
A presses hold
#### Log Messages
Incoming 200 OK after doing hold with an inactive video:
```
v=0
o=root 436040161 309284577 IN IP4 1.2.3.5
s=call
t=0 0
m=audio 14200 RTP/AVPF 9 8 126
c=IN IP4 1.2.3.5
a=ptime:20
a=recvonly
a=mid:0
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:126 telephone-event/8000
a=fmtp:126 0-15
m=video 0 RTP/AVPF 96
a=label:1
a=inactive
a=mid:1
Mar 27 17:52:22 c5p05es2-1 /usr/sbin/kamailio[2938205]: ERROR: <core> [core/parser/sdp/sdp.c:490]: parse_sdp_session(): can't find media IP in the message
Mar 27 17:52:22 c5p05es2-1 /usr/sbin/kamailio[2938205]: INFO: <script>: >>> Sending Reply: 200 OK (1.2.3.4:443 -> 100.108.48.38:65251)
```
Compare to working SDP parsing:
```
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:126 telephone-event/8000
a=fmtp:126 0-15
m=video 0 RTP/AVP 96
c=IN IP4 1.2.3.5
a=inactive
a=mid:1
Mar 27 18:00:17 c5p05es2-1 /usr/sbin/kamailio[2942881]: INFO: <script>: ONREPLY_ROUTE[FORWARD]
Mar 27 18:00:17 c5p05es2-1 /usr/sbin/kamailio[2942881]: INFO: <script>: ROUTE[RTPP_REPLY]
Mar 27 18:00:17 c5p05es2-1 /usr/sbin/kamailio[2942881]: INFO: <script>: > 200 with video
Mar 27 18:00:17 c5p05es2-1 /usr/sbin/kamailio[2942881]: INFO: <script>: > 200 with inactive video
Mar 27 18:00:17 c5p05es2-1 /usr/sbin/kamailio[2942881]: INFO: <script>: > Remove inactive video
Mar 27 18:00:17 c5p05es2-1 /usr/sbin/kamailio[2942881]: INFO: <script>: > Answer to WebRTC client: 200 - qijpuibkv6ufhnd282ks
Mar 27 18:00:17 c5p05es2-1 /usr/sbin/kamailio[2942881]: INFO: <script>: >>> Sending Reply: 200 OK (91.237.65.14:443 -> 80.108.48.38:65388)
```
### Possible Solutions
Tried to fix in script:
```
if(sdp_with_media("video")) xlog("L_INFO", "> $rs with video");
if(sdp_with_active_media("video")) xlog("L_INFO", "> $rs with active video");
if(!sdp_with_active_media("video")) xlog("L_INFO", "> $rs with inactive video");
if(sdp_with_media("video") && !sdp_with_active_media("video")) {
# try fix for RMT#60189
xlog("L_INFO", "> Remove inactive video");
sdp_remove_media("video");
msg_apply_changes(); # needed?
}
```
But since sdpops cannot parse it cannot remove the buggy media, too. See the log: non of the xlog is logging.
If there is inactive media the c line is not mandatory. The parser should accept this by adding a default IP of 0.0.0.0, if needed
Doing tricks with textops is not a easy nor performant solution to accept this wrong SDP from other parties.
### Additional Information
```
version: kamailio 5.6.4 (x86_64/linux)
flags: USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, 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_BLOCKLIST, 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 10.2.1
```
* **Operating System**:
Debian Bullseye
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3406
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3406(a)github.com>
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests. Please use this template only for bug reports.
If you have questions about using Kamailio or related to its configuration file, ask on sr-users mailing list:
* https://lists.kamailio.org/mailman3/postorius/lists/sr-users.lists.kamailio…
If you have questions about developing extensions to Kamailio or its existing C code, ask on sr-dev mailing list:
* https://lists.kamailio.org/mailman3/postorius/lists/sr-dev.lists.kamailio.o…
Please try to fill this template as much as possible for any issue. It helps the developers to troubleshoot the issue.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
Hi Team,
I am using kamailio as load balancer in my organization and I want to manipulate the cancel request from and to headers.
But kamailio is changing the requests when it sends out and its still using the one it receives from other end.
How do I change the kamailio to change the to domain when it sends the cancel request out?
<!--
Explain what you did, what you expected to happen, and what actually happened.
-->
### Troubleshooting
Code to handle cancel
if (is_method("CANCEL")) {
if (ends_with($td, "incoming.req.com")) {
xinfo("Updating CANCEL request");
uac_replace_to("sip:<number>@manipulated.to.domain.com");
$uac_req(turi)="sip:<number>@manipulated.to.domain.com";
append_hf("To: <"sip:<number>@manipulated.to.domain.com">");
#uac_req_send();
xinfo("Updating CANCEL request TD: $td");
}
if (t_check_trans()) {
route(RELAY);
}
exit;
}
SIP message:
CANCEL sip:<number>@mycompany.net SIP/2.0
Via: SIP/2.0/UDP <IP>;branch=z9hG4bK787.76dc73a7e90664fa84d8571e1281161d.0
Max-Forwards: 69
From: <sip:<fromNumber>@incoming.req.com>;tag=QQ8NBSygKDa0c
To: <sip:<toNumber>@incoming.req.com>
Call-ID: 1cc67943-bb08-4e52-9694-cb33210e7b3b
CSeq: 65568792 CANCEL
Content-Length: 0
Reason: Q.850;cause=16;text="NORMAL_CLEARING"
#### Reproduction
<!--
If the issue can be reproduced, describe how it can be done.
-->
#### Debugging Data
<!--
If you got a core dump, use gdb to extract troubleshooting data - full backtrace,
local variables and the list of the code at the issue location.
gdb /path/to/kamailio /path/to/corefile
bt full
info locals
list
If you are familiar with gdb, feel free to attach more of what you consider to
be relevant.
-->
```
(paste your debugging data here)
```
#### Log Messages
<!--
Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
(paste your log messages here)
```
#### SIP Traffic
<!--
If the issue is exposed by processing specific SIP messages, grab them with ngrep or save in a pcap file, then add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
(paste your sip traffic here)
```
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
(paste your output here)
```
* **Operating System**:
<!--
Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...;
Kernel details (output of `lsb_release -a` and `uname -a`)
-->
```
(paste your output here)
```
--
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/3409
You are receiving this because you are subscribed to this thread.
Message ID: <kamailio/kamailio/issues/3409(a)github.com>