sr-users

sr-users@lists.kamailio.org

46 participants
37553 discussions

crash when sending reply
by Juha Heinanen 02 Jul '21

02 Jul '21

Kamailio 5.5 crashed when sending reply (bt full below). Before the crash there had been several mysql related error messages ("Lost connection to MySQL server during query" and "Too many connections") in syslog when async worker tried to insert accounting data. So perhaps this core dump has something to do with that. -- Juha Reading symbols from /usr/bin/sip-proxy...done. [New LWP 21324] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/usr/bin/sip-proxy -f /etc/sip-proxy/sip-proxy.cfg -P /run/sip-proxy/sip-proxy.'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007fd274ce3b6e in run_trans_callbacks_internal (cb_lst=0x7fd2532503a8, type=512, trans=0x7fd253250330, params=0x7fff9b8eb2b0) at t_hooks.c:254 254 t_hooks.c: No such file or directory. (gdb) bt full #0 0x00007fd274ce3b6e in run_trans_callbacks_internal (cb_lst=0x7fd2532503a8, type=512, trans=0x7fd253250330, params=0x7fff9b8eb2b0) at t_hooks.c:254 cbp = 0x10 backup_from = 0x5613ccfb37f0 <def_list+16> backup_to = 0x5613ccfb37f8 <def_list+24> backup_dom_from = 0x5613ccfb3800 <def_list+32> backup_dom_to = 0x5613ccfb3808 <def_list+40> backup_uri_from = 0x5613ccfb37e0 <def_list> backup_uri_to = 0x5613ccfb37e8 <def_list+8> backup_xavps = 0x5613ccf56270 <_xavp_list_head> backup_xavus = 0x5613ccf56278 <_xavu_list_head> backup_xavis = 0x5613ccf56280 <_xavi_list_head> __func__ = "run_trans_callbacks_internal" #1 0x00007fd274ce41f7 in run_trans_callbacks_with_buf (type=512, rbuf=0x7fd253250400, req=0x7fd252d6dd20, repl=0x7fd2758bf0b0, flags=0) at t_hooks.c:303 params = {req = 0x7fd252d6dd20, rpl = 0x7fd2758bf0b0, param = 0x7fd254760f60, code = 486, flags = 0, branch = 0, t_rbuf = 0x7fd253250400, dst = 0x7fd253250450, send_buf = { s = 0x7fd25325b9f0 "@", len = 579}} trans = 0x7fd253250330 #2 0x00007fd274c88c15 in relay_reply (t=0x7fd253250330, p_msg=0x7fd2758bf0b0, branch=0, msg_status=486, cancel_data=0x7fff9b8eb580, do_put_on_wait=1) at t_reply.c:2133 relay = 0 save_clone = 0 buf = 0x7fd275ca0ff0 "SIP/2.0 486 Busy Here\r\nTo: <sip:XXXXX@XXXXX.com;user=phone>;tag=h7g4Esbg_11002529899813\r\nFrom: <sip:XXXXX@XXXXX>;tag=as6964f29d\r\nCal"... res_len = 579 relayed_code = 486 relayed_msg = 0x7fd2758bf0b0 reply_bak = 0x7fd2510f1000 bm = {to_tag_val = {s = 0x7fd25216e4c0 "@\003", len = 1377234752}} totag_retr = 0 reply_status = RPS_COMPLETED uas_rb = 0x7fd253250400 to_tag = 0x7fd25216e820 reason = {s = 0x7fd25216e830 "0", len = 1394935248} onsend_params = {req = 0x9b8eb420, rpl = 0x7fd274c6b10d <futex_get+40>, param = 0x1, code = 1359984720, flags = 32722, branch = 0, t_rbuf = 0x7fff9b8eb460, dst = 0xa0679800, send_buf = { s = 0x19b8eb450 <error: Cannot access memory at address 0x19b8eb450>, len = 1359984720}} ip = {af = 2609820752, len = 32767, u = {addrl = {94643040895493, 0}, addr32 = {3436528133, 22035, 0, 0}, addr16 = {16901, 52437, 22035, 0, 0, 0, 0, 0}, addr = "\005B\325\314\023V\000\000\000\000\000\000\000\000\000"}} __func__ = "relay_reply" #3 0x00007fd274c8de6b in reply_received (p_msg=0x7fd2758bf0b0) at t_reply.c:2680 msg_status = 486 last_uac_status = 180 ack = 0x7fd25216e830 "0" ack_len = 459 branch = 0 reply_status = 32722 onreply_route = 2 cancel_data = {cancel_bitmap = 0, reason = {cause = 0, u = {text = {s = 0x0, len = 1977055608}, e2e_cancel = 0x0, packed_hdrs = {s = 0x0, len = 1977055608}}}} uac = 0x7fd2532505c0 t = 0x7fd253250330 lack_dst = {send_sock = 0x40, to = {s = {sa_family = 49168, sa_data = "\207u\322\177\000\000\220\266\216\233\377\177\000"}, sin = {sin_family = 49168, sin_port = 30087, sin_addr = { s_addr = 32722}, sin_zero = "\220\266\216\233\377\177\000"}, sin6 = {sin6_family = 49168, sin6_port = 30087, sin6_flowinfo = 32722, sin6_addr = {__in6_u = { __u6_addr8 = "\220\266\216\233\377\177\000\000L=\215s\322\177\000", __u6_addr16 = {46736, 39822, 32767, 0, 15692, 29581, 32722, 0}, __u6_addr32 = {2609821328, 32767, 1938636108, 32722}}}, sin6_scope_id = 1971831024}, sas = {ss_family = 49168, __ss_padding = "\207u\322\177\000\000\220\266\216\233\377\177\000\000L=\215s\322\177\000\000\360\300\207u\322\177", '\000' <repeats 13 times>, "\b\000\000\000\000\060Z\264u\322\177\000\000\213\t\342\316\023V\000\000;\b\342\316\023V\000\000\020\313\320\000\000\000\000\000\020\000\000\000\000\000\000\000I\001\000\000\000\000\000\000\000\230g\240\210\347A\357\300\266\216\233\377\177\000\000\000\230g\240\210\347", <incomplete sequence \357>, __ss_align = 0}}, id = 0, send_flags = {f = 0, blst_imask = 0}, proto = 0 '\000', proto_pad0 = 0 '\000', proto_pad1 = 0} backup_user_from = 0x5613ccfb37f0 <def_list+16> backup_user_to = 0x5613ccfb37f8 <def_list+24> backup_domain_from = 0x5613ccfb3800 <def_list+32> backup_domain_to = 0x5613ccfb3808 <def_list+40> backup_uri_from = 0x5613ccfb37e0 <def_list> backup_uri_to = 0x5613ccfb37e8 <def_list+8> backup_xavps = 0x5613ccf56270 <_xavp_list_head> backup_xavus = 0x5613ccf56278 <_xavu_list_head> backup_xavis = 0x5613ccf56280 <_xavi_list_head> replies_locked = 1 branch_ret = 0 prev_branch = 1971830800 blst_503_timeout = 32722 hf = 0xb5c750 onsend_params = {req = 0x7fff9b8eb5e0, rpl = 0xef41e788a0679800, param = 0x30, code = 0, flags = 0, branch = 0, t_rbuf = 0x0, dst = 0x7fd27d972cb0 <__syslog>, send_buf = { s = 0x5613ccec69b3 "INFO", len = -1603823616}} ctx = {rec_lev = 0, run_flags = 2, last_retcode = -1, jmp_env = {{__jmpbuf = {0, -5133089567146157739, 0, 140542026919088, 94643042412979, 536870912, -5133089567232140971, -1505551737941960363}, __mask_was_saved = 0, __saved_mask = {__val = {140735803210560, 13683472, 7765887371, 140735803209568, 94643041089583, 0, 17240315422543681536, 0, 0, 0, 0, 94643042412979, 17240315422543681536, 140735803209872, 94643041372964, 2866715017336}}}}} bctx = 0x7fd27587c010 keng = 0x0 ret = 0 evname = {s = 0x7fd274d3696f "on_sl_reply", len = 11} __func__ = "reply_received" #4 0x00005613ccbba0d4 in do_forward_reply (msg=0x7fd2758bf0b0, mode=0) at core/forward.c:764 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 = "\000\000\000\000\000\000\000"}, 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}, sas = {ss_family = 0, __ss_padding = '\000' <repeats 117 times>, __ss_align = 0}}, id = 0, send_flags = {f = 0, blst_imask = 0}, proto = 0 '\000', proto_pad0 = 0 '\000', proto_pad1 = 0} new_len = 0 r = 2 ip = {af = 1, len = 6356993, u = {addrl = {140735803210560, 140541891965104}, addr32 = {2609822528, 32767, 1972105392, 32722}, addr16 = {47936, 39822, 32767, 0, 61616, 30091, 32722, 0}, addr = "@\273\216\233\377\177\000\000\260\360\213u\322\177\000"}} s = 0xef41e788a0679800 <error: Cannot access memory at address 0xef41e788a0679800> len = -1685145520 __func__ = "do_forward_reply" #5 0x00005613ccbbc23c in forward_reply (msg=0x7fd2758bf0b0) at core/forward.c:865 No locals. #6 0x00005613ccc5eea9 in receive_msg ( buf=0x5613cee206f0 "SIP/2.0 486 Busy Here\r\nTo: <sip:XXXXX@XXXXX;user=phone>;tag=h7g4Esbg_11002529899813\r\nFrom: <sip:XXXXX@XXXXX>;tag=as6964f29d\r\nCal"..., len=667, rcv_info=0x7fd253b7cad8) at core/receive.c:587 msg = 0x7fd2758bf0b0 ctx = {rec_lev = 0, run_flags = 0, last_retcode = 1, jmp_env = {{__jmpbuf = {0, -5133089566915471019, 0, 140542026919088, 94643042412979, 536870912, -5133089567001454251, -1505551737941960363}, __mask_was_saved = 0, __saved_mask = {__val = {94643073835016, 65535, 17240315422543681536, 18446744073709551536, 2, 0, 140542026919088, 94643042412979, 536870912, 140735803211024, 94643040635195, 140735803211696, 65535, 65536, 4095, 140735803211580}}}}} bctx = 0x0 ret = 1 tvb = {tv_sec = 0, tv_usec = 0} tve = {tv_sec = 0, tv_usec = 0} diff = 0 inb = {s = 0x5613cee206f0 "SIP/2.0 486 Busy Here\r\nTo: <sip:XXXXX@XXXXX;user=phone>;tag=h7g4Esbg_11002529899813\r\nFrom: <sip:XXXXX@XXXXX>;tag=as6964f29d\r\nCal"..., len = 667} netinfo = {data = {s = 0x5613cee206f0 "SIP/2.0 486 Busy Here\r\nTo: <sip:XXXXX@XXXXX;user=phone>;tag=h7g4Esbg_11002529899813\r\nFrom: <sip:XXXXX@XXXXX;tag=as6964f29d\r\nCal"..., len = 667}, rcv = 0x7fd253b7cad8, dst = 0x0} keng = 0x0 evp = {data = 0x7fff9b8eba90, obuf = {s = 0x0, len = 0}, rcv = 0x7fd253b7cad8, dst = 0x0, req = 0x0, rpl = 0x0, rplcode = 0, mode = 0} cidlockidx = 0 cidlockset = 0 errsipmsg = 0 exectime = 0 __func__ = "receive_msg" #7 0x00005613ccd1cf15 in receive_tcp_msg (tcpbuf=0x7fd253b7ce60 "SIP/2.0 486 Busy Here\r\nTo: <sip:XXXXX@XXXXX;user=phone>;tag=h7g4Esbg_11002529899813\r\nFrom: <sip:XXXXX@XXXXX>;tag=as6964f29d\r\nCal"..., len=667, rcv_info=0x7fd253b7cad8, con=0x7fd253b7cac0) at core/tcp_read.c:1424 buf = 0x5613cee206f0 "SIP/2.0 486 Busy Here\r\nTo: <sip:XXXXX@XXXXX;user=phone>;tag=h7g4Esbg_11002529899813\r\nFrom: <sip:XXXXX@XXXXX>;tag=as6964f29d\r\nCal"... bsize = 65535 blen = 65535 __func__ = "receive_tcp_msg" #8 0x00005613ccd1f554 in tcp_read_req (con=0x7fd253b7cac0, bytes_read=0x7fff9b8ebf34, read_flags=0x7fff9b8ebf3c) at core/tcp_read.c:1607 bytes = 667 total_bytes = 667 resp = 1 size = 0 req = 0x7fd253b7cbe8 dst = {send_sock = 0x7fff9b8ebec0, to = {s = {sa_family = 32062, sa_data = "\303\314\023V\000\000p\276\216\233\377\177\000"}, sin = {sin_family = 32062, sin_port = 52419, sin_addr = {s_addr = 22035}, sin_zero = "p\276\216\233\377\177\000"}, sin6 = {sin6_family = 32062, sin6_port = 52419, sin6_flowinfo = 22035, sin6_addr = {__in6_u = {__u6_addr8 = "p\276\216\233\377\177\000\000\030\000\000\000\000\000\000", __u6_addr16 = {48752, 39822, 32767, 0, 24, 0, 0, 0}, __u6_addr32 = {2609823344, 32767, 24, 0}}}, sin6_scope_id = 0}, sas = {ss_family = 32062, __ss_padding = "\303\314\023V\000\000p\276\216\233\377\177\000\000\030", '\000' <repeats 15 times>, "\225q\\\037P\000\000\000\070,\214u\322\177\000\000\000\244\374\314\023V\000\000\000\000\000\000\001 \000\000\070,\214u\322\177\000\000\001\000\000\000\000\000\000\000\300ʷS\322\177\000\000\200\276\216\233\377\177\000\000\070,\214u\322\177\000\000\200\277\216\233\377\177\000\000\b\000\000\000\000\000\000", __ss_align = 20}}, id = 1, send_flags = {f = 1, blst_imask = 0}, proto = 31 '\037', proto_pad0 = 0 '\000', proto_pad1 = 0} c = 49 '1' ret = 0 __func__ = "tcp_read_req" #9 0x00005613ccd23eb4 in handle_io (fm=0x7fd2758c2c38, events=1, idx=-1) at core/tcp_read.c:1857 ret = 0 n = 1404553920 read_flags = RD_CONN_SHORT_READ con = 0x7fd253b7cac0 s = 1404554328 resp = 1 t = 526152085 ee = 0x0 __func__ = "handle_io" #10 0x00005613ccd0dd1e in io_wait_loop_epoll (h=0x5613ccfca240 <io_w>, t=2, repeat=0) at core/io_wait.h:1070 n = 1 r = 0 fm = 0x7fd2758c2c38 revents = 1 __func__ = "io_wait_loop_epoll" #11 0x00005613ccd25981 in tcp_receive_loop (unix_sock=39) at core/tcp_read.c:1978 __func__ = "tcp_receive_loop" #12 0x00005613ccb8561b in tcp_init_children (woneinit=0x7fff9b8ec338) at core/tcp_main.c:5139 r = 2 i = 7 reader_fd_1 = 39 pid = 0 si_desc = "tcp receiver (generic)\000\000\205\220\274\314\023V\000\000\020Î\233\377\177\000\000\301\200\313\314\000\000\000\000AS\000\000\000\000\000\000۸\352\314\023V\000\000\246\000\216\233\377\177\000\000\034\352\340\314\023V\000\000\340\302\216\233\001\000\000\000\360\311\017Q\322\177\000\000\340\302\216\233\377\177\000\000\340\227:S\001\000\000\000\000Î\233\377\177\000\000\274\353\340\314\023V\000" si = 0x0 __func__ = "tcp_init_children" #13 0x00005613cca62bba in main_loop () at main.c:1857 i = 8 pid = 21313 si = 0x0 si_desc = "udp receiver child=7 sock=XXX.XXX.XXX.XXX:5060\000\000\000\003\000\000\000 \000\000\000\000\230g\240\210\347A\357\000\000\000\000\000\000\000\000\210P\347\314\023V\000\000\000\000\000\000\000\000\000\000\260,\227}\322\177\000\000\263i\354\314\023V\000\000\000\000\000 \000\000\000\000\260Ď\233\377\177\000\000\t\205\317\314\023V\000" nrprocs = 8 woneinit = 1 __func__ = "main_loop" #14 0x00005613cca6d4aa in main (argc=17, argv=0x7fff9b8ec9f8) at main.c:3053 cfg_stream = 0x5613cecb6290 c = -1 r = 0 tmp = 0x7fff9b8ecf3f "" tmp_len = 2109797928 port = 32722 proto = 2109962736 ahost = 0x0 aport = 0 options = 0x5613cce77ce0 ":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 = 3769828628 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 0 n_lst = 0x0 p = 0x0 st = {st_dev = 21, st_ino = 17087, st_nlink = 2, st_mode = 16832, st_uid = 109, st_gid = 115, __pad0 = 0, st_rdev = 0, st_size = 40, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1620845793, tv_nsec = 887985330}, st_mtim = {tv_sec = 1625090397, tv_nsec = 157181302}, st_ctim = {tv_sec = 1625090401, tv_nsec = 197141517}, __glibc_reserved = {0, 0, 0}} tbuf = "\000\000\000\000\000\000\000\000\b\000\000\000\000\000\000\000\060\207\303}\322\177\000\000\000\000\000\000\000\000\000\000\240q\237\233\377\177\000\000\364\212\301}\322\177\000\000\b\000\000\000\000\000\000\000\230r\237\233\377\177\000\000\060\207\303}\322\177\000\000\230ǎ\233\377\177\000\000\224ǎ\233\377\177", '\000' <repeats 18 times>, "\230r\237\233\377\177\000\000\250q\237\233\377\177\000\000'\376\237}\322\177\000\000&\260be\000\000\000\000\000Ɏ\233\377\177\000\000\300\212\225\001\000\000\000\000`Ȏ\233\377\177\000\000PȎ\233\377\177\000\000\230ǎ\233\377\177\000\000X\207\303}\322\177\000\000\001", '\000' <repeats 31 times>... option_index = 0 long_options = {{name = 0x5613cce79f3f "help", has_arg = 0, flag = 0x0, val = 104}, {name = 0x5613cce754e0 "version", has_arg = 0, flag = 0x0, val = 118}, {name = 0x5613cce79f44 "alias", has_arg = 1, flag = 0x0, val = 1024}, {name = 0x5613cce79f4a "subst", has_arg = 1, flag = 0x0, val = 1025}, {name = 0x5613cce79f50 "substdef", has_arg = 1, flag = 0x0, val = 1026}, {name = 0x5613cce79f59 "substdefs", has_arg = 1, flag = 0x0, val = 1027}, {name = 0x5613cce79f63 "server-id", has_arg = 1, flag = 0x0, val = 1028}, {name = 0x5613cce79f6d "loadmodule", has_arg = 1, flag = 0x0, val = 1029}, {name = 0x5613cce79f78 "modparam", has_arg = 1, flag = 0x0, val = 1030}, {name = 0x5613cce79f81 "log-engine", has_arg = 1, flag = 0x0, val = 1031}, {name = 0x5613cce79f8c "debug", has_arg = 1, flag = 0x0, val = 1032}, {name = 0x5613cce79f92 "cfg-print", has_arg = 0, flag = 0x0, val = 1033}, {name = 0x5613cce79f9c "atexit", has_arg = 1, flag = 0x0, val = 1034}, {name = 0x0, has_arg = 0, flag = 0x0, val = 0}} __func__ = "main"

3 9

UAC_AUTH with RTPEngine NAT
by Paul Smith 02 Jul '21

02 Jul '21

Hi, [Note I posted this yesterday from the wrong email address.] I am struggling to see why my SDP is not being set correctly on the INVITE to my supplier with Proxy-Authentication when I use uac_auth(). The initial INVITE to my supplier has correct SDP set by rtpengine_manage. Then supplier replies with a 407. My failure route correctly handles the Auth, and also calls NATMANAGE again... but this time the SDP is unchanged and the private IP and original media information from the original device is relayed to my supplier. kamailio.cfg isbased on the default config. Running kamailio 5.4.6 and using example from uac module for uac_auth. My failure route calls NATMANAGE. Is there anything special about uac_auth? Do I need some extra magic to apply the message body changes after I have run rtpengine_manage(). I can see that the NATMANAGEr test for nat_uac_test("8") is true, and rtpengine_manage() s being called. But the outgoing SDP is not changed. Thanks for any hints! Paul ==================== Extract of kamailio.cfg failure_route[TRUNKAUTH] { if (t_is_canceled()) { exit; } route(NATMANAGE); xlog("L_INFO","In failure route, just finshed NATMANAGE and now body is $mb"); if(t_check_status("401|407")) { # $avp(auser) = "test"; # $avp(apass) = "test"; # $avp(apass) = "36d0a02793542b4961e8348347236dbf"; if (uac_auth()) { t_relay(); } exit; } }

3 3

UAC_AUTH with RTPEngine NAT
by Paul Smith 01 Jul '21

01 Jul '21

Hi, I am struggling to see why my SDP is not being set correctly on the INVITE to my supplier with Proxy-Authentication when I use uac_auth(). The initial INVITE to my supplier has correct SDP set by rtpengine_manage. Then supplier replies with a 407. My failure route correctly handles the Auth, and also calls NATMANAGE again... but this time the SDP is unchanged and the private IP and original media information from the original device is relayed to my supplier. kamailio.cfg isbased on the default config. Running kamailio 5.4.6 and using example from uac module for uac_auth. My failure route calls NATMANAGE. Is there anything special about uac_auth? Do I need some extra magic to apply the message body changes after I have run rtpengine_manage(). ==================== Extract of kamailio.cfg failure_route[TRUNKAUTH] { if (t_is_canceled()) { exit; } route(NATMANAGE); xlog("L_INFO","In failure route, just finshed NATMANAGE and now body is $mb"); if(t_check_status("401|407")) { # $avp(auser) = "test"; # $avp(apass) = "test"; # $avp(apass) = "36d0a02793542b4961e8348347236dbf"; if (uac_auth()) { t_relay(); } exit; } }

1 0

Kamailio BSD license
by stevecarellccie＠yahoo.com 01 Jul '21

01 Jul '21

Hello, I am trying to use Kamailio in our application which would be deployed in certain environment in addition to a cloud infrastructure. As I understand it, parts of the Kamailio code are covered under the BSD license - are you able to share what those are? I am trying to determine if Kamailio can be used in a customer environment or should it be strictly restricted to cloud environments due to the GPL v2 licenses Thanks,Steve

2 1

install stirshaken module by apt at Debian 10
by Yuriy Nasida 30 Jun '21

30 Jun '21

Hi, I know that it's possible to compile manually but what about apt method to install stirshaken module? I am checking the list of modules using: apt search kamailio But... Nothing looks like stirshaken. Thus, only several modules available and for others we should compile manually ? Please advise Thanks

2 1

Websocket In-dialoge SIP routing failed post network loss due to aliases
by Shahid Hussain 30 Jun '21

30 Jun '21

Hi, Websocket module documentation has a code reference to use aliases for SIP routing. However, aliases will not work in the following setup and situation. 1. Kamailio is configured with active and standby node 2. Ping is implemented from webclient and kamailio responds with pong. 3. Two clients ClinetA and ClientB registered themselves to Kamailio. 4. After SIP negotiation (INVITE-200OK) each client learnt about below aliases. Alias of ClientA: alias=172.27.6.98~58336 Alias of ClientB: alias=172.27.6.98~58342 So normally if ClientB wants to send SIP message to ClientA, SIP URI from ClientB looks like below ACK sip:v9d0gtl6@q0lrdlj63pik.invalid;alias=172.27.6.98~58336~5;transport=ws SIP/2.0 4. Call is in a connected state. Following is the issue. i. Switchover (or network lost or reboot) at Kamailio happened ii. Due to ping pong both the clients detected network loss individually and re-registered themselves. iii. Aliases of both the clients got changed. New Alias of ClientA: alias=172.27.6.98~ 58346 New Alias of ClientB: alias=172.27.6.98~ 58348 iv. But ClientB doesn’t know that ClientA also re-registered and ClientA’s alias got changed and vice-versa v. Because of this ClientB still sends BYE with Initial alias BYE sip:v9d0gtl6@q0lrdlj63pik.invalid;alias=172.27.6.98~58336~5;transport=ws SIP/2.0 Would like to know what is the recommended solution for this problem using alias or is it a limitation of using alias? Thanks & Regards, Shahid

4 11

Re: [SR-Users] Guidance building a WebRTC to Asterisk Intermediate Proxy
by Peter Manley 29 Jun '21

29 Jun '21

Thanks Muhammad, That seems to have done the trick. I am now able to bridge WebRTC to UDP. Regards, Peter Manley M S shaheryarkh at gmail.com<mailto:sr-users%40lists.kamailio.org?Subject=Re%3A%20%5BSR-Users%5D%20Guidance%20building%20a%20WebRTC%20to%20Asterisk%20Intermediate%0A%20Proxy&In-Reply-To=%3CCAFZQphyZE_tGB9%3D5tFQBtXAv5twMh%3D9aCNFAvveGf0-L%3Dy_qwQ%40mail.gmail.com%3E> Sat Jun 26 03:57:27 CEST 2021 * Previous message (by thread): [SR-Users] Guidance building a WebRTC to Asterisk Intermediate Proxy<https://lists.kamailio.org/pipermail/sr-users/2021-June/112799.html> * Messages sorted by: [ date ]<https://lists.kamailio.org/pipermail/sr-users/2021-June/date.html#112800> [ thread ]<https://lists.kamailio.org/pipermail/sr-users/2021-June/thread.html#112800> [ subject ]<https://lists.kamailio.org/pipermail/sr-users/2021-June/subject.html#112800> [ author ]<https://lists.kamailio.org/pipermail/sr-users/2021-June/author.html#112800> ________________________________ The problem seems to that the kamailio is trying to route it over UDP port using WSS transport, which will never work. You are creating a transport bridge (UDP <-> WSS i.e. stateless transport <-> stateful transport) as well media bridge (RTP <-> SRTP), so it is going to be tricky. I strongly discourage it since things get messy for sequential requests. But you can try the following, Here are some PATH module parameters and functions, you will need to setup. 1. You will need to enable "use_received" parameter to ensure connection tracking. 2. It seems you may have enabled "received_format", so you make sure you do NAT detection and use "handle_ruri_alias" for initial requests. 3. You must also enabled "enable_r2", but with caution, since both ends (i.e. UAC and UAS) can be using same kamailio (proxy) socket for in/out. 4. Make sure to use "add_path_received" instead of "add_path". 5. If using OUTBOUND module then make sure it is loaded BEFORE the PATH module. Thank you. -- Muhammad Shahzad Shafi Burraq Technologies Tel: +49 176 99 83 10 85 On Sat, Jun 26, 2021 at 12:47 AM Peter Manley <peter.manley at kombea.com<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>> wrote: > Hello, > > > > I'm working on building an RTP Proxy which will allow both regular SIP to > SIP transactions and WebRTC to SIP transactions to an Asterisk Server. > > > > SIP UAC < ---UDP/SIP --- > Kamailio/RTPEngine Proxy < ---UDP/SIP----- > > Asterisk Server > > > > AND > > > > WebRTC UAC < ---WSS--- > Kamailio/RTPEngine Proxy < ---UDP/SIP----- > > Asterisk Server > > > > The Kamailio/RTPEngine Proxy is stateless (does not use the tm or > registerer modules), and uses the Path module to replace the Route header > with a Path header. > > > > It works grep for SIP/UDP to SIP/UDP transactions. > > > > HOWEVER... It only partially works for WSS to SIP/UDP transactions. The > REGISTER/401(Unauthorized), REGISTER/200(OK) transaction works well. > > > > When the Asterisk server sends a SIP Options message, I get the following > error: > > Jun 25 15:47:03 VRTPENGINE kamailio[4953]: INFO: <script>: => OPTIONS < > sip:l4umfumh at 192.0.2.97<https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>;transport=ws;alias=209.141.117.212~59751~6 -> > <null> (IP:172.16.0.48:sp) > > Jun 25 15:47:03 VRTPENGINE kamailio[4953]: WARNING: <core> > [core/msg_translator.c:2815]: via_builder(): TCP/TLS connection (id: 0) for > WebSocket could not be found > > Jun 25 15:47:03 VRTPENGINE kamailio[4953]: ERROR: <core> > [core/msg_translator.c:2003]: build_req_buf_from_sip_req(): could not > create Via header > > Jun 25 15:47:03 VRTPENGINE kamailio[4953]: ERROR: <core> > [core/forward.c:550]: forward_request(): building failed > > Jun 25 15:47:03 VRTPENGINE kamailio[4953]: WARNING: <core> > [core/receive.c:425]: receive_msg(): error while trying script > > > > It appears that the WebSocket corresponding to the WSS leg cannot be > located when the request is initiated from the Asterisk Server. > > > > Any thoughts on how I can get this to work in the other direction > (Asterisk to Kamailio)? I've been looking at the WebRTC to SIP Client and > Server (https://github.com/havfo/WEBRTC-to-SIP), but that doesn't quite > do what I want it to do (i.e. it appears to act as a registrar server and > doesn't forward REGISTER requests on to another registrar). > > > > > > Thanks and regards, > > > > *Peter H. Manley, Ph.D.* > > Chief Software Architect > > KomBea Corporation > > 3400 North Ashton Blvd, Suite 470 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__maps.google.com_-3Fq-3…> > > Lehi, Utah 84043 > <https://urldefense.proofpoint.com/v2/url?u=https-3A__maps.google.com_-3Fq-3…> > > www.kombea.com<http://www.kombea.com> > <https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kombea.com_&d=DwMF-…> > > > > Office:+1.801.610.5808 > > Mobile +1.801.243.7773 > > Peter H. Manley, Ph.D. Chief Software Architect KomBea Corporation 3400 North Ashton Blvd, Suite 470<https://urldefense.proofpoint.com/v2/url?u=https-3A__maps.google.com_-3Fq-3…> Lehi, Utah 84043<https://urldefense.proofpoint.com/v2/url?u=https-3A__maps.google.com_-3Fq-3…> www.kombea.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kombea.com_&d=DwMF-…> Office:+1.801.610.5808 Mobile +1.801.243.7773

1 0

Kamailio + RTPEngine - Destinations Behind NAT
by Edward Romanenco 29 Jun '21

29 Jun '21

Hi everyone, I'm using Kamailio (Ver 5.5.1, Public IP X.X.X.11, Private IP 172.18.0.20) + RTPEngine (Ver 9.4.1.1, Public IP X.X.X.7, Private IP 172.18.0.50) alongside Freeswitch (Private IP 172.18.0.40) in my backend and delivering calls to a mobile application (call flow is Freeswitch -> Kamailio + RTPEngine -> Applicaiton). While calls made to NATted destination generally works fine - from time to time, we've experiencing one-sided audio due to the rtpengine sending the media stream to the remote end's private IP instead of his public one. For instance, in the attached logs - media was sent towards 192.168.1.93 instead of 79.179.1.2, which is the expected destination. Problem appears almost randomly; I can make 20 fine calls in a row for the same destination until experiencing it, and I didn't find any difference as it comes to the SIP invite exchange between the two. Has anyone ever experienced the same behavior and can share some general instructions on how to troubleshoot it? Relevant Kamailio config section is attached. Invite Kamailio->Device INVITE sip:972587102881@79.179.1.2:56308;transport=TLS;ob SIP/2.0 Record-Route: <sip:X.X.X.11:443;transport=tls;r2=on;lr=on;ftag=cvcHy5UcS9pjj> Record-Route: <sip:172.18.0.20:5099;r2=on;lr=on;ftag=cvcHy5UcS9pjj> Via: SIP/2.0/TLS X.X.X.11:443;branch=z9hG4bK24bf.52b1dd68e26010ba103bd8d6fdb53cf4.0 Via: SIP/2.0/UDP 172.18.0.40;received=172.18.0.40;rport=5060;branch=z9hG4bKH234Q58HpHNKK Max-Forwards: 66 From: "972522149596" <sip:FreeSWITCH@172.18.0.20:5099>;tag=cvcHy5UcS9pjj To: <sip:972587102881@172.18.0.20:5099> Call-ID: be55bd1e-537d-123a-65a9-0242ac120028 CSeq: 37932220 INVITE Contact: <sip:gw+kam-in@172.18.0.40:5060;transport=udp;gw=kam-in;alias=172.18.0.40~5060~1> User-Agent: FreeSWITCH-mod_sofia/1.10.6-release+git~20210325T131609Z~1ff9d0a60e~64bit Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY Supported: timer, path, replaces Allow-Events: talk, hold, conference, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 567 X-SESSION-ID: 721533765 X-INCOMING: PSTN X-from-freeswitch: +972522149596 X-FS-Support: update_display,send_info Remote-Party-ID: "972522149596" <sip:972522149596@172.18.0.20:5099>;party=calling;screen=yes;privacy=off v=0 o=FreeSWITCH 1624937621 1624937622 IN IP4 X.X.X.7 s=FreeSWITCH c=IN IP4 X.X.X.7 t=0 0 m=audio 30018 RTP/AVP 102 101 a=rtpmap:102 opus/48000/2 a=fmtp:102 useinbandfec=1; maxaveragebitrate=30000; maxplaybackrate=48000; ptime=20; minptime=10; maxptime=40 a=rtpmap:101 telephone-event/48000 a=fmtp:101 0-16 a=sendrecv a=rtcp:30019 a=ptime:20 a=ice-ufrag:bKPZt0dW a=ice-pwd:H4qyL7mPUOvoiAjosiLasXAdzj a=candidate:41sXGEsTafxHi8ms 1 UDP 2130706431 X.X.X.7 30018 typ host a=candidate:41sXGEsTafxHi8ms 2 UDP 2130706430 X.X.X.7 30019 typ host Response Device->Kamailio SIP/2.0 200 OK Via: SIP/2.0/TLS X.X.X.11:443;received=X.X.X.11;branch=z9hG4bK24bf.52b1dd68e26010ba103bd8d6fdb53cf4.0 Via: SIP/2.0/UDP 172.18.0.40;rport=5060;received=172.18.0.40;branch=z9hG4bKH234Q58HpHNKK Record-Route: <sip:X.X.X.11:443;transport=tls;lr;r2=on;ftag=cvcHy5UcS9pjj> Record-Route: <sip:172.18.0.20:5099;lr;r2=on;ftag=cvcHy5UcS9pjj> Call-ID: be55bd1e-537d-123a-65a9-0242ac120028 From: "972522149596" <sip:FreeSWITCH@172.18.0.20>;tag=cvcHy5UcS9pjj To: <sip:972587102881@172.18.0.20>;tag=5f75877e-58c2-44f3-a5b3-43f8786c42a1 CSeq: 37932220 INVITE Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Contact: <sip:972587102881@79.179.1.2:56308;transport=TLS;ob> Supported: replaces, 100rel, timer, norefersub Content-Type: application/sdp Content-Length: 348 v=0 o=- 3833960833 3833960834 IN IP4 192.168.1.93 s=pjmedia b=AS:117 t=0 0 a=X-nat:0 m=audio 4002 RTP/AVP 96 120 c=IN IP4 192.168.1.93 b=TIAS:96000 a=rtcp:4003 IN IP4 192.168.1.93 a=sendrecv a=rtpmap:96 opus/48000/2 a=fmtp:96 useinbandfec=1 a=rtpmap:120 telephone-event/48000 a=fmtp:120 0-16 a=ssrc:816694098 cname:72cdb5f53fc2e8fb Kamailio NAT Detect/Manage Routes # Caller NAT detection route[NATDETECT] { #!ifdef WITH_NAT xinfo("NATDETECT: Adding the rport parameter to the first Via header of the received message\n"); force_rport(); xinfo("NATDETECT: Trying to guess if client's request originated behind a nat. Testing 19.\n"); if (nat_uac_test("19")) { if (is_method("REGISTER")) { xinfo("NATDETECT: REGISTER request. Creating a URI consisting of the source IP, port, and protocol and storing the URI in an Attribute-Value-Pair.\n"); fix_nated_register(); } else { if(is_first_hop()) { xinfo("NATDETECT: Adding an ;alias=ip~port~transport parameter to the contact URI containing the received ip, port, and transport protocol.\n"); set_contact_alias(); } } xinfo("NATDETECT: Setting flag FLT_NATS.\n"); setflag(FLT_NATS); } else { xinfo("NATDETECT: Didn't detect natted request by any of the given heuristics\n"); } #!endif return; } # RTPProxy control and signaling updates for NAT traversal route[NATMANAGE] { #!ifdef WITH_NAT if (is_request()) { if(has_totag()) { if(check_route_param("nat=yes")) { xinfo("NATMANAGE: This is a request with to-tag that has 'nat=yes', setting branch flag FLB_NATB.\n"); setbflag(FLB_NATB); } } } if (!(isflagset(FLT_NATS) || isbflagset(FLB_NATB))) { xinfo("NATMANAGE: No NAT flag detected for this request\n"); return; } else { xinfo("NATMANAGE: NAT flag detected for this request\n"); } if(!is_present_hf("x-purpose")) { xinfo("NATMANAGE: x-purpose header does not appear in this request, SDP is searched for occurrence of RFC1918 or RFC6598 addresses.\n"); if(nat_uac_test("8")) { xinfo("NATMANAGE: Found occurrence of RFC1918 or RFC6598 addresses. Checking if there is a match of source address or uri with an address in the group of the dispatcher-list.\n"); if(ds_is_from_list()) { xinfo("NATMANAGE: There is a match with an address in the group of the dispatcher-list.\n"); rtpengine_manage("ICE=force replace-session-connection replace-origin direction=priv direction=pub"); } else { xinfo("NATMANAGE: No match with an address in the group of the dispatcher-list.\n"); rtpengine_manage("ICE=force replace-session-connection replace-origin direction=pub direction=priv"); } } else { xinfo("NATMANAGE: No occurrence of RFC1918 or RFC6598 addresses. Checking if there is a match of source address or uri with an address in the group of the dispatcher-list.\n"); if(ds_is_from_list()) { xinfo("NATMANAGE: There is a match with an address in the group of the dispatcher-list.\n"); rtpengine_manage("ICE=force replace-session-connection replace-origin trust-address direction=priv direction=pub"); } else { xinfo("NATMANAGE: No match with an address in the group of the dispatcher-list.\n"); rtpengine_manage("ICE=force replace-session-connection replace-origin trust-address direction=pub direction=priv"); } } } if (is_request()) { if (!has_totag()) { if(t_is_branch_route()) { xinfo("NATMANAGE: This is a request without to-tag and top-executed route block is branch_route, adding record route param ;nat=yes.\n"); add_rr_param(";nat=yes"); } } } if (is_reply()) { if(isbflagset(FLB_NATB)) { if(is_first_hop()) { xinfo("NATMANAGE: Adding an ;alias=ip~port~transport parameter to the contact URI containing the received ip, port, and transport protocol.\n"); set_contact_alias(); } } } #!endif return; } RTPEngine Logs 2021-06-29T13:07:05.440658779Z [1624972025.439547] INFO: [be55bd1e-537d-123a-65a9-0242ac120028]: [control] Received command 'offer' from 172.18.0.20:53880 2021-06-29T13:07:05.440690853Z [1624972025.439641] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028]: [control] Dump for 'offer' from 172.18.0.20:53880: { "supports": [ "load limit" ], "sdp": "v=0 2021-06-29T13:07:05.440695330Z o=FreeSWITCH 1624937621 1624937622 IN IP4 172.18.0.40 2021-06-29T13:07:05.440698353Z s=FreeSWITCH 2021-06-29T13:07:05.440700926Z c=IN IP4 172.18.0.40 2021-06-29T13:07:05.440703539Z t=0 0 2021-06-29T13:07:05.440706179Z m=audio 34404 RTP/AVP 102 101 2021-06-29T13:07:05.440708722Z a=rtpmap:102 opus/48000/2 2021-06-29T13:07:05.440711294Z a=fmtp:102 useinbandfec=1; maxaveragebitrate=30000; maxplaybackrate=48000; ptime=20; minptime=10; maxptime=40 2021-06-29T13:07:05.440714053Z a=rtpmap:101 telephone-event/48000 2021-06-29T13:07:05.440716746Z a=fmtp:101 0-16 2021-06-29T13:07:05.440719258Z a=ptime:20 2021-06-29T13:07:05.440721823Z ", "ICE": "force", "direction": [ "priv", "pub" ], "replace": [ "session-connection", "origin" ], "call-id": "be55bd1e-537d-123a-65a9-0242ac120028", "received-from": [ "IP4", "172.18.0.40" ], "from-tag": "cvcHy5UcS9pjj", "command": "offer" } 2021-06-29T13:07:05.441069790Z [1624972025.439694] NOTICE: [be55bd1e-537d-123a-65a9-0242ac120028]: [core] Creating new call 2021-06-29T13:07:05.441088698Z [1624972025.439809] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028]: [codec] Default sink codec is opus/48000/2 2021-06-29T13:07:05.441091829Z [1624972025.439815] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028]: [codec] Output DTMF payload type is 101 2021-06-29T13:07:05.441094966Z [1624972025.439821] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028]: [codec] Creating codec handler for opus/48000/2 2021-06-29T13:07:05.441097777Z [1624972025.439828] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028]: [codec] Sink supports codec opus/48000/2 2021-06-29T13:07:05.441100540Z [1624972025.439833] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028]: [codec] Using passthrough handler for opus/48000/2 2021-06-29T13:07:05.441103390Z [1624972025.439839] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028]: [codec] Creating codec handler for telephone-event/48000 2021-06-29T13:07:05.441106153Z [1624972025.439844] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028]: [codec] Sink supports codec telephone-event/48000 2021-06-29T13:07:05.441108913Z [1624972025.439849] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028]: [codec] Using passthrough handler for telephone-event/48000 2021-06-29T13:07:05.441111679Z [1624972025.440116] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028]: [core] set FILLED flag for stream 172.18.0.40:34404 2021-06-29T13:07:05.441124990Z [1624972025.440124] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028]: [core] set FILLED flag for stream 172.18.0.40:34405 2021-06-29T13:07:05.441663481Z [1624972025.441074] INFO: [be55bd1e-537d-123a-65a9-0242ac120028]: [control] Replying to 'offer' from 172.18.0.20:53880 (elapsed time 0.001414 sec) 2021-06-29T13:07:05.441694377Z [1624972025.441103] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028]: [control] Response dump for 'offer' to 172.18.0.20:53880: { "sdp": "v=0 2021-06-29T13:07:05.441701068Z o=FreeSWITCH 1624937621 1624937622 IN IP4 X.X.X.7 2021-06-29T13:07:05.441706421Z s=FreeSWITCH 2021-06-29T13:07:05.441711414Z c=IN IP4 X.X.X.7 2021-06-29T13:07:05.441716274Z t=0 0 2021-06-29T13:07:05.441721177Z m=audio 30018 RTP/AVP 102 101 2021-06-29T13:07:05.441726204Z a=rtpmap:102 opus/48000/2 2021-06-29T13:07:05.441731246Z a=fmtp:102 useinbandfec=1; maxaveragebitrate=30000; maxplaybackrate=48000; ptime=20; minptime=10; maxptime=40 2021-06-29T13:07:05.441736873Z a=rtpmap:101 telephone-event/48000 2021-06-29T13:07:05.441742017Z a=fmtp:101 0-16 2021-06-29T13:07:05.441827012Z a=sendrecv 2021-06-29T13:07:05.441844744Z a=rtcp:30019 2021-06-29T13:07:05.441848881Z a=ptime:20 2021-06-29T13:07:05.441852444Z a=ice-ufrag:bKPZt0dW 2021-06-29T13:07:05.441856394Z a=ice-pwd:H4qyL7mPUOvoiAjosiLasXAdzj 2021-06-29T13:07:05.441860642Z a=candidate:41sXGEsTafxHi8ms 1 UDP 2130706431 X.X.X.7 30018 typ host 2021-06-29T13:07:05.441864955Z a=candidate:41sXGEsTafxHi8ms 2 UDP 2130706430 X.X.X.7 30019 typ host 2021-06-29T13:07:05.441868967Z ", "result": "ok" } 2021-06-29T13:07:07.001082810Z [1624972027.000176] DEBUG: [core] timer run time = 0.000029 sec 2021-06-29T13:07:07.817899628Z [1624972027.816949] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028 port 30019]: [core] >>> in_ssrc changed for: :0 new: 30adc352 2021-06-29T13:07:07.817932021Z [1624972027.816987] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028 port 30019]: [core] >>> out_ssrc changed for 172.18.0.40:34405 new: 30adc352 2021-06-29T13:07:07.817936388Z [1624972027.816998] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028 port 30019]: [rtcp] Calling handler for RTCP packet type 201 2021-06-29T13:07:07.817939853Z [1624972027.817025] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028 port 30019]: [core] RR from 30adc352 about 0: FL 0 TL 0 HSR 0 J 0 LSR 0 DLSR 0 2021-06-29T13:07:07.817942689Z [1624972027.817030] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028 port 30019]: [core] No payload type known for RTCP RR, discarding 2021-06-29T13:07:07.817945696Z [1624972027.817036] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028 port 30019]: [rtcp] Calling handler for RTCP packet type 202 2021-06-29T13:07:07.817948500Z [1624972027.817124] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028 port 30019]: [core] Forward to sink endpoint: 172.18.0.40:34405 2021-06-29T13:07:07.818762433Z [1624972027.817995] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028 port 30019]: [rtcp] Calling handler for RTCP packet type 201 2021-06-29T13:07:07.818790347Z [1624972027.818031] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028 port 30019]: [core] RR from 30adc352 about 0: FL 0 TL 0 HSR 0 J 0 LSR 0 DLSR 0 2021-06-29T13:07:07.818794422Z [1624972027.818035] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028 port 30019]: [core] No payload type known for RTCP RR, discarding 2021-06-29T13:07:07.818797834Z [1624972027.818042] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028 port 30019]: [rtcp] Calling handler for RTCP packet type 202 2021-06-29T13:07:07.818801095Z [1624972027.818122] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028 port 30019]: [core] Forward to sink endpoint: 172.18.0.40:34405 2021-06-29T13:07:07.847992398Z [1624972027.846284] INFO: [be55bd1e-537d-123a-65a9-0242ac120028]: [control] Received command 'answer' from 172.18.0.20:47817 2021-06-29T13:07:07.848048472Z [1624972027.846325] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028]: [control] Dump for 'answer' from 172.18.0.20:47817: { "supports": [ "load limit" ], "sdp": "v=0 2021-06-29T13:07:07.848058346Z o=- 3833960833 3833960834 IN IP4 192.168.1.93 2021-06-29T13:07:07.848063378Z s=pjmedia 2021-06-29T13:07:07.848067785Z b=AS:117 2021-06-29T13:07:07.848071736Z t=0 0 2021-06-29T13:07:07.848075782Z a=X-nat:0 2021-06-29T13:07:07.848079588Z m=audio 4002 RTP/AVP 96 120 2021-06-29T13:07:07.848084210Z c=IN IP4 192.168.1.93 2021-06-29T13:07:07.848089110Z b=TIAS:96000 2021-06-29T13:07:07.848092756Z a=rtcp:4003 IN IP4 192.168.1.93 2021-06-29T13:07:07.848096578Z a=sendrecv 2021-06-29T13:07:07.848100173Z a=rtpmap:96 opus/48000/2 2021-06-29T13:07:07.848104153Z a=fmtp:96 useinbandfec=1 2021-06-29T13:07:07.848108660Z a=rtpmap:120 telephone-event/48000 2021-06-29T13:07:07.848112776Z a=fmtp:120 0-16 2021-06-29T13:07:07.848116856Z a=ssrc:816694098 cname:72cdb5f53fc2e8fb 2021-06-29T13:07:07.848120776Z ", "ICE": "force", "direction": [ "pub", "priv" ], "replace": [ "session-connection", "origin" ], "call-id": "be55bd1e-537d-123a-65a9-0242ac120028", "received-from": [ "IP4", "79.179.1.2" ], "from-tag": "cvcHy5UcS9pjj", "to-tag": "5f75877e-58c2-44f3-a5b3-43f8786c42a1", "command": "answer" } 2021-06-29T13:07:07.848128079Z [1624972027.846411] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028]: [codec] Default sink codec is opus/48000/2 2021-06-29T13:07:07.848132255Z [1624972027.846418] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028]: [codec] Output DTMF payload type is 120 2021-06-29T13:07:07.848136164Z [1624972027.846424] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028]: [codec] Creating codec handler for opus/48000/2 2021-06-29T13:07:07.848139819Z [1624972027.846429] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028]: [codec] Sink supports codec opus/48000/2 2021-06-29T13:07:07.848143930Z [1624972027.846434] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028]: [codec] Using passthrough handler for opus/48000/2 2021-06-29T13:07:07.848169208Z [1624972027.846441] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028]: [codec] Creating codec handler for telephone-event/48000 2021-06-29T13:07:07.848174300Z [1624972027.846445] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028]: [codec] Sink supports codec telephone-event/48000 2021-06-29T13:07:07.848178752Z [1624972027.846449] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028]: [codec] Using passthrough handler for telephone-event/48000 2021-06-29T13:07:07.848183460Z [1624972027.846586] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028]: [core] set FILLED flag for stream 192.168.1.93:4002 2021-06-29T13:07:07.848188805Z [1624972027.846593] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028]: [core] set FILLED flag for stream 192.168.1.93:4003 2021-06-29T13:07:07.848193111Z [1624972027.846597] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028]: [ice] Shutting down ICE agent (nothing to do) 2021-06-29T13:07:07.848197042Z [1624972027.847228] INFO: [be55bd1e-537d-123a-65a9-0242ac120028]: [control] Replying to 'answer' from 172.18.0.20:47817 (elapsed time 0.000890 sec) 2021-06-29T13:07:07.848201623Z [1624972027.847243] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028]: [control] Response dump for 'answer' to 172.18.0.20:47817: { "sdp": "v=0 2021-06-29T13:07:07.848205754Z o=- 3833960833 3833960834 IN IP4 172.18.0.50 2021-06-29T13:07:07.848209696Z s=pjmedia 2021-06-29T13:07:07.848213446Z b=AS:117 2021-06-29T13:07:07.848217361Z t=0 0 2021-06-29T13:07:07.848220816Z a=X-nat:0 2021-06-29T13:07:07.848224363Z m=audio 30018 RTP/AVP 96 120 2021-06-29T13:07:07.848228432Z c=IN IP4 172.18.0.50 2021-06-29T13:07:07.848232603Z b=TIAS:96000 2021-06-29T13:07:07.848235992Z a=ssrc:816694098 cname:72cdb5f53fc2e8fb 2021-06-29T13:07:07.848240381Z a=rtpmap:96 opus/48000/2 2021-06-29T13:07:07.848243923Z a=fmtp:96 useinbandfec=1 2021-06-29T13:07:07.848247725Z a=rtpmap:120 telephone-event/48000 2021-06-29T13:07:07.848386453Z a=fmtp:120 0-16 2021-06-29T13:07:07.848395759Z a=sendrecv 2021-06-29T13:07:07.848399822Z a=rtcp:30019 2021-06-29T13:07:07.848403748Z a=ptime:20 2021-06-29T13:07:07.848407203Z a=ice-ufrag:4Q9H38CE 2021-06-29T13:07:07.848410827Z a=ice-pwd:OR8EfUn5dCLbhZqyiwsTUOyUdW 2021-06-29T13:07:07.848414680Z a=candidate:f75EKiqnFiVfQdoZ 1 UDP 2130706431 172.18.0.50 30018 typ host 2021-06-29T13:07:07.848419247Z a=candidate:f75EKiqnFiVfQdoZ 2 UDP 2130706430 172.18.0.50 30019 typ host 2021-06-29T13:07:07.848432370Z ", "result": "ok" } 2021-06-29T13:07:07.872251466Z [1624972027.871342] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028 port 30018]: [ice] Created candidate pair f75EKiqnFiVfQdoZ:33d9f4832b3cc9a0:1 between 172.18.0.50 and 172.18.0.40:34404, type prflx 2021-06-29T13:07:07.872276197Z [1624972027.871381] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028 port 30018]: [ice] Triggering check for f75EKiqnFiVfQdoZ:33d9f4832b3cc9a0:1 2021-06-29T13:07:07.872286600Z [1624972027.871396] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028 port 30018]: [ice] ICE pair f75EKiqnFiVfQdoZ:33d9f4832b3cc9a0:1 has been nominated by peer 2021-06-29T13:07:07.872289762Z [1624972027.871401] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028 port 30018]: [ice] ICE not completed yet and no usable candidates 2021-06-29T13:07:07.872292668Z [1624972027.871407] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028 port 30018]: [core] Successful STUN binding request from 172.18.0.40:34404 2021-06-29T13:07:07.919668940Z [1624972027.918862] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028 port 30018]: [core] >>> in_ssrc changed for: 172.18.0.40:34404 new: 70f328c1 2021-06-29T13:07:07.919698433Z [1624972027.918897] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028 port 30018]: [core] >>> out_ssrc changed for 192.168.1.93:4002 new: 70f328c1 2021-06-29T13:07:07.919703321Z [1624972027.918911] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028 port 30018]: [core] Forward to sink endpoint: 192.168.1.93:4002 (RTP seq 64423 TS 2880) 2021-06-29T13:07:07.939554198Z [1624972027.938733] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028 port 30018]: [core] Forward to sink endpoint: 192.168.1.93:4002 (RTP seq 64424 TS 3840) 2021-06-29T13:07:07.959769679Z [1624972027.959017] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028 port 30018]: [core] Forward to sink endpoint: 192.168.1.93:4002 (RTP seq 64425 TS 4800) 2021-06-29T13:07:07.979861917Z [1624972027.979067] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028 port 30018]: [core] Forward to sink endpoint: 192.168.1.93:4002 (RTP seq 64426 TS 5760) 2021-06-29T13:07:07.999566603Z [1624972027.998777] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028 port 30018]: [core] Forward to sink endpoint: 192.168.1.93:4002 (RTP seq 64427 TS 6720) 2021-06-29T13:07:08.019668998Z [1624972028.018802] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028 port 30018]: [core] Forward to sink endpoint: 192.168.1.93:4002 (RTP seq 64428 TS 7680) 2021-06-29T13:07:08.040856248Z [1624972028.039663] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028 port 30018]: [core] Forward to sink endpoint: 192.168.1.93:4002 (RTP seq 64429 TS 8640) 2021-06-29T13:07:08.061133612Z [1624972028.059847] DEBUG: [be55bd1e-537d-123a-65a9-0242ac120028 port 30018]: [core] Forward to sink endpoint: 192.168.1.93:4002 (RTP seq 64430 TS 9600) Edward

1 1

Guidance building a WebRTC to Asterisk Intermediate Proxy
by Peter Manley 26 Jun '21

26 Jun '21

Hello, I'm working on building an RTP Proxy which will allow both regular SIP to SIP transactions and WebRTC to SIP transactions to an Asterisk Server. SIP UAC < ---UDP/SIP --- > Kamailio/RTPEngine Proxy < ---UDP/SIP----- > Asterisk Server AND WebRTC UAC < ---WSS--- > Kamailio/RTPEngine Proxy < ---UDP/SIP----- > Asterisk Server The Kamailio/RTPEngine Proxy is stateless (does not use the tm or registerer modules), and uses the Path module to replace the Route header with a Path header. It works grep for SIP/UDP to SIP/UDP transactions. HOWEVER... It only partially works for WSS to SIP/UDP transactions. The REGISTER/401(Unauthorized), REGISTER/200(OK) transaction works well. When the Asterisk server sends a SIP Options message, I get the following error: Jun 25 15:47:03 VRTPENGINE kamailio[4953]: INFO: <script>: => OPTIONS < sip:l4umfumh@192.0.2.97;transport=ws;alias=209.141.117.212~59751~6 -> <null> (IP:172.16.0.48:sp) Jun 25 15:47:03 VRTPENGINE kamailio[4953]: WARNING: <core> [core/msg_translator.c:2815]: via_builder(): TCP/TLS connection (id: 0) for WebSocket could not be found Jun 25 15:47:03 VRTPENGINE kamailio[4953]: ERROR: <core> [core/msg_translator.c:2003]: build_req_buf_from_sip_req(): could not create Via header Jun 25 15:47:03 VRTPENGINE kamailio[4953]: ERROR: <core> [core/forward.c:550]: forward_request(): building failed Jun 25 15:47:03 VRTPENGINE kamailio[4953]: WARNING: <core> [core/receive.c:425]: receive_msg(): error while trying script It appears that the WebSocket corresponding to the WSS leg cannot be located when the request is initiated from the Asterisk Server. Any thoughts on how I can get this to work in the other direction (Asterisk to Kamailio)? I've been looking at the WebRTC to SIP Client and Server (https://github.com/havfo/WEBRTC-to-SIP), but that doesn't quite do what I want it to do (i.e. it appears to act as a registrar server and doesn't forward REGISTER requests on to another registrar). Thanks and regards, Peter H. Manley, Ph.D. Chief Software Architect KomBea Corporation 3400 North Ashton Blvd, Suite 470<https://urldefense.proofpoint.com/v2/url?u=https-3A__maps.google.com_-3Fq-3…> Lehi, Utah 84043<https://urldefense.proofpoint.com/v2/url?u=https-3A__maps.google.com_-3Fq-3…> www.kombea.com<https://urldefense.proofpoint.com/v2/url?u=http-3A__www.kombea.com_&d=DwMF-…> Office:+1.801.610.5808 Mobile +1.801.243.7773

2 1

using both ldap and local authenticate
by Thành Trần Duy 25 Jun '21

25 Jun '21

Hi all, I am using kamailio as PBX with some softphones and hard phones. I want user on a pc to login with LDAP and users using a hard phone login normally (username/password). Can I use 2 types of authentication at the same time? Many thanks, Tran Duy Thanh

2 2

Jump to page:

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