- sr-users - kamailio.org

"signal 15 received" and ... on Kamailio 5.1.6
by AL RSM 15 Nov '18

15 Nov '18

Hi, I just installed Kamailio 5.1.6 on Ubuntu 18.04. Starting Kamailio with the default config will give us the following in the log. Is this normal? Is there a way to fix this issue? Thanks, AL Nov 15 14:01:59 lab-proxy03 kamailio[13544]: * Stopping Kamailio SIP Server: kamailio Nov 15 14:01:59 lab-proxy03 /usr/local/sbin/kamailio[5182]: NOTICE: <core> [main.c:692]: handle_sigs(): Thank you for flying kamailio!!! Nov 15 14:01:59 lab-proxy03 /usr/local/sbin/kamailio[5213]: INFO: <core> [main.c:819]: sig_usr(): signal 15 received Nov 15 14:01:59 lab-proxy03 /usr/local/sbin/kamailio[5212]: INFO: <core> [main.c:819]: sig_usr(): signal 15 received .... Nov 15 14:01:59 lab-proxy03 /usr/local/sbin/kamailio[5182]: INFO: <core> [core/sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized Nov 15 14:02:00 lab-proxy03 kamailio[13544]: ...done. Nov 15 14:02:00 lab-proxy03 kamailio[13556]: * Starting Kamailio SIP Server: kamailio Nov 15 14:02:00 lab-proxy03 kamailio: INFO: <core> [core/sctp_core.c:74]: sctp_core_check_support(): SCTP API not enabled - if you want to use it, load sctp module Nov 15 14:02:00 lab-proxy03 kamailio: INFO: <core> [core/tcp_main.c:4721]: init_tcp(): using epoll_lt as the io watch method (auto detected) .... Nov 15 14:02:00 lab-proxy03 /usr/local/sbin/kamailio[13596]: INFO: rr [../outbound/api.h:52]: ob_load_api(): unable to import bind_ob - maybe module is not loaded Nov 15 14:02:00 lab-proxy03 /usr/local/sbin/kamailio[13596]: INFO: rr [rr_mod.c:175]: mod_init(): outbound module not available Nov 15 14:02:00 lab-proxy03 /usr/local/sbin/kamailio[13596]: INFO: <core> [core/udp_server.c:153]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 Nov 15 14:02:00 lab-proxy03 /usr/local/sbin/kamailio[13596]: INFO: <core> [core/udp_server.c:205]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 Nov 15 14:02:00 lab-proxy03 /usr/local/sbin/kamailio[13596]: INFO: <core> [core/udp_server.c:153]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 Nov 15 14:02:00 lab-proxy03 /usr/local/sbin/kamailio[13596]: INFO: <core> [core/udp_server.c:205]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 Nov 15 14:02:00 lab-proxy03 /usr/local/sbin/kamailio[13618]: INFO: jsonrpcs [jsonrpcs_sock.c:443]: jsonrpc_dgram_process(): a new child 0/13618 Nov 15 14:02:00 lab-proxy03 /usr/local/sbin/kamailio[13619]: INFO: ctl [io_listener.c:214]: io_listen_loop(): io_listen_loop: using epoll_lt io watch method (config) Nov 15 14:02:00 lab-proxy03 kamailio[13556]: ...done.

1 0

REFER packet - Kamailio gives request_uri instead request-uri -
by YAS0 CANER 15 Nov '18

15 Nov '18

Hello, i test on refer packet on Kamailio 5.3-dev . it gives route_uri (@route_uri) instead of request-uri ($ru). Could you give me help about it please. Thanks. Packet 2018/11/15 10:51:20.522512 192.168.1.109:5080 -> 192.168.1.120:5060 REFER sip:100@192.168.1.120 SIP/2.0 CSeq: 1 REFER From: <sip:105@192.168.1.120;transport=UDP>;tag=10215SIPpTag001 To: <sip:100@192.168.1.120;transport=UDP>;tag=7e3fb504 Call-ID: 1-10215(a)192.168.1.109 Max-Forwards: 70 Route: <sip:192.168.1.120;lr> Via: SIP/2.0/UDP 192.168.1.136:5080;branch=z9hG4bK-10215-1-7 Contact: <sip:105@192.168.1.136:5080> Refer-To: <sip:103@192.168.1.120> Referred-By: <sip:105@192.168.1.120;transport=UDP> Content-Length: 0 1(48532) WARNING: {1 1 REFER 1-10215(a)192.168.1.109} <script>: REFER in WITHINDLG [$ru sip:192.168.1.120;lr ] 1(48532) WARNING: {1 1 REFER 1-10215(a)192.168.1.109} <script>: REFER MYROUTE [ru sip:192.168.1.120;lr ] [route_uri sip:192.168.1.120;lr ] [ rU <null> ] Scenairo SIPP UAC -> Kamailio - > UAC 2 After call answered , SIPP send REFER request as above.

1 2

mod siptrace - option ping from nathelper do not get duplicated
by Roman Dissauer 14 Nov '18

14 Nov '18

Hi, we are using kamailio 5.1 with siptrace module in trace_mode on. Everything works perfect except that option pings from nathelper module do not get duplicated. Is there a reason for that? Thanks, Roman

2 1

Core dump on diameter CCR request
by Venkatesh Macha 14 Nov '18

14 Nov '18

Hi all, I am trying to implement Diameter charging with Kamailio. I am following below tutorial https://www.kamailio.org/events/2016-KamailioWorld/Day2/15-Carsten.Bock-Dia… But whenever I try to do the Ro_CCR from the INVITE block, Kamailio is crashing and generating the core dump. I am new to diameter. I might be doing something wrong here. please someone help me here. Please find the *diameter.xml* and *Diameter_core_dump_full_debug.txt* file. diameter.xml <http://sip-router.1086192.n5.nabble.com/file/t6374/diameter.xml> Diameter_core_dump_full_Debug.txt <http://sip-router.1086192.n5.nabble.com/file/t6374/Diameter_core_dump_full_…> Here is my kamailio.cfg : loadmodule "cdp" loadmodule "cdp_avp" loadmodule "ims_charging" loadmodule "ims_dialog" modparam("cdp","config_file","/etc/kamailio/diameter.xml") modparam("cdp", "debug_heavy", 1) # ----- ims_diameter_ro params ----- #modparam("ims_charging", "single_ro_session_per_dialog", 1) modparam("ims_charging", "origin_host", "10.195.0.38"); modparam("ims_charging", "origin_realm", "10.195.0.38"); modparam("ims_charging", "destination_realm", "mydomain.com"); modparam("ims_charging","interim_update_credits",30); modparam("ims_charging","timer_buffer",5); # -- ims_dialog params -- modparam("ims_dialog", "dlg_flag", 8) While starting the kamailio, i am getting following errors: Nov 11 11:40:03 ip-10-195-0-38 /usr/local/sbin/kamailio[25653]: ERROR: cdp [peerstatemachine.c:675]: add_peer_application(): Too many applications for this peer (max 0), not adding Application 4:0. Before crashing kamailio showing following error: Nov 11 11:39:49 ip-10-195-0-38 /usr/local/sbin/kamailio[25571]: INFO: {1 18325 INVITE Nf6-dl2WeXF.LJhXotiRsuMhijsNx45o} <script>: Entered into INVITE Block Nov 11 11:39:49 ip-10-195-0-38 /usr/local/sbin/kamailio[25571]: ERROR: {1 18325 INVITE Nf6-dl2WeXF.LJhXotiRsuMhijsNx45o} ims_dialog [dlg_handlers.c:264]: dlg_get_iuid_shm_clone(): ***** Requesting 8 Nov 11 11:39:49 ip-10-195-0-38 /usr/local/sbin/kamailio[25571]: CRITICAL: {1 18325 INVITE Nf6-dl2WeXF.LJhXotiRsuMhijsNx45o} <core> [core/mem/q_malloc.c:144]: qm_debug_check_frag(): BUG: qm: prev. fragm. tail overwritten(0, abcdefed)[0x7f467d438768:0x7f467d4387a0]! Memory allocator was called from cdp: diameter_avp.c:157. Fragment marked by cdp: peerstatemachine.c:602. Exec from core/mem/q_malloc.c:384. Nov 11 11:39:49 ip-10-195-0-38 /usr/local/sbin/kamailio[25599]: CRITICAL: <core> [core/pass_fd.c:277]: receive_fd(): EOF on 16 Nov 11 11:39:52 ip-10-195-0-38 /usr/local/sbin/kamailio[25567]: ALERT: <core> [main.c:740]: handle_sigs(): child process 25571 exited by a signal 6 Nov 11 11:39:52 ip-10-195-0-38 /usr/local/sbin/kamailio[25567]: ALERT: <core> [main.c:743]: handle_sigs(): core was generated Nov 11 11:39:52 ip-10-195-0-38 /usr/local/sbin/kamailio[25567]: INFO: <core> [main.c:766]: handle_sigs(): terminating due to SIGCHLD Thanks you in Advance, Venkey -- Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html

4 9

WebRTC video call terminated after ~30 seconds
by Mathias Brodala - Pagemachine AG 14 Nov '18

14 Nov '18

Hi, I am currently testing a setup to do video calls via WebRTC and have set up Kamailio as SIP server. So far the calls are working fine, but after around 30 seconds the calls are terminated. I can reproduce this easily both with the JsSIP demo [0] as well as the SIPjs demo [1]. The browser console using JsSIP log [2] shows me this: > JsSIP:WebSocketInterface WebSocket wss://sip.example.org closed +60s > jssip-3.2.10.js:23490 JsSIP:WebSocketInterface WebSocket abrupt disconnection +1ms Please also have a look at my kamailio.cfg [3]. I tried to follow the docs of the websocket module [4] as close as possible to get everything up and running. Kamailio is currently running on a private DigitalOcean droplet and I already tried to disable all firewall rules without change. I also asked the DO staff if something could lead to UDP packets getting dropped after some time but I was told that there is no such logic in the DO network. Please let me know if you can find anything unusual which could cause this behavior or if you need more information. Thank you, Mathias Brodala [0] https://tryit.jssip.net/ [1] https://sipjs.com/demo-phone/ [2] https://gist.github.com/mbrodala/0f81aaa174be87096cf20502633f3ac3 [3] https://gist.github.com/mbrodala/066faa455da46362dab3dd5326ba8ad1 [4] https://www.kamailio.org/docs/modules/5.1.x/modules/websocket.html -- Dipl.-Inf. (FH) Mathias Brodala Tel.: 069.260.99.70.45 Fax: .31 mbrodala(a)pagemachine.de <https://www.pagemachine.de/> Pagemachine AG Solmsstraße 6a, 60486 Frankfurt am Main <https://maps.google.com/?q=Solmsstra%C3%9Fe+6a,+60486+Frankfurt+am+Main&ent…> Vorstand: Volker Neuenhaus, Stefan Schütt, Miklos Weiszhaupt Vorsitzender des Aufsichtsrats: Holger Kleinschmidt Registergericht: Amtsgericht Frankfurt Registernummer: HRB 56436 Umsatzsteuer-ID: DE226286966 <https://www.kununu.com/de/pagemachine> <https://www.kununu.com/de/pagemachine> <http://www.frankfurt-main.ihk.de/> <https://typo3.com/>

2 1

topos without db?
by Giuseppe Pandolfi 13 Nov '18

13 Nov '18

Hi, Is it possible using topos module without db support? I'm trying to use topos module with sqlite db backend, but I have any concurrency problems during write procedure (I use WALL pragma). When execute speed calls traffic sqlite emits an error trace telling it's locked. Is it possible to use a sort of hash tabel to save topos informations and don't use the db? Best regards, Giuseppe

5 4

variable $rb not updated on failure route after a 302 on the same PID
by David Escartín 13 Nov '18

13 Nov '18

Hello all we are seeing what we think is quite strange behaviour We have expecienced this on 5.0 and 5.1 version. this is the call flow INV--> <-- 302 (SDP) INV--> <-- 503 (SDP) (or another 302) When we receive a 302 and we load contacts and create a new branch, when we receive the second error response, and we receive it on the same udp receiver process, if we read the content of $rb on the the onreply_route, we get the proper value of the response SDP, but when we read $T_rpl($rb) on the failure_route, we get the value of the first error transaction. If the response (second) is received in another PID, it's ok. I'm not sure if i'm explaining myself, but we would think that the value should be updated, no matter which PID is used to process the response for example, running the kamailio with only 1 child. For the first 302 we have onreply route checking $rb 1(7698) INFO: <script>: LAL {"sdp_data":"3466666666","sdp_data_2":null,"nrn":null} failure_route checking $T_rpl($rb) 1(7698) INFO: <script>: LOOOOOOOOL {"sdp_data":"3466666666","sdp_data_2":null,"nrn":null} and for the next error 1(7698) INFO: <script>: LAL {"sdp_data":"34619796636","sdp_data_2":null,"nrn":null} 1(7698) INFO: <script>: LOOOOOOOOL {"sdp_data":"3466666666","sdp_data_2":null,"nrn":null} If we run it with 16 children and the PID don't match. For the first 302 we have onreply route checking $rb 13(8360) INFO: <script>: LAL {"sdp_data":"3466666666","sdp_data_2":null,"nrn":null} failure_route checking $T_rpl($rb) 13(8360) INFO: <script>: LOOOOOOOOL {"sdp_data":"3466666666","sdp_data_2":null,"nrn":null} and for the next error after loading the contacts 15(8362) INFO: <script>: LAL {"sdp_data":"34619796636","sdp_data_2":null,"nrn":null} 15(8362) INFO: <script>: LOOOOOOOOL {"sdp_data":"34619796636","sdp_data_2":null,"nrn":null} i attach you the logs in both cases could you please check if you see anything wrong? best regards david 16_children.log 11(8358) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/634) [[INVITE sip:34606147628@10.100.10.67:5069 SIP/2.0 0D 0A Via: SIP/2.0/UDP 10.100.10.67:5061;branch=z9hG4bK-]] 11(8358) DEBUG: <core> [core/parser/msg_parser.c:604]: parse_msg(): SIP Request: 11(8358) DEBUG: <core> [core/parser/msg_parser.c:606]: parse_msg(): method: <INVITE> 11(8358) DEBUG: <core> [core/parser/msg_parser.c:608]: parse_msg(): uri: <sip:34606147628@10.100.10.67:5069> 11(8358) DEBUG: <core> [core/parser/msg_parser.c:610]: parse_msg(): version: <SIP/2.0> 11(8358) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-9680-1-0>; state=16 11(8358) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 11(8358) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 11(8358) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 11(8358) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=10 11(8358) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [44]; uri=[sip:34606147628@10.100.10.67:5069] 11(8358) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069> ] 11(8358) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 11(8358) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - request - call-id: [1-9680(a)10.100.10.67] - cseq: [1 INVITE] 11(8358) DEBUG: <core> [core/receive.c:248]: receive_msg(): preparing to run routing scripts... 11(8358) INFO: <script>: hereeeeeeeeeee 11(8358) DEBUG: tm [t_lookup.c:1320]: t_newtran(): msg id=1 , global msg id=0 , T on entrance=0xffffffffffffffff 11(8358) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=217 11(8358) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 11(8358) DEBUG: tm [t_lookup.c:477]: t_lookup_request(): start searching: hash=13774, isACK=0 11(8358) DEBUG: tm [t_lookup.c:435]: matching_3261(): RFC3261 transaction matching failed 11(8358) DEBUG: tm [t_lookup.c:659]: t_lookup_request(): no transaction found 11(8358) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=9680SIPpTag001 11(8358) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 11(8358) DEBUG: <core> [core/md5utils.c:67]: MD5StringArray(): MD5 calculated: 56115a2d09f62d466f1d45a5f5ff7cc2 11(8358) DEBUG: tm [t_funcs.c:324]: t_relay_to(): new INVITE 11(8358) DEBUG: <core> [core/msg_translator.c:159]: check_via_address(): (10.100.10.67, 10.100.10.67, 0) 11(8358) DEBUG: tm [t_reply.c:596]: _reply_light(): reply sent out. buf=0x7f334b5f4ea0: SIP/2.0 100 trying -..., shmem=0x7f3346638240: SIP/2.0 100 trying - 11(8358) DEBUG: tm [t_reply.c:606]: _reply_light(): finished 11(8358) INFO: <script>: LEL 11(8358) DEBUG: <core> [core/msg_translator.c:159]: check_via_address(): (10.100.10.67, 10.100.10.67, 0) 11(8358) INFO: <script>: hereeeeeeeeeee 11(8358) DEBUG: tm [t_funcs.c:372]: t_relay_to(): new transaction forwarded 11(8358) DEBUG: <core> [core/receive.c:289]: receive_msg(): request-route executed in: 550 usec 11(8358) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 11(8358) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 11(8358) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 11(8358) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 11(8358) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 11(8358) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 11(8358) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 11(8358) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 11(8358) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/397) [[SIP/2.0 100 Trying 0D 0A Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKec53.56115a2d09f62d466f1d45a5f]] 11(8358) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 11(8358) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 11(8358) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <100> 11(8358) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <Trying> 11(8358) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKec53.56115a2d09f62d466f1d45a5f5ff7cc2.0>; state=9 11(8358) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 11(8358) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-9680-1-0>; state=16 11(8358) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 11(8358) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 11(8358) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 11(8358) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=10 11(8358) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [44]; uri=[sip:34606147628@10.100.10.67:5069] 11(8358) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069> ] 11(8358) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 11(8358) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - reply - call-id: [1-9680(a)10.100.10.67] - cseq: [1 INVITE] 11(8358) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7f334b5f3768) id=2 global id=1 T start=0xffffffffffffffff 13(8360) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/479) [[SIP/2.0 302 Moved Temporarily 0D 0A Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKec53.56115a2d09f62d]] 11(8358) DEBUG: tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 13774 label 0 branch 0 11(8358) DEBUG: tm [t_lookup.c:951]: t_reply_matching(): reply (0x7f334b5f3768) matched an active transaction (T=0x7f334663b040)! 11(8358) DEBUG: tm [t_lookup.c:1088]: t_check_msg(): msg (0x7f334b5f3768) id=2 global id=2 T end=0x7f334663b040 11(8358) DEBUG: tm [t_reply.c:2209]: reply_received(): org. status uas=100, uac[0]=0 local=0 is_invite=1) 11(8358) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=0 11(8358) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 11(8358) INFO: <script>: LAL 11(8358) DEBUG: tm [t_reply.c:1265]: t_should_relay_response(): ->>>>>>>>> T_code=100, new_code=100 11(8358) DEBUG: tm [t_reply.c:1788]: relay_reply(): branch=0, save=0, relay=-1 icode=0 11(8358) DEBUG: <core> [core/receive.c:362]: receive_msg(): reply-route executed in: 149 usec 11(8358) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 11(8358) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 11(8358) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 11(8358) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 11(8358) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 11(8358) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 11(8358) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 11(8358) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 13(8360) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 13(8360) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 13(8360) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <302> 13(8360) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <Moved Temporarily> 13(8360) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKec53.56115a2d09f62d466f1d45a5f5ff7cc2.0>; state=9 13(8360) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 13(8360) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-9680-1-0>; state=16 13(8360) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 13(8360) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 13(8360) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 13(8360) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=5 13(8360) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 13(8360) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 13(8360) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069>] 13(8360) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 13(8360) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - reply - call-id: [1-9680(a)10.100.10.67] - cseq: [1 INVITE] 13(8360) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7f334b5f3768) id=1 global id=0 T start=0xffffffffffffffff 13(8360) DEBUG: tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 13774 label 0 branch 0 13(8360) DEBUG: tm [t_lookup.c:951]: t_reply_matching(): reply (0x7f334b5f3768) matched an active transaction (T=0x7f334663b040)! 13(8360) DEBUG: tm [t_lookup.c:1088]: t_check_msg(): msg (0x7f334b5f3768) id=1 global id=1 T end=0x7f334663b040 13(8360) DEBUG: tm [t_reply.c:2209]: reply_received(): org. status uas=100, uac[0]=100 local=0 is_invite=1) 13(8360) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=63 13(8360) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 13(8360) INFO: <script>: LAL {"sdp_data":"3466666666","sdp_data_2":null,"nrn":null} 13(8360) DEBUG: tm [t_reply.c:1265]: t_should_relay_response(): ->>>>>>>>> T_code=100, new_code=302 13(8360) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 13(8360) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 13(8360) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <302> 13(8360) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <Moved Temporarily> 13(8360) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKec53.56115a2d09f62d466f1d45a5f5ff7cc2.0>; state=9 13(8360) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 13(8360) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-9680-1-0>; state=16 13(8360) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 13(8360) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 13(8360) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 13(8360) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=5 13(8360) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 13(8360) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 13(8360) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069>] 13(8360) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 13(8360) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=63 13(8360) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 13(8360) INFO: <script>: LOOOOOOOOL {"sdp_data":"3466666666","sdp_data_2":null,"nrn":null} 13(8360) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7f3346637088) id=0 global id=0 T start=0x7f334663b040 13(8360) DEBUG: tm [t_lookup.c:1091]: t_check_msg(): T (0x7f334663b040) already found for msg (0x7f3346637088)! 13(8360) DEBUG: tmx [t_var.c:534]: pv_get_tm_reply_code(): reply code is <302> 13(8360) INFO: <script>: Call: 302 received, trying to load contacts 13(8360) DEBUG: uac_redirect [rd_funcs.c:72]: get_redirect(): resume branch=0 13(8360) DEBUG: uac_redirect [rd_funcs.c:79]: get_redirect(): checking branch=0 (added=0) 13(8360) DEBUG: uac_redirect [rd_funcs.c:83]: get_redirect(): branch=0 is a redirect (added=0) 13(8360) DEBUG: uac_redirect [rd_funcs.c:159]: sort_contacts(): sort_contacts: <sip:34666988297@10.100.10.67:5060> q=10 13(8360) DEBUG: uac_redirect [rd_funcs.c:295]: shmcontact2dset(): adding contact <sip:34666988297@10.100.10.67:5060> 13(8360) DEBUG: <core> [sruid.c:183]: sruid_next(): new sruid is [rdir-5be4236b-20a8-1] (1 / 20) 13(8360) DEBUG: tm [t_serial.c:191]: ki_t_load_contacts(): nr_branches is 1 13(8360) DEBUG: tm [t_serial.c:194]: ki_t_load_contacts(): nothing to do - only one contact! 13(8360) INFO: <script>: LEL 13(8360) DEBUG: <core> [core/msg_translator.c:159]: check_via_address(): (10.100.10.67, 10.100.10.67, 0) 13(8360) INFO: <script>: hereeeeeeeeeee 13(8360) DEBUG: tm [t_reply.c:1788]: relay_reply(): branch=0, save=0, relay=-1 icode=0 13(8360) DEBUG: <core> [core/receive.c:362]: receive_msg(): reply-route executed in: 783 usec 13(8360) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 13(8360) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 13(8360) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 13(8360) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 13(8360) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 13(8360) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 13(8360) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 13(8360) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 14(8361) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/397) [[SIP/2.0 100 Trying 0D 0A Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKec53.56115a2d09f62d466f1d45a5f]] 15(8362) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/482) [[SIP/2.0 503 Service Unavailable 0D 0A Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKec53.56115a2d09f6]] 14(8361) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 14(8361) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 14(8361) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <100> 14(8361) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <Trying> 15(8362) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 15(8362) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 15(8362) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <503> 15(8362) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <Service Unavailable> 14(8361) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKec53.56115a2d09f62d466f1d45a5f5ff7cc2.1>; state=9 14(8361) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 14(8361) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-9680-1-0>; state=16 14(8361) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 14(8361) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 14(8361) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 15(8362) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKec53.56115a2d09f62d466f1d45a5f5ff7cc2.1>; state=9 15(8362) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 15(8362) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-9680-1-0>; state=16 15(8362) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 14(8361) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=10 15(8362) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 14(8361) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [44]; uri=[sip:34606147628@10.100.10.67:5069] 15(8362) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 14(8361) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069> ] 14(8361) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 14(8361) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - reply - call-id: [1-9680(a)10.100.10.67] - cseq: [1 INVITE] 15(8362) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=5 15(8362) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 15(8362) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 15(8362) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069>] 14(8361) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7f334b5f3768) id=1 global id=0 T start=0xffffffffffffffff 14(8361) DEBUG: tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 13774 label 0 branch 1 14(8361) DEBUG: tm [t_lookup.c:951]: t_reply_matching(): reply (0x7f334b5f3768) matched an active transaction (T=0x7f334663b040)! 14(8361) DEBUG: tm [t_lookup.c:1088]: t_check_msg(): msg (0x7f334b5f3768) id=1 global id=1 T end=0x7f334663b040 15(8362) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 14(8361) DEBUG: tm [t_reply.c:2209]: reply_received(): org. status uas=100, uac[1]=0 local=0 is_invite=1) 15(8362) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - reply - call-id: [1-9680(a)10.100.10.67] - cseq: [1 INVITE] 15(8362) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7f334b5f3768) id=1 global id=0 T start=0xffffffffffffffff 15(8362) DEBUG: tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 13774 label 0 branch 1 15(8362) DEBUG: tm [t_lookup.c:951]: t_reply_matching(): reply (0x7f334b5f3768) matched an active transaction (T=0x7f334663b040)! 14(8361) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=0 15(8362) DEBUG: tm [t_lookup.c:1088]: t_check_msg(): msg (0x7f334b5f3768) id=1 global id=1 T end=0x7f334663b040 15(8362) DEBUG: tm [t_reply.c:2209]: reply_received(): org. status uas=100, uac[1]=100 local=0 is_invite=1) 14(8361) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 14(8361) INFO: <script>: LAL 14(8361) DEBUG: tm [t_reply.c:1265]: t_should_relay_response(): ->>>>>>>>> T_code=100, new_code=100 14(8361) DEBUG: tm [t_reply.c:1788]: relay_reply(): branch=1, save=0, relay=-1 icode=0 14(8361) DEBUG: <core> [core/receive.c:362]: receive_msg(): reply-route executed in: 199 usec 14(8361) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 14(8361) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 14(8361) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 14(8361) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 14(8361) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 14(8361) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 14(8361) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 14(8361) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 15(8362) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=64 15(8362) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 15(8362) INFO: <script>: LAL {"sdp_data":"34619796636","sdp_data_2":null,"nrn":null} 15(8362) DEBUG: tm [t_reply.c:1265]: t_should_relay_response(): ->>>>>>>>> T_code=100, new_code=503 15(8362) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 15(8362) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 15(8362) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <503> 15(8362) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <Service Unavailable> 15(8362) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKec53.56115a2d09f62d466f1d45a5f5ff7cc2.1>; state=9 15(8362) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 15(8362) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-9680-1-0>; state=16 15(8362) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 15(8362) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 15(8362) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 15(8362) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=5 15(8362) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 15(8362) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 15(8362) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069>] 15(8362) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 15(8362) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=64 15(8362) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 15(8362) INFO: <script>: LOOOOOOOOL {"sdp_data":"34619796636","sdp_data_2":null,"nrn":null} 15(8362) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7f3346637088) id=0 global id=0 T start=0x7f334663b040 15(8362) DEBUG: tm [t_lookup.c:1091]: t_check_msg(): T (0x7f334663b040) already found for msg (0x7f3346637088)! 15(8362) DEBUG: tmx [t_var.c:534]: pv_get_tm_reply_code(): reply code is <503> 15(8362) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7f3346637088) id=0 global id=0 T start=0x7f334663b040 15(8362) DEBUG: tm [t_lookup.c:1091]: t_check_msg(): T (0x7f334663b040) already found for msg (0x7f3346637088)! 15(8362) DEBUG: tmx [t_var.c:534]: pv_get_tm_reply_code(): reply code is <503> 15(8362) INFO: <script>: LEL 15(8362) DEBUG: <core> [core/msg_translator.c:159]: check_via_address(): (10.100.10.67, 10.100.10.67, 0) 15(8362) INFO: <script>: hereeeeeeeeeee 15(8362) DEBUG: tm [t_reply.c:1788]: relay_reply(): branch=1, save=0, relay=-1 icode=0 15(8362) DEBUG: <core> [core/receive.c:362]: receive_msg(): reply-route executed in: 676 usec 15(8362) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 15(8362) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 15(8362) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 15(8362) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 15(8362) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 15(8362) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 15(8362) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 15(8362) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 15(8362) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/404) [[SIP/2.0 180 Ringing 0D 0A Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKec53.56115a2d09f62d466f1d45a5]] 15(8362) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 15(8362) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 15(8362) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <180> 15(8362) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <Ringing> 15(8362) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKec53.56115a2d09f62d466f1d45a5f5ff7cc2.2>; state=9 15(8362) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 15(8362) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-9680-1-0>; state=16 15(8362) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 15(8362) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 15(8362) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 15(8362) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=5 15(8362) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 15(8362) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 15(8362) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069>] 15(8362) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 15(8362) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - reply - call-id: [1-9680(a)10.100.10.67] - cseq: [1 INVITE] 15(8362) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7f334b5f3768) id=2 global id=1 T start=0xffffffffffffffff 6(8353) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/595) [[SIP/2.0 200 OK 0D 0A Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKec53.56115a2d09f62d466f1d45a5f5ff7]] 15(8362) DEBUG: tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 13774 label 0 branch 2 15(8362) DEBUG: tm [t_lookup.c:951]: t_reply_matching(): reply (0x7f334b5f3768) matched an active transaction (T=0x7f334663b040)! 15(8362) DEBUG: tm [t_lookup.c:1088]: t_check_msg(): msg (0x7f334b5f3768) id=2 global id=2 T end=0x7f334663b040 15(8362) DEBUG: tm [t_reply.c:2209]: reply_received(): org. status uas=100, uac[2]=0 local=0 is_invite=1) 15(8362) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=0 15(8362) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 15(8362) INFO: <script>: LAL 15(8362) DEBUG: tm [t_reply.c:1265]: t_should_relay_response(): ->>>>>>>>> T_code=100, new_code=180 15(8362) DEBUG: tm [t_reply.c:1788]: relay_reply(): branch=2, save=0, relay=2 icode=0 15(8362) DEBUG: <core> [core/msg_translator.c:2270]: generate_res_buf_from_sip_res(): old size: 404, new size: 318 15(8362) DEBUG: <core> [core/msg_translator.c:2288]: generate_res_buf_from_sip_res(): copied size: orig:112, new: 26, rest: 292 msg= SIP/2.0 180 Ringing Via: SIP/2.0/UDP 10.100.10.67:5061;branch=z9hG4bK-9680-1-0 From: "BTS" <sip:34917019888@10.100.10.67:5061>;tag=9680SIPpTag001 To: "Javi" <sip:34606147628@10.100.10.67:5069>;tag=5 Call-ID: 1-9680(a)10.100.10.67 CSeq: 1 INVITE Contact: <sip:10.100.10.67:5060;transport=UDP> Content-Length: 0 15(8362) DEBUG: <core> [core/receive.c:362]: receive_msg(): reply-route executed in: 71 usec 15(8362) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 15(8362) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 15(8362) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 15(8362) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 15(8362) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 15(8362) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 15(8362) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 15(8362) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 6(8353) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 6(8353) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 6(8353) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <200> 6(8353) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <OK> 6(8353) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKec53.56115a2d09f62d466f1d45a5f5ff7cc2.2>; state=9 6(8353) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 6(8353) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-9680-1-0>; state=16 6(8353) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 6(8353) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 6(8353) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 6(8353) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=5 6(8353) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 6(8353) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 6(8353) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069>] 6(8353) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 6(8353) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - reply - call-id: [1-9680(a)10.100.10.67] - cseq: [1 INVITE] 6(8353) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7f334b5f3768) id=1 global id=0 T start=0xffffffffffffffff 6(8353) DEBUG: tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 13774 label 0 branch 2 6(8353) DEBUG: tm [t_lookup.c:951]: t_reply_matching(): reply (0x7f334b5f3768) matched an active transaction (T=0x7f334663b040)! 6(8353) DEBUG: tm [t_lookup.c:1088]: t_check_msg(): msg (0x7f334b5f3768) id=1 global id=1 T end=0x7f334663b040 6(8353) DEBUG: tm [t_reply.c:2209]: reply_received(): org. status uas=180, uac[2]=180 local=0 is_invite=1) 6(8353) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=161 6(8353) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 6(8353) INFO: <script>: LAL v=0 o=user1 53655765 2353687637 IN IP4 10.100.10.67 s=- c=IN IP4 10.100.10.67 t=0 0 m=audio 6000 RTP/AVP 0 18 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 6(8353) DEBUG: tm [t_reply.c:1265]: t_should_relay_response(): ->>>>>>>>> T_code=180, new_code=200 6(8353) DEBUG: tm [t_reply.c:1788]: relay_reply(): branch=2, save=0, relay=2 icode=0 6(8353) DEBUG: <core> [core/msg_translator.c:2270]: generate_res_buf_from_sip_res(): old size: 595, new size: 509 6(8353) DEBUG: <core> [core/msg_translator.c:2288]: generate_res_buf_from_sip_res(): copied size: orig:107, new: 21, rest: 488 msg= SIP/2.0 200 OK Via: SIP/2.0/UDP 10.100.10.67:5061;branch=z9hG4bK-9680-1-0 From: "BTS" <sip:34917019888@10.100.10.67:5061>;tag=9680SIPpTag001 To: "Javi" <sip:34606147628@10.100.10.67:5069>;tag=5 Call-ID: 1-9680(a)10.100.10.67 CSeq: 1 INVITE Contact: <sip:10.100.10.67:5060;transport=UDP> Content-Type: application/sdp Content-Length: 161 v=0 o=user1 53655765 2353687637 IN IP4 10.100.10.67 s=- c=IN IP4 10.100.10.67 t=0 0 m=audio 6000 RTP/AVP 0 18 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 6(8353) DEBUG: tm [t_reply.c:1631]: cleanup_uac_timers(): RETR/FR timers reset 6(8353) DEBUG: <core> [core/receive.c:362]: receive_msg(): reply-route executed in: 283 usec 6(8353) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 6(8353) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 6(8353) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 6(8353) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 6(8353) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 6(8353) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 6(8353) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 6(8353) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 6(8353) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/323) [[ACK sip:34606147628@10.100.10.67:5060 SIP/2.0 0D 0A Via: SIP/2.0/UDP 10.100.10.67:5061;branch=z9hG4bK-968]] 6(8353) DEBUG: <core> [core/parser/msg_parser.c:604]: parse_msg(): SIP Request: 6(8353) DEBUG: <core> [core/parser/msg_parser.c:606]: parse_msg(): method: <ACK> 6(8353) DEBUG: <core> [core/parser/msg_parser.c:608]: parse_msg(): uri: <sip:34606147628@10.100.10.67:5060> 6(8353) DEBUG: <core> [core/parser/msg_parser.c:610]: parse_msg(): version: <SIP/2.0> 6(8353) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-9680-1-0>; state=16 6(8353) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 6(8353) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 6(8353) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 6(8353) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=5 6(8353) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 6(8353) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 6(8353) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Test" <sip:34606147628@10.100.10.67:5069>] 6(8353) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <ACK> 6(8353) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - request - call-id: [1-9680(a)10.100.10.67] - cseq: [1 ACK] 6(8353) DEBUG: <core> [core/receive.c:248]: receive_msg(): preparing to run routing scripts... 6(8353) DEBUG: sl [sl_funcs.c:387]: sl_filter_ACK(): too late to be a local ACK! 6(8353) INFO: <script>: hereeeeeeeeeee 6(8353) DEBUG: tm [t_lookup.c:1320]: t_newtran(): msg id=2 , global msg id=1 , T on entrance=0xffffffffffffffff 6(8353) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=0 6(8353) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 6(8353) DEBUG: tm [t_lookup.c:477]: t_lookup_request(): start searching: hash=13774, isACK=1 6(8353) DEBUG: tm [t_lookup.c:435]: matching_3261(): RFC3261 transaction matching failed 6(8353) DEBUG: tm [t_lookup.c:659]: t_lookup_request(): no transaction found 6(8353) DEBUG: tm [t_funcs.c:284]: t_relay_to(): forwarding ACK statelessly 6(8353) DEBUG: <core> [core/md5utils.c:67]: MD5StringArray(): MD5 calculated: 56115a2d09f62d466f1d45a5f5ff7cc2 6(8353) DEBUG: <core> [core/msg_translator.c:159]: check_via_address(): (10.100.10.67, 10.100.10.67, 0) 6(8353) DEBUG: <core> [core/forward.c:557]: forward_request(): Sending: ACK sip:34606147628@10.100.10.67:5060 SIP/2.0 Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKec53.56115a2d09f62d466f1d45a5f5ff7cc2.0 Via: SIP/2.0/UDP 10.100.10.67:5061;branch=z9hG4bK-9680-1-0 From: "BTS" <sip:34917019888@10.100.10.67:5061>;tag=9680SIPpTag001 To: "Test" <sip:34606147628@10.100.10.67:5069>;tag=5 Call-ID: 1-9680(a)10.100.10.67 CSeq: 1 ACK Max-Forwards: 70 Subject: 1 Content-Length: 0 . 6(8353) DEBUG: <core> [core/forward.c:559]: forward_request(): orig. len=323, new_len=414, proto=1 6(8353) INFO: <script>: hereeeeeeeeeee 6(8353) DEBUG: <core> [core/receive.c:289]: receive_msg(): request-route executed in: 232 usec 6(8353) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 6(8353) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 6(8353) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 6(8353) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 6(8353) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 6(8353) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 6(8353) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 6(8353) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 3(8350) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/338) [[BYE sip:34606147628@10.100.10.67:5060 SIP/2.0 0D 0A Via: SIP/2.0/UDP 10.100.10.67:5061;branch=z9hG4bK-968]] 3(8350) DEBUG: <core> [core/parser/msg_parser.c:604]: parse_msg(): SIP Request: 3(8350) DEBUG: <core> [core/parser/msg_parser.c:606]: parse_msg(): method: <BYE> 3(8350) DEBUG: <core> [core/parser/msg_parser.c:608]: parse_msg(): uri: <sip:34606147628@10.100.10.67:5060> 3(8350) DEBUG: <core> [core/parser/msg_parser.c:610]: parse_msg(): version: <SIP/2.0> 3(8350) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-9680-1-8>; state=16 3(8350) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 3(8350) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 3(8350) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 3(8350) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=5 3(8350) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 3(8350) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 3(8350) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Test" <sip:34606147628@10.100.10.67:5069>] 3(8350) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <2> <BYE> 3(8350) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - request - call-id: [1-9680(a)10.100.10.67] - cseq: [2 BYE] 3(8350) DEBUG: <core> [core/receive.c:248]: receive_msg(): preparing to run routing scripts... 3(8350) INFO: <script>: hereeeeeeeeeee 3(8350) DEBUG: tm [t_lookup.c:1320]: t_newtran(): msg id=2 , global msg id=1 , T on entrance=0xffffffffffffffff 3(8350) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=0 3(8350) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 3(8350) DEBUG: tm [t_lookup.c:477]: t_lookup_request(): start searching: hash=13771, isACK=0 3(8350) DEBUG: tm [t_lookup.c:435]: matching_3261(): RFC3261 transaction matching failed 3(8350) DEBUG: tm [t_lookup.c:659]: t_lookup_request(): no transaction found 3(8350) DEBUG: <core> [core/md5utils.c:67]: MD5StringArray(): MD5 calculated: 5b69d64cadac24fd6fc477c074a9b4c9 3(8350) INFO: <script>: LEL 3(8350) DEBUG: <core> [core/msg_translator.c:159]: check_via_address(): (10.100.10.67, 10.100.10.67, 0) 3(8350) INFO: <script>: hereeeeeeeeeee 3(8350) DEBUG: tm [t_funcs.c:372]: t_relay_to(): new transaction forwarded 3(8350) DEBUG: <core> [core/receive.c:289]: receive_msg(): request-route executed in: 265 usec 3(8350) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 3(8350) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 3(8350) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 3(8350) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 3(8350) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 3(8350) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 3(8350) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 3(8350) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 7(8354) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/396) [[SIP/2.0 200 OK 0D 0A Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKbc53.5b69d64cadac24fd6fc477c074a9b]] 7(8354) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 7(8354) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 7(8354) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <200> 7(8354) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <OK> 7(8354) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKbc53.5b69d64cadac24fd6fc477c074a9b4c9.0>; state=9 7(8354) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 7(8354) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-9680-1-8>; state=16 7(8354) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 7(8354) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 7(8354) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 7(8354) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=5 7(8354) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 7(8354) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 7(8354) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Test" <sip:34606147628@10.100.10.67:5069>] 7(8354) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <2> <BYE> 7(8354) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - reply - call-id: [1-9680(a)10.100.10.67] - cseq: [2 BYE] 7(8354) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7f334b5f3768) id=2 global id=1 T start=0xffffffffffffffff 7(8354) DEBUG: tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 13771 label 0 branch 0 7(8354) DEBUG: tm [t_lookup.c:951]: t_reply_matching(): reply (0x7f334b5f3768) matched an active transaction (T=0x7f33466359d8)! 7(8354) DEBUG: tm [t_lookup.c:1088]: t_check_msg(): msg (0x7f334b5f3768) id=2 global id=2 T end=0x7f33466359d8 7(8354) DEBUG: tm [t_reply.c:2209]: reply_received(): org. status uas=0, uac[0]=0 local=0 is_invite=0) 7(8354) DEBUG: tm [t_reply.c:1265]: t_should_relay_response(): ->>>>>>>>> T_code=0, new_code=200 7(8354) DEBUG: tm [t_reply.c:1788]: relay_reply(): branch=0, save=0, relay=0 icode=0 7(8354) DEBUG: <core> [core/msg_translator.c:2270]: generate_res_buf_from_sip_res(): old size: 396, new size: 310 7(8354) DEBUG: <core> [core/msg_translator.c:2288]: generate_res_buf_from_sip_res(): copied size: orig:107, new: 21, rest: 289 msg= SIP/2.0 200 OK Via: SIP/2.0/UDP 10.100.10.67:5061;branch=z9hG4bK-9680-1-8 From: "BTS" <sip:34917019888@10.100.10.67:5061>;tag=9680SIPpTag001 To: "Test" <sip:34606147628@10.100.10.67:5069>;tag=5 Call-ID: 1-9680(a)10.100.10.67 CSeq: 2 BYE Contact: <sip:10.100.10.67:5060;transport=UDP> Content-Length: 0 7(8354) DEBUG: tm [t_reply.c:1631]: cleanup_uac_timers(): RETR/FR timers reset 7(8354) DEBUG: <core> [core/receive.c:362]: receive_msg(): reply-route executed in: 137 usec 7(8354) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 7(8354) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 7(8354) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 7(8354) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 7(8354) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 7(8354) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 7(8354) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 7(8354) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 18(8365) DEBUG: tm [h_table.c:129]: free_cell_helper(): freeing transaction 0x7f334663b040 from timer.c:654 18(8365) DEBUG: tm [h_table.c:129]: free_cell_helper(): freeing transaction 0x7f33466359d8 from timer.c:654 1_children.log 1(7698) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/634) [[INVITE sip:34606147628@10.100.10.67:5069 SIP/2.0 0D 0A Via: SIP/2.0/UDP 10.100.10.67:5061;branch=z9hG4bK-]] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:604]: parse_msg(): SIP Request: 1(7698) DEBUG: <core> [core/parser/msg_parser.c:606]: parse_msg(): method: <INVITE> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:608]: parse_msg(): uri: <sip:34606147628@10.100.10.67:5069> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:610]: parse_msg(): version: <SIP/2.0> 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-8173-1-0>; state=16 1(7698) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 1(7698) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 1(7698) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=10 1(7698) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [44]; uri=[sip:34606147628@10.100.10.67:5069] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069> ] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 1(7698) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - request - call-id: [1-8173(a)10.100.10.67] - cseq: [1 INVITE] 1(7698) DEBUG: <core> [core/receive.c:248]: receive_msg(): preparing to run routing scripts... 1(7698) INFO: <script>: hereeeeeeeeeee 1(7698) DEBUG: tm [t_lookup.c:1320]: t_newtran(): msg id=1 , global msg id=0 , T on entrance=0xffffffffffffffff 1(7698) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=217 1(7698) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 1(7698) DEBUG: tm [t_lookup.c:477]: t_lookup_request(): start searching: hash=65453, isACK=0 1(7698) DEBUG: tm [t_lookup.c:435]: matching_3261(): RFC3261 transaction matching failed 1(7698) DEBUG: tm [t_lookup.c:659]: t_lookup_request(): no transaction found 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=8173SIPpTag001 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 1(7698) DEBUG: <core> [core/md5utils.c:67]: MD5StringArray(): MD5 calculated: 8f25665e8c867e73b07da3cb1f702171 1(7698) DEBUG: tm [t_funcs.c:324]: t_relay_to(): new INVITE 1(7698) DEBUG: <core> [core/msg_translator.c:159]: check_via_address(): (10.100.10.67, 10.100.10.67, 0) 1(7698) DEBUG: tm [t_reply.c:596]: _reply_light(): reply sent out. buf=0x7fe2c208bea0: SIP/2.0 100 trying -..., shmem=0x7fe2bd0c9f40: SIP/2.0 100 trying - 1(7698) DEBUG: tm [t_reply.c:606]: _reply_light(): finished 1(7698) INFO: <script>: LEL 1(7698) DEBUG: <core> [core/msg_translator.c:159]: check_via_address(): (10.100.10.67, 10.100.10.67, 0) 1(7698) INFO: <script>: hereeeeeeeeeee 1(7698) DEBUG: tm [t_funcs.c:372]: t_relay_to(): new transaction forwarded 1(7698) DEBUG: <core> [core/receive.c:289]: receive_msg(): request-route executed in: 607 usec 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 1(7698) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 1(7698) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/397) [[SIP/2.0 100 Trying 0D 0A Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKdaff.8f25665e8c867e73b07da3cb1]] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 1(7698) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <100> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <Trying> 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKdaff.8f25665e8c867e73b07da3cb1f702171.0>; state=9 1(7698) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-8173-1-0>; state=16 1(7698) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 1(7698) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 1(7698) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=10 1(7698) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [44]; uri=[sip:34606147628@10.100.10.67:5069] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069> ] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 1(7698) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - reply - call-id: [1-8173(a)10.100.10.67] - cseq: [1 INVITE] 1(7698) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7fe2c208a768) id=2 global id=1 T start=0xffffffffffffffff 1(7698) DEBUG: tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 65453 label 0 branch 0 1(7698) DEBUG: tm [t_lookup.c:951]: t_reply_matching(): reply (0x7fe2c208a768) matched an active transaction (T=0x7fe2bd0c76d8)! 1(7698) DEBUG: tm [t_lookup.c:1088]: t_check_msg(): msg (0x7fe2c208a768) id=2 global id=2 T end=0x7fe2bd0c76d8 1(7698) DEBUG: tm [t_reply.c:2209]: reply_received(): org. status uas=100, uac[0]=0 local=0 is_invite=1) 1(7698) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=0 1(7698) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 1(7698) INFO: <script>: LAL 1(7698) DEBUG: tm [t_reply.c:1265]: t_should_relay_response(): ->>>>>>>>> T_code=100, new_code=100 1(7698) DEBUG: tm [t_reply.c:1788]: relay_reply(): branch=0, save=0, relay=-1 icode=0 1(7698) DEBUG: <core> [core/receive.c:362]: receive_msg(): reply-route executed in: 118 usec 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 1(7698) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 1(7698) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/479) [[SIP/2.0 302 Moved Temporarily 0D 0A Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKdaff.8f25665e8c867e]] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 1(7698) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <302> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <Moved Temporarily> 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKdaff.8f25665e8c867e73b07da3cb1f702171.0>; state=9 1(7698) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-8173-1-0>; state=16 1(7698) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 1(7698) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 1(7698) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=3 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 1(7698) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069>] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 1(7698) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - reply - call-id: [1-8173(a)10.100.10.67] - cseq: [1 INVITE] 1(7698) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7fe2c208a768) id=3 global id=2 T start=0xffffffffffffffff 1(7698) DEBUG: tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 65453 label 0 branch 0 1(7698) DEBUG: tm [t_lookup.c:951]: t_reply_matching(): reply (0x7fe2c208a768) matched an active transaction (T=0x7fe2bd0c76d8)! 1(7698) DEBUG: tm [t_lookup.c:1088]: t_check_msg(): msg (0x7fe2c208a768) id=3 global id=3 T end=0x7fe2bd0c76d8 1(7698) DEBUG: tm [t_reply.c:2209]: reply_received(): org. status uas=100, uac[0]=100 local=0 is_invite=1) 1(7698) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=63 1(7698) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 1(7698) INFO: <script>: LAL {"sdp_data":"3466666666","sdp_data_2":null,"nrn":null} 1(7698) DEBUG: tm [t_reply.c:1265]: t_should_relay_response(): ->>>>>>>>> T_code=100, new_code=302 1(7698) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 1(7698) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <302> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <Moved Temporarily> 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKdaff.8f25665e8c867e73b07da3cb1f702171.0>; state=9 1(7698) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-8173-1-0>; state=16 1(7698) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 1(7698) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 1(7698) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=3 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 1(7698) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069>] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=63 1(7698) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 1(7698) INFO: <script>: LOOOOOOOOL {"sdp_data":"3466666666","sdp_data_2":null,"nrn":null} 1(7698) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7fe2bd0ca850) id=0 global id=0 T start=0x7fe2bd0c76d8 1(7698) DEBUG: tm [t_lookup.c:1091]: t_check_msg(): T (0x7fe2bd0c76d8) already found for msg (0x7fe2bd0ca850)! 1(7698) DEBUG: tmx [t_var.c:534]: pv_get_tm_reply_code(): reply code is <302> 1(7698) INFO: <script>: Call: 302 received, trying to load contacts 1(7698) DEBUG: uac_redirect [rd_funcs.c:72]: get_redirect(): resume branch=0 1(7698) DEBUG: uac_redirect [rd_funcs.c:79]: get_redirect(): checking branch=0 (added=0) 1(7698) DEBUG: uac_redirect [rd_funcs.c:83]: get_redirect(): branch=0 is a redirect (added=0) 1(7698) DEBUG: uac_redirect [rd_funcs.c:159]: sort_contacts(): sort_contacts: <sip:34666988297@10.100.10.67:5060> q=10 1(7698) DEBUG: uac_redirect [rd_funcs.c:295]: shmcontact2dset(): adding contact <sip:34666988297@10.100.10.67:5060> 1(7698) DEBUG: <core> [sruid.c:183]: sruid_next(): new sruid is [rdir-5be42212-1e12-1] (1 / 20) 1(7698) DEBUG: tm [t_serial.c:191]: ki_t_load_contacts(): nr_branches is 1 1(7698) DEBUG: tm [t_serial.c:194]: ki_t_load_contacts(): nothing to do - only one contact! 1(7698) INFO: <script>: LEL 1(7698) DEBUG: <core> [core/msg_translator.c:159]: check_via_address(): (10.100.10.67, 10.100.10.67, 0) 1(7698) INFO: <script>: hereeeeeeeeeee 1(7698) DEBUG: tm [t_reply.c:1788]: relay_reply(): branch=0, save=0, relay=-1 icode=0 1(7698) DEBUG: <core> [core/receive.c:362]: receive_msg(): reply-route executed in: 581 usec 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 1(7698) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 1(7698) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/397) [[SIP/2.0 100 Trying 0D 0A Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKdaff.8f25665e8c867e73b07da3cb1]] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 1(7698) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <100> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <Trying> 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKdaff.8f25665e8c867e73b07da3cb1f702171.1>; state=9 1(7698) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-8173-1-0>; state=16 1(7698) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 1(7698) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 1(7698) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=10 1(7698) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [44]; uri=[sip:34606147628@10.100.10.67:5069] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069> ] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 1(7698) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - reply - call-id: [1-8173(a)10.100.10.67] - cseq: [1 INVITE] 1(7698) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7fe2c208a768) id=4 global id=3 T start=0xffffffffffffffff 1(7698) DEBUG: tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 65453 label 0 branch 1 1(7698) DEBUG: tm [t_lookup.c:951]: t_reply_matching(): reply (0x7fe2c208a768) matched an active transaction (T=0x7fe2bd0c76d8)! 1(7698) DEBUG: tm [t_lookup.c:1088]: t_check_msg(): msg (0x7fe2c208a768) id=4 global id=4 T end=0x7fe2bd0c76d8 1(7698) DEBUG: tm [t_reply.c:2209]: reply_received(): org. status uas=100, uac[1]=0 local=0 is_invite=1) 1(7698) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=0 1(7698) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 1(7698) INFO: <script>: LAL 1(7698) DEBUG: tm [t_reply.c:1265]: t_should_relay_response(): ->>>>>>>>> T_code=100, new_code=100 1(7698) DEBUG: tm [t_reply.c:1788]: relay_reply(): branch=1, save=0, relay=-1 icode=0 1(7698) DEBUG: <core> [core/receive.c:362]: receive_msg(): reply-route executed in: 38 usec 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 1(7698) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 1(7698) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/482) [[SIP/2.0 503 Service Unavailable 0D 0A Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKdaff.8f25665e8c86]] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 1(7698) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <503> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <Service Unavailable> 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKdaff.8f25665e8c867e73b07da3cb1f702171.1>; state=9 1(7698) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-8173-1-0>; state=16 1(7698) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 1(7698) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 1(7698) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=3 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 1(7698) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069>] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 1(7698) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - reply - call-id: [1-8173(a)10.100.10.67] - cseq: [1 INVITE] 1(7698) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7fe2c208a768) id=5 global id=4 T start=0xffffffffffffffff 1(7698) DEBUG: tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 65453 label 0 branch 1 1(7698) DEBUG: tm [t_lookup.c:951]: t_reply_matching(): reply (0x7fe2c208a768) matched an active transaction (T=0x7fe2bd0c76d8)! 1(7698) DEBUG: tm [t_lookup.c:1088]: t_check_msg(): msg (0x7fe2c208a768) id=5 global id=5 T end=0x7fe2bd0c76d8 1(7698) DEBUG: tm [t_reply.c:2209]: reply_received(): org. status uas=100, uac[1]=100 local=0 is_invite=1) 1(7698) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=64 1(7698) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 1(7698) INFO: <script>: LAL {"sdp_data":"34619796636","sdp_data_2":null,"nrn":null} 1(7698) DEBUG: tm [t_reply.c:1265]: t_should_relay_response(): ->>>>>>>>> T_code=100, new_code=503 1(7698) INFO: <script>: LOOOOOOOOL {"sdp_data":"3466666666","sdp_data_2":null,"nrn":null} 1(7698) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7fe2bd0cbb88) id=0 global id=0 T start=0x7fe2bd0c76d8 1(7698) DEBUG: tm [t_lookup.c:1091]: t_check_msg(): T (0x7fe2bd0c76d8) already found for msg (0x7fe2bd0cbb88)! 1(7698) DEBUG: tmx [t_var.c:534]: pv_get_tm_reply_code(): reply code is <503> 1(7698) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7fe2bd0cbb88) id=0 global id=0 T start=0x7fe2bd0c76d8 1(7698) DEBUG: tm [t_lookup.c:1091]: t_check_msg(): T (0x7fe2bd0c76d8) already found for msg (0x7fe2bd0cbb88)! 1(7698) DEBUG: tmx [t_var.c:534]: pv_get_tm_reply_code(): reply code is <503> 1(7698) INFO: <script>: LEL 1(7698) DEBUG: <core> [core/msg_translator.c:159]: check_via_address(): (10.100.10.67, 10.100.10.67, 0) 1(7698) INFO: <script>: hereeeeeeeeeee 1(7698) DEBUG: tm [t_reply.c:1788]: relay_reply(): branch=1, save=0, relay=-1 icode=0 1(7698) DEBUG: <core> [core/receive.c:362]: receive_msg(): reply-route executed in: 188 usec 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 1(7698) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 1(7698) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/404) [[SIP/2.0 180 Ringing 0D 0A Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKdaff.8f25665e8c867e73b07da3cb]] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 1(7698) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <180> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <Ringing> 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKdaff.8f25665e8c867e73b07da3cb1f702171.2>; state=9 1(7698) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-8173-1-0>; state=16 1(7698) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 1(7698) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 1(7698) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=3 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 1(7698) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069>] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 1(7698) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - reply - call-id: [1-8173(a)10.100.10.67] - cseq: [1 INVITE] 1(7698) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7fe2c208a768) id=6 global id=5 T start=0xffffffffffffffff 1(7698) DEBUG: tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 65453 label 0 branch 2 1(7698) DEBUG: tm [t_lookup.c:951]: t_reply_matching(): reply (0x7fe2c208a768) matched an active transaction (T=0x7fe2bd0c76d8)! 1(7698) DEBUG: tm [t_lookup.c:1088]: t_check_msg(): msg (0x7fe2c208a768) id=6 global id=6 T end=0x7fe2bd0c76d8 1(7698) DEBUG: tm [t_reply.c:2209]: reply_received(): org. status uas=100, uac[2]=0 local=0 is_invite=1) 1(7698) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=0 1(7698) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 1(7698) INFO: <script>: LAL 1(7698) DEBUG: tm [t_reply.c:1265]: t_should_relay_response(): ->>>>>>>>> T_code=100, new_code=180 1(7698) DEBUG: tm [t_reply.c:1788]: relay_reply(): branch=2, save=0, relay=2 icode=0 1(7698) DEBUG: <core> [core/msg_translator.c:2270]: generate_res_buf_from_sip_res(): old size: 404, new size: 318 1(7698) DEBUG: <core> [core/msg_translator.c:2288]: generate_res_buf_from_sip_res(): copied size: orig:112, new: 26, rest: 292 msg= SIP/2.0 180 Ringing Via: SIP/2.0/UDP 10.100.10.67:5061;branch=z9hG4bK-8173-1-0 From: "BTS" <sip:34917019888@10.100.10.67:5061>;tag=8173SIPpTag001 To: "Javi" <sip:34606147628@10.100.10.67:5069>;tag=3 Call-ID: 1-8173(a)10.100.10.67 CSeq: 1 INVITE Contact: <sip:10.100.10.67:5060;transport=UDP> Content-Length: 0 1(7698) DEBUG: <core> [core/receive.c:362]: receive_msg(): reply-route executed in: 93 usec 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 1(7698) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 1(7698) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/595) [[SIP/2.0 200 OK 0D 0A Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKdaff.8f25665e8c867e73b07da3cb1f702]] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 1(7698) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <200> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <OK> 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKdaff.8f25665e8c867e73b07da3cb1f702171.2>; state=9 1(7698) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-8173-1-0>; state=16 1(7698) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 1(7698) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 1(7698) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=3 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 1(7698) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Javi" <sip:34606147628@10.100.10.67:5069>] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <INVITE> 1(7698) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - reply - call-id: [1-8173(a)10.100.10.67] - cseq: [1 INVITE] 1(7698) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7fe2c208a768) id=7 global id=6 T start=0xffffffffffffffff 1(7698) DEBUG: tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 65453 label 0 branch 2 1(7698) DEBUG: tm [t_lookup.c:951]: t_reply_matching(): reply (0x7fe2c208a768) matched an active transaction (T=0x7fe2bd0c76d8)! 1(7698) DEBUG: tm [t_lookup.c:1088]: t_check_msg(): msg (0x7fe2c208a768) id=7 global id=7 T end=0x7fe2bd0c76d8 1(7698) DEBUG: tm [t_reply.c:2209]: reply_received(): org. status uas=180, uac[2]=180 local=0 is_invite=1) 1(7698) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=161 1(7698) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 1(7698) INFO: <script>: LAL v=0 o=user1 53655765 2353687637 IN IP4 10.100.10.67 s=- c=IN IP4 10.100.10.67 t=0 0 m=audio 6000 RTP/AVP 0 18 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 1(7698) DEBUG: tm [t_reply.c:1265]: t_should_relay_response(): ->>>>>>>>> T_code=180, new_code=200 1(7698) DEBUG: tm [t_reply.c:1788]: relay_reply(): branch=2, save=0, relay=2 icode=0 1(7698) DEBUG: <core> [core/msg_translator.c:2270]: generate_res_buf_from_sip_res(): old size: 595, new size: 509 1(7698) DEBUG: <core> [core/msg_translator.c:2288]: generate_res_buf_from_sip_res(): copied size: orig:107, new: 21, rest: 488 msg= SIP/2.0 200 OK Via: SIP/2.0/UDP 10.100.10.67:5061;branch=z9hG4bK-8173-1-0 From: "BTS" <sip:34917019888@10.100.10.67:5061>;tag=8173SIPpTag001 To: "Javi" <sip:34606147628@10.100.10.67:5069>;tag=3 Call-ID: 1-8173(a)10.100.10.67 CSeq: 1 INVITE Contact: <sip:10.100.10.67:5060;transport=UDP> Content-Type: application/sdp Content-Length: 161 v=0 o=user1 53655765 2353687637 IN IP4 10.100.10.67 s=- c=IN IP4 10.100.10.67 t=0 0 m=audio 6000 RTP/AVP 0 18 a=rtpmap:0 PCMU/8000 a=rtpmap:18 G729/8000 1(7698) DEBUG: tm [t_reply.c:1631]: cleanup_uac_timers(): RETR/FR timers reset 1(7698) DEBUG: <core> [core/receive.c:362]: receive_msg(): reply-route executed in: 185 usec 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 1(7698) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 1(7698) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/323) [[ACK sip:34606147628@10.100.10.67:5060 SIP/2.0 0D 0A Via: SIP/2.0/UDP 10.100.10.67:5061;branch=z9hG4bK-817]] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:604]: parse_msg(): SIP Request: 1(7698) DEBUG: <core> [core/parser/msg_parser.c:606]: parse_msg(): method: <ACK> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:608]: parse_msg(): uri: <sip:34606147628@10.100.10.67:5060> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:610]: parse_msg(): version: <SIP/2.0> 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-8173-1-0>; state=16 1(7698) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 1(7698) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 1(7698) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=3 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 1(7698) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Test" <sip:34606147628@10.100.10.67:5069>] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <1> <ACK> 1(7698) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - request - call-id: [1-8173(a)10.100.10.67] - cseq: [1 ACK] 1(7698) DEBUG: <core> [core/receive.c:248]: receive_msg(): preparing to run routing scripts... 1(7698) DEBUG: sl [sl_funcs.c:387]: sl_filter_ACK(): too late to be a local ACK! 1(7698) INFO: <script>: hereeeeeeeeeee 1(7698) DEBUG: tm [t_lookup.c:1320]: t_newtran(): msg id=8 , global msg id=7 , T on entrance=0xffffffffffffffff 1(7698) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=0 1(7698) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 1(7698) DEBUG: tm [t_lookup.c:477]: t_lookup_request(): start searching: hash=65453, isACK=1 1(7698) DEBUG: tm [t_lookup.c:435]: matching_3261(): RFC3261 transaction matching failed 1(7698) DEBUG: tm [t_lookup.c:659]: t_lookup_request(): no transaction found 1(7698) DEBUG: tm [t_funcs.c:284]: t_relay_to(): forwarding ACK statelessly 1(7698) DEBUG: <core> [core/md5utils.c:67]: MD5StringArray(): MD5 calculated: 8f25665e8c867e73b07da3cb1f702171 1(7698) DEBUG: <core> [core/msg_translator.c:159]: check_via_address(): (10.100.10.67, 10.100.10.67, 0) 1(7698) DEBUG: <core> [core/forward.c:557]: forward_request(): Sending: ACK sip:34606147628@10.100.10.67:5060 SIP/2.0 Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKdaff.8f25665e8c867e73b07da3cb1f702171.0 Via: SIP/2.0/UDP 10.100.10.67:5061;branch=z9hG4bK-8173-1-0 From: "BTS" <sip:34917019888@10.100.10.67:5061>;tag=8173SIPpTag001 To: "Test" <sip:34606147628@10.100.10.67:5069>;tag=3 Call-ID: 1-8173(a)10.100.10.67 CSeq: 1 ACK Max-Forwards: 70 Subject: 1 Content-Length: 0 . 1(7698) DEBUG: <core> [core/forward.c:559]: forward_request(): orig. len=323, new_len=414, proto=1 1(7698) INFO: <script>: hereeeeeeeeeee 1(7698) DEBUG: <core> [core/receive.c:289]: receive_msg(): request-route executed in: 109 usec 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 1(7698) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 1(7698) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/338) [[BYE sip:34606147628@10.100.10.67:5060 SIP/2.0 0D 0A Via: SIP/2.0/UDP 10.100.10.67:5061;branch=z9hG4bK-817]] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:604]: parse_msg(): SIP Request: 1(7698) DEBUG: <core> [core/parser/msg_parser.c:606]: parse_msg(): method: <BYE> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:608]: parse_msg(): uri: <sip:34606147628@10.100.10.67:5060> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:610]: parse_msg(): version: <SIP/2.0> 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-8173-1-8>; state=16 1(7698) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 1(7698) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 1(7698) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=3 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 1(7698) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Test" <sip:34606147628@10.100.10.67:5069>] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <2> <BYE> 1(7698) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - request - call-id: [1-8173(a)10.100.10.67] - cseq: [2 BYE] 1(7698) DEBUG: <core> [core/receive.c:248]: receive_msg(): preparing to run routing scripts... 1(7698) INFO: <script>: hereeeeeeeeeee 1(7698) DEBUG: tm [t_lookup.c:1320]: t_newtran(): msg id=9 , global msg id=8 , T on entrance=(nil) 1(7698) DEBUG: <core> [core/parser/msg_parser.c:183]: get_hdr_field(): content_length=0 1(7698) DEBUG: <core> [core/parser/msg_parser.c:89]: get_hdr_field(): found end of header 1(7698) DEBUG: tm [t_lookup.c:477]: t_lookup_request(): start searching: hash=65450, isACK=0 1(7698) DEBUG: tm [t_lookup.c:435]: matching_3261(): RFC3261 transaction matching failed 1(7698) DEBUG: tm [t_lookup.c:659]: t_lookup_request(): no transaction found 1(7698) DEBUG: <core> [core/md5utils.c:67]: MD5StringArray(): MD5 calculated: 72541dabc2c0991bc1a987a58afe468a 1(7698) INFO: <script>: LEL 1(7698) DEBUG: <core> [core/msg_translator.c:159]: check_via_address(): (10.100.10.67, 10.100.10.67, 0) 1(7698) INFO: <script>: hereeeeeeeeeee 1(7698) DEBUG: tm [t_funcs.c:372]: t_relay_to(): new transaction forwarded 1(7698) DEBUG: <core> [core/receive.c:289]: receive_msg(): request-route executed in: 223 usec 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 1(7698) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 1(7698) DEBUG: <core> [core/udp_server.c:492]: udp_rcv_loop(): received on udp socket: (106/100/396) [[SIP/2.0 200 OK 0D 0A Via: SIP/2.0/UDP 52.88.180.226:5069;branch=z9hG4bKaaff.72541dabc2c0991bc1a987a58afe4]] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:614]: parse_msg(): SIP Reply (status): 1(7698) DEBUG: <core> [core/parser/msg_parser.c:616]: parse_msg(): version: <SIP/2.0> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:618]: parse_msg(): status: <200> 1(7698) DEBUG: <core> [core/parser/msg_parser.c:620]: parse_msg(): reason: <OK> 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bKaaff.72541dabc2c0991bc1a987a58afe468a.0>; state=9 1(7698) DEBUG: <core> [core/parser/parse_via.c:2681]: parse_via(): parsing via: next via 1(7698) DEBUG: <core> [core/parser/parse_via.c:1303]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK-8173-1-8>; state=16 1(7698) DEBUG: <core> [core/parser/parse_via.c:2639]: parse_via(): end of header reached, state=5 1(7698) DEBUG: <core> [core/parser/msg_parser.c:492]: parse_headers(): Via found, flags=2 1(7698) DEBUG: <core> [core/parser/msg_parser.c:494]: parse_headers(): this is the first via 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:185]: parse_to_param(): add param: tag=3 1(7698) DEBUG: <core> [core/parser/parse_addr_spec.c:864]: parse_addr_spec(): end of header reached, state=29 1(7698) DEBUG: <core> [core/parser/msg_parser.c:171]: get_hdr_field(): <To> [50]; uri=[sip:34606147628@10.100.10.67:5069] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:172]: get_hdr_field(): to body ["Test" <sip:34606147628@10.100.10.67:5069>] 1(7698) DEBUG: <core> [core/parser/msg_parser.c:152]: get_hdr_field(): cseq <CSeq>: <2> <BYE> 1(7698) DEBUG: <core> [core/receive.c:205]: receive_msg(): --- received sip message - reply - call-id: [1-8173(a)10.100.10.67] - cseq: [2 BYE] 1(7698) DEBUG: tm [t_lookup.c:1019]: t_check_msg(): msg (0x7fe2c208a768) id=10 global id=9 T start=0xffffffffffffffff 1(7698) DEBUG: tm [t_lookup.c:897]: t_reply_matching(): t_reply_matching: hash 65450 label 0 branch 0 1(7698) DEBUG: tm [t_lookup.c:951]: t_reply_matching(): reply (0x7fe2c208a768) matched an active transaction (T=0x7fe2bd0ccd40)! 1(7698) DEBUG: tm [t_lookup.c:1088]: t_check_msg(): msg (0x7fe2c208a768) id=10 global id=10 T end=0x7fe2bd0ccd40 1(7698) DEBUG: tm [t_reply.c:2209]: reply_received(): org. status uas=0, uac[0]=0 local=0 is_invite=0) 1(7698) DEBUG: tm [t_reply.c:1265]: t_should_relay_response(): ->>>>>>>>> T_code=0, new_code=200 1(7698) DEBUG: tm [t_reply.c:1788]: relay_reply(): branch=0, save=0, relay=0 icode=0 1(7698) DEBUG: <core> [core/msg_translator.c:2270]: generate_res_buf_from_sip_res(): old size: 396, new size: 310 1(7698) DEBUG: <core> [core/msg_translator.c:2288]: generate_res_buf_from_sip_res(): copied size: orig:107, new: 21, rest: 289 msg= SIP/2.0 200 OK Via: SIP/2.0/UDP 10.100.10.67:5061;branch=z9hG4bK-8173-1-8 From: "BTS" <sip:34917019888@10.100.10.67:5061>;tag=8173SIPpTag001 To: "Test" <sip:34606147628@10.100.10.67:5069>;tag=3 Call-ID: 1-8173(a)10.100.10.67 CSeq: 2 BYE Contact: <sip:10.100.10.67:5060;transport=UDP> Content-Length: 0 1(7698) DEBUG: tm [t_reply.c:1631]: cleanup_uac_timers(): RETR/FR timers reset 1(7698) DEBUG: <core> [core/receive.c:362]: receive_msg(): reply-route executed in: 74 usec 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/usr_avp.c:636]: destroy_avp_list(): destroying list (nil) 1(7698) DEBUG: <core> [core/xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) 1(7698) DEBUG: <core> [core/receive.c:378]: receive_msg(): cleaning up 3(7700) DEBUG: tm [h_table.c:129]: free_cell_helper(): freeing transaction 0x7fe2bd0c76d8 from timer.c:654 3(7700) DEBUG: tm [h_table.c:129]: free_cell_helper(): freeing transaction 0x7fe2bd0ccd40 from timer.c:654

3 5

dlflags interface deprecated
by AL S 13 Nov '18

13 Nov '18

Hi, We are running the old release of Kamailio 3.3.7 and getting the following notice log: kamailio: NOTICE: <core> [sr_module.c:627]: /usr/local/lib64/kamailio/modules_k/perl.so: exports dlflags interface is deprecated and it will not be supported in newer versions; consider using mod_register() instead Is there a way to fix this issue on the same Kamailio3.3.7 code? Thanks, AL

3 2

Execution Sequence of the Request_Route
by Abdulaziz Alghosh 13 Nov '18

13 Nov '18

Hello, I migrated from Kamailio 3.0.3 to Kamailio 5.1.4. and have two questions about the execution sequence of the Request_Route. The following condition trys to authenticate the first INVITE or REGISTER request which normally does not have the Authorization Header: route (auth) .. .. .. route[auth]{ if ( !proxy_authorize("myrealm", "subscriber") ) { proxy_challenge("myrealm", "0"); sl_reply_error(); exit; }; return; } For sure the Return Code of "proxy_authorize" will not be one (1) at the beginneing, so the proxy_challenge() will generate the "407 Proxy Authentication Required" request and the agent will send the INVITE or the REGISTER again with the Authorization-Header and the call or the registration attempt succeeds. During my observation to the new returned codes (values) of both proxy_authorize() and proxy_challenge() in Kamailio 5.1.4, I noticed the following differnet execution sequence of this "Request_Route". at Kamailio 3.0.3, and exactly after the proxy_challenge("myrealm", "0") command was executed, no more commands were excuted as if it jumped out of the if statement, and the proxy was wating for the new INVITE or REGISTER. Hence the sl_reply_error() did not send any error reply. I wrote several logging commad before and after the proxy_challenge("myrealm", "0"), so I am pretty sure that the proxy_challenge("myrealm", "0") is last excuted command to be excuted here. at Kamailio 5.1.4, the behaviour was more logical and the proxy executes commands which come under the proxy_challenge("myrealm", "0") like logging commands or sl_reply_error() which generates usually the error reply " 500 I'm terribly sorry, server error occurred". My first question is: May somebody explain this different behavior? My second Question: assume that the agent will send a wrong credentials and response, does the proxy_challenge("myrealm", "0") function terminate this dialouge with 401 Unauthorized Error or I must add the following "if condition" afterwards: if ( !proxy_authorize("myrealm", "subscriber") ) { proxy_challenge("myrealm", "0"); if (!$rc){ sl_reply_error(); '#### or I will be more specific sl_send_reply (code, reason) } exit; }; Thanks and best regards Abdulaziz Alghosh

2 1

Redirects - are q values required to implement serial forking?
by Mike Montgomery 12 Nov '18

12 Nov '18

We have a situation where we get a redirect from a carrier with a list of carriers to send the transaction to in the contact header. None of the carriers in the contact header have q values assigned. We have implemented our redirect handling logic using the UAC_REDIRECT module (get_redirects()) with help from TM module (t-load_contacts(), t_next_contact()). (failure_route code is at bottom of this note) We find that when we receive a contact header with q values, we can launch requests serially using t_next_contact() and individually work through the contact list until we get a positive response. When we get a redirect with no q values in the contact header we find that all contacts get loaded and launched in parallel. Although not stated in the documentation, it appears that in order to implement serial contact redirect handling, q values must be present in the contact header. Based on this assumption, and knowing that the redirecting carrier cannot include q values, we have attempted to modify the contact header and find that we are unable to add q values to the contact header. We have attempted without success to use remove_hf("Contact”) followed by append_hf("Contact: $(avp(contact)) \r\n”); where $(avp(contact)) is the avp where we have rewritten the contact header to include q values. Any guidance on how to handle this issue is appreciated. _________________________________________________________- Our failure route code: if (t_check_status("3[0-9][0-9]")) { xlog("L_INFO", "----> REDIRECT Contact Header --> $T_rpl($ct) --- Method $rm --- From $T_req($fu) --- To $T_req($tu) --- Destination $T_req($du) \n"); get_redirects("*:*"); if (!t_load_contacts()) { xlog("L_INFO", "-t_load_contacts() FAILED /n"); }; xlog("L_INFO", "####->LOAD CONTACT LIST $xavp(tm_contacts[0]=>uri) \n"); if (t_next_contacts()) { xlog("L_INFO", "-t_next_contact() loaded successfully /n"); xlog("L_INFO", "####-> NEXT CONTACT LIST $xavp(tm_contacts[0]=>uri) \n"); }; t_on_failure("serial"); if(t_relay()){ xlog("L_INFO","----->Relayed in MANAGE_FAILURE --- Method $rm --- Contact Header $ct \n"); }; exit; } else { xlog("L_INFO","-----> NO REDIRECT --- Method $rm --- Contact Header $ct \n"); exit; } failure_route["serial"] { xlog ("L_INFO", "Entered failure_route(serial) /n"); if (t_check_status("3[0-9][0-9]")) { xlog("L_INFO", "----> DOUBLE REDIRECT Contact Header --> $T_rpl($ct) --- Method $rm --- From $T_req($fu) --- To $T_req($tu) --- Destination $T_req($du) \n"); $xavp(tm_contacts[*]) = $null; xlog("L_INFO", "XXX-> tm_contacts reset to Null $xavp(tm_contacts[0]=>uri)\n"); get_redirects("*:*"); if (!t_load_contacts()) { xlog("L_INFO", "-t_load_contacts() FAILED /n"); }; xlog("L_INFO", "####-> LOAD 2 CONTACT LIST $xavp(tm_contacts[0]=>uri) \n"); } if (!t_next_contacts()) { exit; } xlog("L_INFO", "-t_next_contact() loaded successfully /n"); xlog("L_INFO", "####-> NEXT CONTACT LIST $xavp(tm_contacts[0]=>uri) \n"); t_on_failure("serial"); if(t_relay()){ xlog("L_INFO","----->Relayed in failure_route(serial) --- Method $rm --- Contact Header $ct \n"); }; } Best Regards, Mike Montgomery Principal, Trusted Technical Services, Inc. o - 919 924 4703 x3000 m - 919 539 6133

2 1

Adding Perl Module to kamailio-5.1.6
by AL S 12 Nov '18

12 Nov '18

I am trying to install Perl module on Ubuntu 18.04 / Kamailio kamailio-5.1.6 and getting the following response: $ sudo apt-get install kamailio-perl-modules Reading package lists... Done Building dependency tree Reading state information... Done kamailio-perl-modules is already the newest version (5.1.2-1ubuntu2). You might want to run 'apt --fix-broken install' to correct these. The following packages have unmet dependencies: kamailio-perl-modules : Depends: kamailio (= 5.1.2-1ubuntu2) but it is not installable E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution). Is there a better way to add perl module? PS: libperl-dev already installed. Thanks, AL

2 1

siptrace module doesn't close db connections
by Roman Dissauer 12 Nov '18

12 Nov '18

Hi, it seems that siptrace module doesn’t close db connections. I’m on Kamailio 5.1.4 from official debian stretch repository with postgresql db module enabled. siptrace config: modparam("siptrace", "db_url", DBURL) modparam("siptrace", "duplicate_uri", "sip:193.32.51.189:9060") modparam("siptrace", "hep_mode_on", 1) modparam("siptrace", "hep_version", 3) modparam("siptrace", "hep_capture_id", 1001) modparam("siptrace", "trace_mode", 1) Here you can see the open connections from the kamailio host: # select client_addr, state, query from pg_stat_activity where client_addr = '10.23.101.61'; client_addr | state | query --------------+-------+---------------------------------------------------------------- 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' 10.23.101.61 | idle | select table_version from version where table_name='sip_trace' (31 Zeilen) another example, other installation with same kamailio version 5.1.4: # select client_addr, state, query from pg_stat_activity where client_addr = '10.23.102.1'; client_addr | state | query -------------+-------+---------------------------------------------------------------- 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' 10.23.102.1 | idle | select table_version from version where table_name='sip_trace' (39 Zeilen) Thanks Roman

2 2

Single session start
by José Antonio Gutiérrez Delgado 12 Nov '18

12 Nov '18

Hi, I would like to know if it is possible to make the last register of a user the active register and if possible the only one. I'm with an Android application and sometimes I can not deregister properly before the new registration, for example when the network changes, so there are times when the hanging signals do not work correctly when there is more than one register for a user. Is it possible to avoid that there is more than one register for a user? Is it possible to configure the last register to delete the previous ones or to be a single register? Thanks in advance and I await your answers. -- José Antonio Gutiérrez Delgado Responsable técnico Oficina: (+34) 923040031 <http://www.arsoft-company.com/> *Este mensaje se dirige exclusivamente a su destinatario/s y puede contener información privilegiada o confidencial. Si no es vd. el destinatario indicado, queda notificado de que la utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.* *Antes de imprimir, piensa si es necesario. Cuidar el medioambiente es tarea de todos.*

3 2

Custom authentication
by João Sávio 12 Nov '18

12 Nov '18

Hello! I was reading the documentation of Kamailio, And, although there are some authentication modules, I couldn't find a way to implement a custom authentication for SIP Register. Something that allows me, for example, to call a web server and returns if the user is authenticated, or the user data. Am I missing anything? Do you know if it's possible to do this using another way? Thanks João

2 2

high availability and load balancing
by eyas barhouk 10 Nov '18

10 Nov '18

hello dears, i'm using kamailio 5.1 as IMS , and i have the following servers: * p-cscf * i-cscf-1 ,icscf-2 * s-cscf-1,scscf-2 i need to do high availability and load balancing between my servers , but i have some questions like do i have to use keepalived or dispatcher module and what the benefits of each one of them ,and on load balancing method should i do it for the register requests or only for invite requests or just for every thing ?? if any one has an idea or any thing to guide me i will be thankful thanks in advance and regards

3 3

Client Registration and Call over Kamailio
by serkan celik 09 Nov '18

09 Nov '18

Hi all, I am using Kamailio as a proxy in front of a 3rd part Open IMS (Not IMS modules in kamailio). I have defined Kamailio as an outbound proxy in Soft clients(I have configured IMS users info in Soft Clients). When I send register from client to IMS, Register message is sent to IMS over Kamailio. Kamailio forwards this received Register to the 3rd party IMS. Finally the client is registered into IMS over Kamailio. However when I try to make a call from registered users (both registered over Kamailio), IMS sends 403 Forbidden - "Not Registered! You must register first with a S-CSCF" to Kamailio. When I debugged the issue I found the reason why IMS sends 403. When IMS receives an Invite message from Kamailio it checks whether source IP which Invite is sent registered or not. As I make registration over Kamailio without changing contact header, IMS registers the user with the contact IP (which is the client IP). So to make a call from Soft client (IMS users) over Kamailio I also need to register Kamailio source IP as well.To deal with the issue I have changed the contact address of Register message coming from Soft client with Kamailio IP on Kamailio. Then IMS registered Kamailio IP as a contact when registering IMS user. But this time when I make a call from Soft client over Kamailio, IMS sends Termination Invite to Kamailio. So to finalize the call Kamailio has to route this termination Invite to the terminating IMS user . Is there any better approach to overcome this issue. Which is the better approach to use Kamailio in front of IMS. I want to both register and make a call from Soft clients over Kamailio to the IMS. Regards, Serkan CELIK

3 5

systemd kamailio.service - RFC Wants=network-online.target
by Kevin Olbrich 08 Nov '18

08 Nov '18

Hi! The systemd kamailio.service file for debian (in my case, it's stretch) has the following unit options set: [Unit] > Description=Kamailio (OpenSER) - the Open Source SIP Server > After=network.target It would be better to change this to: [Unit] > Description=Kamailio (OpenSER) - the Open Source SIP Server > Wants=network-online.target > After=network-online.target Why? With network.target the service starts as soon as the network setup is started, not explicitly after configuring (=IP) it [1]. This creates a race condition on very fast hardware like mine (booting incl. all services takes 10s). Even with static IPs, kamailio often fails directly at boot because eth1 (connection to DB cluster) is not up. [I have never met this problem on systems which ran on HDDs.] Setting "network-online.target" as Wants + After makes sure, Kamailio is started after all interfaces are ready to serve. Units that strictly require a configured network connection should pull in > network-online.target (via a Wants= type dependency) and order themselves > after it. This target unit is intended to pull in a service that delays > further execution until the network is sufficiently set up. What precisely > this requires is left to the implementation of the network managing service. > Perfect example for this is the Shorewall package (firewall solution): [Unit] > Description=Shorewall IPv4 firewall > Wants=network-online.target > After=network-online.target > Conflicts=iptables.service firewalld.service RFC Kind regards Kevin [1] https://www.freedesktop.org/software/systemd/man/systemd.special.html

3 6

cfg_lock_helper(): lock set not initialized
by Kjeld Flarup 08 Nov '18

08 Nov '18

Hi What does this error actually mean? I get it with 5.1.4 Nov 6 13:27:02 scantronpbx /usr/sbin/kamailio[2149]: ERROR: cfgutils [cfgutils.c:708]: cfg_lock_helper(): lock set not initialized (attempt to do op: 1 on: u1) -- -------------------- Med Liberalistiske Hilsner ---------------------- Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49 Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

2 1

Phone does not set "Expire-header" but "Contact expire", immediately expires
by Kevin Olbrich 07 Nov '18

07 Nov '18

Hi! I have a phone (Mitel 6930) that does not send an Expire-header but "expire" in Contact during REGISTER: Session Initiation Protocol (REGISTER) > Request-Line: REGISTER sip:pbx.example.com SIP/2.0 > Message Header > Via: SIP/2.0/TLS 192.168.6.16:5061;branch=xxxxxxxxxxxxxxxx;rport > Route: <sip:pbx.example.com;lr=lr;transport=tls> > Max-Forwards: 70 > From: "Example" <sip:121212_6666@pbx.example.com>;tag=b0cec92c3e > To: "Example" <sip:121212_6666@pbx.example.com> > Call-ID: aaaaaaaaaaaaaaaaa > CSeq: 1190442896 REGISTER > Accept-Language: de > Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, > PRACK, SUBSCRIBE, INFO, PUBLISH > Allow-Events: talk, hold, conference, LocalModeStatus > Contact: "Example" <sip:121212_6666@192.0.2.1:62336 > >;+sip.instance="<urn:uuid:00000000-0000-1000-8000-08000FB888F5>";expires=300 > Supported: path, gruu > User-Agent: Mitel 6930/5.0.0.2041 > Aastra-Line: 1 > Aastra-Mac: AAAAAAAAAAAA > Content-Length: 0 This results in successful register, kamailio forwards REGISTER to asterisk (endpoint registered) and immediatly kamailio sends a new REGISTER with Expire set to 0 to asterisk: Session Initiation Protocol (REGISTER) > Request-Line: REGISTER sip:192.168.99.112:5060 SIP/2.0 > Message Header > Via: SIP/2.0/UDP 192.168.99.111:5060 > ;branch=z9hG4bK9f9e.599cf243000000000000000000000000.0 > To: <sip:121212_6666@192.168.99.112> > From: <sip:121212_6666@192.168.99.112 > >;tag=7e4f6993bfbf831f6b016fea6683cdca-b98a > CSeq: 10 REGISTER > Call-ID: 2bc5fd1061b31723-1350(a)192.168.99.111 > Max-Forwards: 70 > Content-Length: 0 > User-Agent: kamailio (5.1.6 (x86_64/linux)) > Contact: <sip:121212_6666@192.168.99.111:5060> > Expires: 0 The phone is then unregistered - the phone also shows "no service". It looks like Kamailio generates this message on it's own (and I don't know why). I am still learning to implement kamailio as proxy. Reading the docs, I would expect Kamailio to automatically eval the correct parameter: > If the processed message contains neither Expires HFs nor expires contact > parameters, this value will be used for newly created usrloc records. [1] What did I miss? Phones which use the Expire-header are working fine. Kind regards Kevin [1] default_expires - http://www.kamailio.org/docs/modules/5.2.x/modules/registrar.html

3 10

busy lamp field
by Kevin Olbrich 06 Nov '18

06 Nov '18

Hi! Can someone share his kamailio.cfg with working busy lamp field in a kamailio-as-proxy scenario? My config is based on the example shipped with 5.1.x and asterisk as the backend. Calling works fine but PUBLISH / SUBSCRIBE is handled by kamailio itself. I am not sure but this might be the part where I should relay the request to asterisk(?): #!ifdef WITH_PRESENCE > if (!t_newtran()) { > sl_reply_error(); > exit; > } > if(is_method("PUBLISH")) { > handle_publish(); > t_release(); > } else if(is_method("SUBSCRIBE")) { > handle_subscribe(); > t_release(); > } > exit; > #!endif Currently the lights are "broken", some phones show them on, some off. Kind regards Kevin

2 1

Kamailio SQL error
by Marcos Pytel 06 Nov '18

06 Nov '18

Hello team! Im using kamailio in sipwise! I get this errors: Nov 5 11:51:34 sipwise proxy[1943]: ERROR: <core> [db_query.c:235]: db_do_insert_cmd(): error while submitting query Nov 5 11:51:34 sipwise proxy[1943]: ERROR: presence [subscribe.c:2514]: update_db_subs_timer(): unsuccessful sql insert Nov 5 11:51:34 sipwise proxy[1943]: ERROR: db_mysql [km_dbase.c:127]: db_mysql_submit_query(): driver error on query: Duplicate entry '6c23f96-0001-0003-0030(a)10.7.255.250-f3067022b00c564156251ba2f28f' for key 'active_watchers_idx' (1062) How can I fix it? Thank you! Marcos.

2 2

db_mongodb_get_columns(): field [username] not found in result iterator
by Denys Pozniak 06 Nov '18

06 Nov '18

Hello! I want to keep user location in mongodb, but Kamailio does not start well. Configuration: loadmodule "usrloc.so" loadmodule "db_mongodb.so" modparam("usrloc", "db_insert_null", 1) modparam("usrloc", "db_url", "mongodb://mongodb.test/kamailio") modparam("usrloc", "db_mode", 2) modparam("usrloc", "timer_interval", 30) modparam("usrloc", "desc_time_order", 1) Mongodb: rs0:PRIMARY> use kamailio switched to db kamailio rs0:PRIMARY> db.location.find() { "_id" : ObjectId("5be024d6b9d8febf4ae19681"), "name" : "location", "version" : 9, "columns" : { "id" : { "type" : "int", "default" : null, "null" : false }, "ruid" : { "type" : "string", "default" : "", "null" : false }, "username" : { "type" : "string", "default" : "", "null" : false }, "domain" : { "type" : "string", "default" : null, "null" : true }, "contact" : { "type" : "string", "default" : "", "null" : false }, "received" : { "type" : "string", "default" : null, "null" : true }, "path" : { "type" : "string", "default" : null, "null" : true }, "expires" : { "type" : "datetime", "default" : "2030-05-28 21:32:15", "null" : false }, "q" : { "type" : "double", "default" : 1, "null" : false }, "callid" : { "type" : "string", "default" : "Default-Call-ID", "null" : false }, "cseq" : { "type" : "int", "default" : 1, "null" : false }, "last_modified" : { "type" : "datetime", "default" : "2000-01-01 00:00:01", "null" : false }, "flags" : { "type" : "int", "default" : 0, "null" : false }, "cflags" : { "type" : "int", "default" : 0, "null" : false }, "user_agent" : { "type" : "string", "default" : "", "null" : false }, "socket" : { "type" : "string", "default" : null, "null" : true }, "methods" : { "type" : "int", "default" : null, "null" : true }, "instance" : { "type" : "string", "default" : null, "null" : true }, "reg_id" : { "type" : "int", "default" : 0, "null" : false }, "server_id" : { "type" : "int", "default" : 0, "null" : false }, "connection_id" : { "type" : "int", "default" : 0, "null" : false }, "keepalive" : { "type" : "int", "default" : 0, "null" : false }, "partition" : { "type" : "int", "default" : 0, "null" : false } } } { "_id" : ObjectId("5be02a77175610be86a1a589"), "username" : "dummy_user" } Syslog: Nov 5 12:51:01 dev-rtpengine /usr/sbin/kamailio[21543]: ERROR: db_mongodb [mongodb_dbase.c:416]: db_mongodb_get_columns(): field [username] not found in result iterator Nov 5 12:51:01 dev-rtpengine /usr/sbin/kamailio[21543]: ERROR: db_mongodb [mongodb_dbase.c:815]: db_mongodb_store_result(): failed to set the columns Nov 5 12:51:01 dev-rtpengine /usr/sbin/kamailio[21543]: ERROR: db_mongodb [mongodb_dbase.c:1018]: db_mongodb_query(): failed to store result Nov 5 12:51:01 dev-rtpengine /usr/sbin/kamailio[21543]: ERROR: db_mongodb [mongodb_dbase.c:1027]: db_mongodb_query(): failed to do the query Nov 5 12:51:01 dev-rtpengine /usr/sbin/kamailio[21543]: ERROR: usrloc [udomain.c:457]: preload_udomain(): db_query failed Nov 5 12:51:01 dev-rtpengine /usr/sbin/kamailio[21543]: ERROR: usrloc [usrloc_mod.c:430]: child_init(): child(1): failed to preload domain 'location' Nov 5 12:51:01 dev-rtpengine /usr/sbin/kamailio[21543]: ERROR: <core> [core/sr_module.c:946]: init_mod_child(): error while initializing module usrloc (/usr/lib64/kamailio/modules/usrloc.so) (idx: 1 rank: 1 desc: [udp receiver child=0 sock=10.10.10.10:5060]) Nov 5 12:51:01 dev-rtpengine /usr/sbin/kamailio[21543]: ERROR: <core> [core/pt.c:340]: fork_process(): init_child failed for process 1, pid 21543, "udp receiver child=0 sock=10.10.10.10:5060" Nov 5 12:51:01 dev-rtpengine /usr/sbin/kamailio[21543]: CRITICAL: <core> [main.c:1607]: main_loop(): Cannot fork 2018-11-05T13:07:19.117+0100 D COMMAND [conn367] run command kamailio.$cmd { find: "version", filter: { table_name: "location" }, projection: { table_version: 1 } } 2018-11-05T13:07:19.118+0100 I COMMAND [conn367] command kamailio.version command: find { find: "version", filter: { table_name: "location" }, projection: { table_version: 1 } } planSummary: COLLSCAN keysExamined:0 docsExamined:2 cursorExhausted:1 numYields:0 nreturned:1 reslen:148 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } protocol:op_query 0ms 2018-11-05T13:07:19.118+0100 D COMMAND [conn367] run command kamailio.$cmd { find: "location", filter: { username: "dummy_user" }, projection: { username: 1 } } 2018-11-05T13:07:19.119+0100 I COMMAND [conn367] command kamailio.location command: find { find: "location", filter: { username: "dummy_user" }, projection: { username: 1 } } planSummary: COLLSCAN keysExamined:0 docsExamined:2 cursorExhausted:1 numYields:0 nreturned:1 reslen:155 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } protocol:op_query 0ms 2018-11-05T13:07:19.178+0100 D COMMAND [conn368] run command kamailio.$cmd { find: "location", filter: {}, projection: { username: 1, contact: 1, expires: 1, q: 1, callid: 1, cseq: 1, flags: 1, cflags: 1, user_agent: 1, received: 1, path: 1, socket: 1, methods: 1, last_modified: 1, ruid: 1, instance: 1, reg_id: 1, server_id: 1, connection_id: 1, keepalive: 1 } } 2018-11-05T13:07:19.179+0100 I COMMAND [conn368] command kamailio.location command: find { find: "location", filter: {}, projection: { username: 1, contact: 1, expires: 1, q: 1, callid: 1, cseq: 1, flags: 1, cflags: 1, user_agent: 1, received: 1, path: 1, socket: 1, methods: 1, last_modified: 1, ruid: 1, instance: 1, reg_id: 1, server_id: 1, connection_id: 1, keepalive: 1 } } planSummary: COLLSCAN keysExamined:0 docsExamined:2 cursorExhausted:1 numYields:0 nreturned:2 reslen:180 locks:{ Global: { acquireCount: { r: 2 } }, Database: { acquireCount: { r: 1 } }, Collection: { acquireCount: { r: 1 } } } protocol:op_query 0ms [root@dev-rtpengine kamailio]# kamailio -v version: kamailio 5.1.6 (x86_64/linux) 7d1964 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: 7d1964 compiled on 11:10:15 Nov 4 2018 with gcc 4.8.5 -- BR, Denys Pozniak

2 5

Fwd: Fw: kamailio5.0.0 support presence
by chaos wu 06 Nov '18

06 Nov '18

Hi Kamailio expert, i want to use kamailio to simulate presence server, after receive subscribe, i need kamailio reply 200 OK, and then send out Notify, but now, it just forward the subscribe, don't reply, could you help check my cfg? thanks in advance. BRs

2 1

Development is open for future release v5.3.x series
by Daniel-Constantin Mierla 06 Nov '18

06 Nov '18

Hello, with the creation of branch 5.2 done this morning, the master branch is from now on open for adding new features, to be part of future release series v5.3.x. Any bug fix committed to master that applies to 5.2.x or older stable branches should be backported as usual with git cherry-pick to appropriate branches like 5.2 or 5.1. Expect that v5.2.0 will be released in about 2-3 weeks from now. Based on the workflow used during the past years, the next future release v5.3.0 should be out after another 8-10 months of development, plus 1-2 months of testing, so sometime in the summer or autumn of 2019. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

1 0

Branch 5.2 has been created
by Daniel-Constantin Mierla 06 Nov '18

06 Nov '18

Hello, the branch 5.2 has been created, to be used for releasing v5.2.x series. To check out this branch, the following commands can be used: git clone https://github.com/kamailio/kamailio kamailio-5.2 cd kamailio-5.2 git checkout -b 5.2 origin/5.2 Pushing commits in this branch: git push origin 5.2:5.2 Note that 5.2 is an official stable branch, so only bug fixes, missing kemi exports (discuss on sr-dev if not sure) or improvements to documentation or helper tools can be pushed to this branch. As usual, if there is a bug fixed, commit and push first to master branch and then cherry pick to 5.2 branch. In few weeks, the first release from branch 5.2 will be out, respectively Kamailio v5.2.0. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

1 0

Use of SCTP on public SIP server
by Kevin Olbrich 06 Nov '18

06 Nov '18

Hi! I read about the SCTP module for Kamailio and I am not sure if I should load it (currently I am not). Does this provide any benefit when Kamailio is used as proxy in front of Asterisk? At least from Wikipedia and the kamailio docs, it sounds like I can load it and it does it's magic. The multihomed part caught my attention. Kinds regards Kevin

3 2

How register with STORE_PLAINTEXT_PW=0
by José Antonio Gutiérrez Delgado 05 Nov '18

05 Nov '18

Hello, I recently discovered that the Kamailio database stores the user's password directly. I have found that by changing STORE_PLAINTEXT_PW = 0 in the configuration file, it stops storing the password in the database, but if I make this change I can no longer register the users in Kamailio. How should I register if I do not store the password? Have I missed a step? I have read that it is related to the HA1 field but it has not been clear how to do it. I hope your help. Thank you. -- José Antonio Gutiérrez Delgado Responsable técnico Oficina: (+34) 923040031 <http://www.arsoft-company.com/> *Este mensaje se dirige exclusivamente a su destinatario/s y puede contener información privilegiada o confidencial. Si no es vd. el destinatario indicado, queda notificado de que la utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.* *Antes de imprimir, piensa si es necesario. Cuidar el medioambiente es tarea de todos.*

2 2

Storing in-progress dialogs in database
by jenus＠cyberchaos.nl 05 Nov '18

05 Nov '18

Hi all, I'm testing with the new dlg_db_load_callid function to replicate dialogs to another (standby) kamailio instance on failover. This works fine for calls that are connected. But i'm missing the dialogs in "ringing" state. Looks like dialogs are written to database by the dialog module when we receive the 200OK/ACK for the invite transaction. The result is that the call gets connected on the other kamailio instance but without a dialog. Is it possible to store the early_dialogs that are in rining state in the database? If that is not the case can i still create a dialog when i only receive the 200OK/ACK to the INVITE transaction (INVITE was processed by another instance) since TM is not aware of the INVITE transaction? I also tried to reject the 200OK to the INVITE in the on reply route, but running into the same issue that TM does not know the INVITE transaction. Thanks, Jan

2 1

string in ims_diameter_server
by Iman Mohammadi 04 Nov '18

04 Nov '18

We have a problem putting data to an AVP object. The data type is byte array (:byte[]). If we convert that array to an integer and put it in 'int32' field then the module just gets the first 4 bytes. If we convert it to base64 or hexString and put it in 'string' field then it treats it as a regular string. And any other field beside 'int32' and 'string' will be ignored. So the question is, how we put a byte array inside an AVP and send it to the module so the diameter gets the data as a byte array? Best Regards Iman Mohammadi

1 0

Branching GIT repository for 5.2.x release series
by Daniel-Constantin Mierla 03 Nov '18

03 Nov '18

Hello, if there is no other opinion, I am considering to create git branch 5.2 at the beginning of next week (likely on Monday evening), to be used for 5.2.x release series. >From that moment, the master branch can get new features and the appropriate bug fixes have to be backported to branch 5.2 as well. With this step, the first release in 5.2.x series, respectively v5.2.0, should be out in about 2-3 weeks. Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

2 1

Crash ims_diameter_server
by Iman Mohammadi 03 Nov '18

03 Nov '18

When the below format is sent from rest , kamailio crashes List[{ List[{ List[{ ]} ]} ]} (Json with 3 nested lists), With 2 lists it works properly, When diameter is translated to json with 3 lists by this module it also works properly, Json format is correct too. gdb: gdb) bt full #0 0x00007f5e23c4a11e in diameterserver_add_avp (m=0x0, d=0x7f5e1b5c2240 "", len=12, avp_code=431, flags=64, vendorid=0, data_do=2, func=0x7f5e23c51d6c <__FUNCTION__.20148> "parselist") at avp_helper.c:208 avp = 0x7f5e1b5c3bd0 __FUNCTION__ = "diameterserver_add_avp" #1 0x00007f5e23c4d0c8 in parselist (response=0x0, list=0x7fff9f21a8d0, item=0x11b67d0, level=2) at avp_helper.c:309 i = 1 flags = 64 x = "p\250!\237" avp_list = {head = 0x0, tail = 0x0} avp_list_s = {s = 0x7f5e1b5c2240 "", len = 12} __FUNCTION__ = "parselist" #2 0x00007f5e23c4cffc in parselist (response=0x7f5e1b5c3ab8, list=0x0, item=0x11b6550, level=1) at avp_helper.c:304 subitem = 0x11b67d0 i = 0 flags = 64 x = "\000\000\000" avp_list = {head = 0x0, tail = 0x0} avp_list_s = {s = 0x7fff9f21a8f0 "@\251!\237\377\177", len = 600070897} __FUNCTION__ = "parselist" #3 0x00007f5e23c4db3a in addAVPsfromJSON (response=0x7f5e1b5c3ab8, json=0x7f5e23e53950 <responsejson>) at avp_helper.c:349 subitem = 0x11b6550 i = 4 __FUNCTION__ = "addAVPsfromJSON" root = 0x11b4210 #4 0x00007f5e23c3fbdb in callback_cdp_request (request_in=0x7f5e1b5c19b0, param=0x0) at ims_diameter_server.c:193 fmsg = 0xab7840 <_faked_msg> backup_rt = 1 ctx = {rec_lev = 0, run_flags = 0, last_retcode = 1, jmp_env = {{__jmpbuf = {1, -5713032302318786866, 7971288, 7971288, 140042162528420, 0, -5713032302339758386, 5712822384154044110}, __mask_was_saved = 0, __saved_mask = {__val = { 140735863172072, 127, 0, 140042162532340, 140042389578761, 4222451713, 140042162532340, 140042162532340, 140042162532340, 140042162532340, 140042162532358, 140042162532467, 140042162532340, 140042162532467, 0, 0}}}}} response = 0x7f5e1b5c3ab8 __FUNCTION__ = "callback_cdp_request" #5 0x00007f5e24a705c0 in api_callback (p=0x7f5e1b598f50, msg=0x7f5e1b5c19b0, ptr=0x0) at api_process.c:83 t = 0x7f5e1b598f50 auto_drop = 32767 h = 0x7f5e1b5b3358 ---Type <return> to continue, or q <return> to quit--- x = {type = (unknown: 2669784000), handler = {requestHandler = 0x7f5e23c3eed1 <callback_cdp_request>, responseHandler = 0x7f5e23c3eed1 <callback_cdp_request>}, param = 0x3ee9f21ac10, next = 0x7f5e1b5988b8, prev = 0x19f210069} type = REQUEST_HANDLER rsp = 0x7f5e1b5c19b0 __FUNCTION__ = "api_callback" #6 0x00007f5e24a857d7 in worker_process (id=5) at worker.c:346 t = {p = 0x7f5e1b598f50, msg = 0x7f5e1b5c19b0} cb = 0x7f5e1b59df30 r = 128 __FUNCTION__ = "worker_process" #7 0x00007f5e24a62a8e in diameter_peer_start (blocking=0) at diameter_peer.c:242 pid = 0 k = 5 p = 0x36 __FUNCTION__ = "diameter_peer_start" #8 0x00007f5e24a559bc in cdp_child_init (rank=0) at cdp_mod.c:243 __FUNCTION__ = "cdp_child_init" #9 0x0000000000547e54 in init_mod_child (m=0x7f5e28656fb8, rank=0) at core/sr_module.c:943 __FUNCTION__ = "init_mod_child" #10 0x0000000000547b16 in init_mod_child (m=0x7f5e28657c38, rank=0) at core/sr_module.c:939 __FUNCTION__ = "init_mod_child" #11 0x0000000000547b16 in init_mod_child (m=0x7f5e28658010, rank=0) at core/sr_module.c:939 __FUNCTION__ = "init_mod_child" #12 0x0000000000547b16 in init_mod_child (m=0x7f5e28658790, rank=0) at core/sr_module.c:939 __FUNCTION__ = "init_mod_child" #13 0x0000000000547b16 in init_mod_child (m=0x7f5e28658d68, rank=0) at core/sr_module.c:939 __FUNCTION__ = "init_mod_child" #14 0x00000000005481e6 in init_child (rank=0) at core/sr_module.c:970 No locals. #15 0x00000000004250f5 in main_loop () at main.c:1701 i = 8 pid = 1964 si = 0x0 si_desc = "udp receiver child=7 sock=10.25.5.23:5060\000y\000\000\000\000\000x\333i(^\177\000\000@\264!\237\377\177", '\000' <repeats 18 times>, "`\263!\237\377\177\000\000\347L\340(^\177\000\000\360\260!\237\377\177\000\000\060\000\000\000\060\000\000\000\260\261!\237\377\177\000\000\350\226i(^\177\000" nrprocs = 8 ---Type <return> to continue, or q <return> to quit--- woneinit = 1 __FUNCTION__ = "main_loop" #16 0x000000000042b99b in main (argc=13, argv=0x7fff9f21b448) at main.c:2638 cfg_stream = 0x111c020 c = -1 r = 0 tmp = 0x7fff9f21bf69 "" tmp_len = 32606 port = 693647725 proto = 0 options = 0x74cd90 ":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 = 898203166 rfd = 4 debug_save = 0 debug_flag = 0 dont_fork_cnt = 0 n_lst = 0x7fff9f21b300 p = 0x7fff9f21b4b8 "\207\277!\237\377\177" st = {st_dev = 15, st_ino = 13240, st_nlink = 2, st_mode = 16877, st_uid = 110, st_gid = 116, __pad0 = 0, st_rdev = 0, st_size = 60, st_blksize = 4096, st_blocks = 0, st_atim = {tv_sec = 1540797448, tv_nsec = 544589798}, st_mtim = {tv_sec = 1540797905, tv_nsec = 662909589}, st_ctim = {tv_sec = 1540798045, tv_nsec = 563947001}, __glibc_reserved = {0, 0, 0}} __FUNCTION__ = "main" (gdb) (gdb) Where is problem? Thanks

3 4

Store TLS handshake date from Kamailio to an external DB
by Toffi Bossol 02 Nov '18

02 Nov '18

Dear community, I am new in Kamailio hence the following question: Does any one know how to tell Kamailio to store the TLS session data in an external DB? Many Thanks in advance! BR; Toffi

3 7

Installing rtpengine from RPM on CentOS
by Pan Christensen 02 Nov '18

02 Nov '18

Hello! According to https://github.com/sipwise/rtpengine/blob/master/el/README.el.md , we should be able to install rtpengine from a CentOS repository using yum. We're unable to find the packages. Any suggestions? Pan B. Christensen Developer Phonect AS Mail: pan.christensen(a)phonect.no<mailto:pan.christensen@phonect.no> + 47 41 88 88 00 [mail_footer]

5 5

Parse Header error when send Register to P-CSCF using ims-pcscf
by Hưng Nguyễn Tiến 02 Nov '18

02 Nov '18

Hi, i'm newbie in kamailio, I tried installed ims kamailio from ng-repository packages, Then when I tried to send register to SIP server using SIPp, I received this log [Proxy-CSCF][28505]: ERROR: <core> [core/parser/msg_parser.c:331]: parse_headers(): bad header field [(null)] [Proxy-CSCF][28500]: ERROR: <core> [core/parser/msg_parser.c:331]: parse_headers(): bad header field [(null)] [Proxy-CSCF][28496]: WARNING: <core> [core/receive.c:192]: receive_msg(): parsing relevant headers failed [Proxy-CSCF][28505]: message repeated 2 times: [ WARNING: <core> [core/receive.c:192]: receive_msg(): parsing relevant headers failed] [Proxy-CSCF][28492]: ERROR: <core> [core/parser/msg_parser.c:675]: parse_msg(): ERROR: parse_msg: message=<#002#020#002#021#023�#023��z'��z'#006��[%�#007> Thank you -- Nguyễn Tiến Hưng

2 1

Diversion headers access and message too long error
by Joan Salvatella 01 Nov '18

01 Nov '18

Hello, We are working on a project that's using a Twilio SIP trunk that diverts calls from the PSTN to our cluster that is hosting two active-active Kamailio 5.1 instances that redirect traffic to several Asterisk 15.4 instances. On this setup we are facing 2 issues: - *Diversion headers access: *Currently, Kamailio only supports access to the last diversion header but since we are receiving traffic from Twilio (it sets the last Diversion header) we are unable to see if the caller was diverted to our SIP trunk. Is there a workaround for this? Any external module that would support this use case? - *Message Too Long Error:* Since Twilio uses long URIs to define its resources, the SIP messages being handled by Kamailio are sometimes too big and generate a "Message Too Long error". I have been able to temporarily patch this removing unused headers using remove_hf_re and remove_hf but it still fails from time to time. Is there a way to split the UDP packet to mitigate this issue? or what other options could be considered? Thanks and regards,

3 5

[CentOS 7] Kamailio 5.1.x mongodb package missing in OpenSUSE repo.
by Denys Pozniak 01 Nov '18

01 Nov '18

Hello! How can I add module DB_MONGODB to existing installation of Kamailio 5.1.6 , if there is no package in OpenSUSE repo (home:kamailio:v5.1.x-rpms.repo) ? -- BR, Denys Pozniak

2 1

Topos on high load
by Igor Olhovskiy 01 Nov '18

01 Nov '18

Hi! We’ve run into really interesting issue while testing Kamailio with sipp (15 CPS, 300 calls - 1 failed call, more CPS - more failed calls) with topos involved. And at some point Kamailio starts to send 2 packets on received INVITE. 1 - with topos applied, 1 - with not. Main problem is to collect logs at this point, cause load is really high. Is it possible some internal race condition while topos involved? PCAP is attached. I’ve made a picture to illustrate a bit an issue Regards, Igor

2 2

Determine destination address family
by Isaac 31 Oct '18

31 Oct '18

Hello, How can I determine the address family (IPv6 or IPv4) of a destination? The destination in this case is a hostname. I'd like to set a flag if the destination is IPv6 but not sure how to go about it. Thanks, Isaac

2 2

Can't add permanent location
by David Villasmil 31 Oct '18

31 Oct '18

Hello all, I'm trying to add a permanent location. i’m using db_mode 1, use_domain = 1, i tried that command kamctl rpc ul.add location 361119997(a)m.domain.com sip:361119997@4.3.2.1 3600 0 sip:4.3.2.1:5060 Response is: { "jsonrpc": "2.0", "error": { "code": -32000, "message": "Execution Error" }, "id": 25950 } Anyone knows what this might be? David

2 5

USRLOC db_mode=4 and server_id
by Darren Williams 31 Oct '18

31 Oct '18

I am currently using multiple instances of Kamailio with a common database and using the usrloc module with db_mode=4 and server_id to filter the contacts that get loaded at startup on each server. The problem I seem to have is that using the RPC call ul.add, I cannot see any parameter to send to specify the server_id. The server_id that the contact is given is 0. If I manually go into the db and modify the server_id everything works as expected. I think I must be missing something somewhere as I'm sure you shouldn't need to do this. Can anyone help please. Thanks Daz

3 2

help with regex extracting from $rb
by Sergiu Pojoga 31 Oct '18

31 Oct '18

Hi there, May be some regex gurus can help me out. Being aware that regex's are tricky but not seeing another alternative in this particular case. Trying to extract MOSLQ field from $rb. $var(moslq) = $(rb{re.subst,/.*MOSLQ=([0-9].[0-9])\s+MOSCQ=([0-9].[0-9]).*/\1/s}); Above regex works fine IF body contains a single matching line. However, if there's 2 lines as in the below example - it return $var(moslq)=0.0, the last found value. I need only *LocalMetrics *values, so I tried this regex which works fine in regex101.com with flag 'multi-line' and *without flag 'global'*, but doesn't work in Kamailio. $var(moslq) = $(rb{re.subst,/.*MOSLQ=([0-9].[0-9])\s+MOSCQ=([0-9].[0-9])[\nRemoteMetrics]?.*/\1/s}); Assuming $rb is as follows: VQSessionReport CallID:1ca9258d285a539e3c1048205bf38d41@mypb.net LocalMetrics: Timestamps:START=2018-10-29T15:04:38Z STOP=2018-10-29T15:06:13Z QualityEst:EXTRI=127 MOSLQ=4.2 MOSCQ=4.4 RemoteMetrics: Timestamps:START=2018-10-29T15:04:38Z STOP=2018-10-29T15:06:13Z QualityEst:RCQ=0 EXTRI=0 MOSLQ=0.0 MOSCQ=0.0 Thanks in advance.

3 4

generate and forward a NOTIFY message
by AL S 31 Oct '18

31 Oct '18

Hi, I was wondering if Kamailio can generate and forward a NOTIFY message upon receiving an INVITE. Thanks, AL

3 2

Kamailio 5.1.x support under ubuntu 18.04 (beaver)
by Andrew Chen 30 Oct '18

30 Oct '18

Hi, We are planning to upgrade our Kamailio infrastructure to Kam 5.1.6 using Ubuntu 18.04. Is this a supported setup given that under the Debia package list support, I don't see beaver in there at all? Stable releases Debian/Ubuntu packages with latest release of 5.1 (choose the distribution you're interested in): deb http://deb.kamailio.org/kamailio51 wheezy main deb-src http://deb.kamailio.org/kamailio51 wheezy main deb http://deb.kamailio.org/kamailio51 jessie main deb-src http://deb.kamailio.org/kamailio51 jessie main deb http://deb.kamailio.org/kamailio51 stretch main deb-src http://deb.kamailio.org/kamailio51 stretch main deb http://deb.kamailio.org/kamailio51 buster main deb-src http://deb.kamailio.org/kamailio51 buster main deb http://deb.kamailio.org/kamailio51 precise main deb-src http://deb.kamailio.org/kamailio51 precise main deb http://deb.kamailio.org/kamailio51 trusty main deb-src http://deb.kamailio.org/kamailio51 trusty main deb http://deb.kamailio.org/kamailio51 xenial main deb-src http://deb.kamailio.org/kamailio51 xenial main Thanks. -- Andy Chen -- *Confidentiality Notice: The information contained in this e-mail and any attachments may be confidential. If you are not an intended recipient, you are hereby notified that any dissemination, distribution or copying of this e-mail is strictly prohibited. If you have received this e-mail in error, please notify the sender and permanently delete the e-mail and any attachments immediately. You should not retain, copy or use this e-mail or any attachment for any purpose, nor disclose all or any part of the contents to any other person. Thank you.*

1 0

How is ruid calculated
by Kjeld Flarup 28 Oct '18

28 Oct '18

I got two tablets registering with the same username, this used to work but now I got a bug report that only one of them gets a call. I found out that the problem is in the ruid column as they both end up with this ruid value uloc-1-5bd0abe9-83c-e4 How is that ruid value calculated, and how can I change this? -- -------------------- Med Liberalistiske Hilsner ---------------------- Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49 Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

2 1

kamailio as proxy for sipclients behind NAT without rtpproxy
by Karthik Kondapaneni 28 Oct '18

28 Oct '18

I want to use kamailio as a forwarding proxy infront of SIP registrar like asterisk/freeswitch without any rtpproxy to reduce the load on server and to be able to handle more requests . I am using default kamailio config file registration is working fine but call is not connecting . So sip clients should register on asterisk(or freeswitch) and able to receive inbound calls too . I am interested in only REGISTER & INVITE messages to restrict the messages based on sipclient's source ip . Please can someone help me with a working configuration for this setup . This is the topology .. (Sipclients with or without NAT ) ---------> (Kamailio without rtpproxy)-------------->(Asterisk or freeswitch or anyother sipserver )

1 0

add_authinfo_hdr not Added in 200 OK
by Seshu Kumar 26 Oct '18

26 Oct '18

Hello Guys, I am using Kamailio version 5.0.4 in IMS mode. I have added ims_auth in kamailio.cfg in S-Server. And added line modparam("ims_auth", "add_authinfo_hdr", 1) I am not finding “Authentication-Info” header being added in 200 OK responses. Anything more i need to enable. Kindly someone give a clue. Or this is known problem? Regards Seshu Kumar

9 21

Postgres: server version < 9.5 does not support insert_update
by Minh Phan 25 Oct '18

25 Oct '18

Hello List, I have just installed the version 5.1.6 and I get this warning message when Kamailio starts: > db_postgres_new_connection(): server version < 9.5 does not support insert_update Does it mean Kamailio will not be working properly with my current Postgres Server (9.4)? What are the consequence of not having support for insert_update command? Best regards, Minh Phan

4 3

Kamailio Slack channel
by Alex Balashov 25 Oct '18

25 Oct '18

Hi, I'd like to submit for the community's consideration the idea of having a Kamailio Slack channel. Emmanuel Schmidbauer took the initiative to create one: https://kamailio.slack.com/ The sign-in link is: https://join.slack.com/t/kamailio/shared_invite/enQtNDY1NDc5MzMwNDIzLWJlNTF… I for one think this is a good idea and, even if it doesn't ultimately get traction, it should be seriously considered by all. Yes, I am aware of the open-source-purist objection to Slack; it is proprietary and perceived to be a "walled garden" of sorts. Furthermore, for those of us who have been on the Internet and involved in technology for a significant amount of time, the irony is not lost that it is little more than a packaging of the "IRC" experience in the bloated form of a modern JavaScript application. I am also very reluctant to contribute in any way to the Balkanisation or fracturing of project-related communication channels. That thought gives me no comfort. These are all concerns of which I'm mindful. Nevertheless: - A great deal of professional real-time messaging and communication in many organisations has moved to Slack. This is also true of our company, and most companies we work with. Thus, a Slack channel for Kamailio would be highly complementary to a platform many other people are already using. - Slack provides a polished and cohesive user experience, which is why it has become so popular. There are clients for every platform, and a seamless user experience that is also highly compatible with mobile and tablet. One can shoehorn IRC into these media, but it clearly is not designed for them. - There are already lots of open-source discussion channels and developer forums on Slack. - Slack's inline Markdown and other conveniences make it _much_ easier to have discussions about code, configurations, etc., since it is easy to insert inline monospace and multiline blobs, attachments, etc. This is what inspired my switch to it. - A lot of people positioned within the current wave of thinking about IT and technology, and thus a big part of our candidate user base, have never used IRC. Anyway, for those interested, I propose that you join Emmanuel and I. Let's see how it works out? -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

3 4

Why set this flag on registration?
by Isaac 25 Oct '18

25 Oct '18

Hello, In the example for a dual-stack IPv6/IPv4 Kamailio setup here: https://kb.asipto.com/kamailio:kamailio-mixed-ipv4-ipv6 the "FLB_IPV6" flag is being sent on IPv6 registrations. Why set this flag on IPv6 registrations? If I understand correctly, registration requests never make it beyond !save("location so it's not like the flag can be used further in the dial-plan. The code in question: route[REGISTRAR] { if (is_method("REGISTER")) { if(isflagset(FLT_NATS)) { setbflag(FLB_NATB); # uncomment next line to do SIP NAT pinging ## setbflag(FLB_NATSIPPING); } if(af==INET6) setbflag(FLB_IPV6); if (!save("location")) sl_reply_error(); exit; } } Any help is appreciated. Thanks

2 2

Kamailio Question
by Brian Longwell 25 Oct '18

25 Oct '18

I'm trying to setup a simple proxy with NAT/RTPproxy. I have started with the basic cfg file and added nat and forced rtpproxy. The proxy is to reside in between endpoints and multiple SIP servers. Currently calls from endpoints are working great but my issue is calls from the server to the endpoint. The SIP messages are good until the 200 OK sent from the phone back, Kamailio is not fixing the contact so it's sending the private IP of the phone back to the server so all subsequent traffic is attempting to route to the private IP. I have tried using the fix_nated_contact everywhere I could think but still no difference. Attached is sip capture and the kamailio.cfg i'm currently using. Thank you, Brian

1 0

RtpEngine and iLBC support
by Lars Olsson 25 Oct '18

25 Oct '18

Hi, Can anyone give a quick answer regarding RtpEngine and support for iLBC codec? I have followed the instructions how to build and enable codecs according to the GitHub manual. But iLBC codec is missing when performing "rtpengine --codecs". I have tried to google around for iLBC references, but the only thing that I have found so far is libilbc, which is a lib for ffmpeg, and it looks like ffmpeg needs to be recompiled. What is the correct/fastest way forward for getting iLBC support on RtpEngine on debian 9? The purpose it to test a-law to iLBC transcoding. Best Regards, Lars

2 1

Odd behavior comparing strings
by Duarte Rocha 25 Oct '18

25 Oct '18

Greetings, I found an odd behaviour in Kamailio and i would like to know if it's intentional. I've made this snippet for showing : $var(teste) = $null; if($var(teste) == "Test") { xerr("TEST : If returned true"); } The "if" returns true if the $var is $null or 0. I'm using the "cmp_str()" now in order to avoid this issue. Best Regards, Duarte Rocha

2 3

Re: [SR-Users] kamailio + asterisk + webrtc
by arish haque 25 Oct '18

25 Oct '18

Hi, I am using this command for starting RTPengine - /usr/sbin/rtpengine --table=0 --interface=192.168.1.x\!182.75.xx.yy --listen-ng=127.0.0.1:22222 --pidfile=/var/run/rtpengine.pid --log-level=6 --log-facility=local1 in kamailio.cfg --> listen=MY_SIP_ADDR advertise 182.75.xx.yy:5060 But still there is no RTP from outside network. Still not able to sort out what is the issue.If pfsense is blocking rtp packets or any other. but i have very config on pfsense. Thanks & Regards, Arish Haque

2 1

Re: [SR-Users] : hight shared memory usage
by Laurent Schweizer 25 Oct '18

25 Oct '18

Hello, No, both server have the same script, the only difference is that they are connected to different DB. We increase the max TLS connections because we plan to move some customer on this proxy and we want to be ready to accept more than 2K TLS connection . Laurent -----Message d'origine----- De : Henning Westerholt <hw(a)kamailio.org> Envoyé : mercredi, 24 octobre 2018 22:46 À : sr-users(a)lists.kamailio.org Cc : Laurent Schweizer <laurent.schweizer(a)peoplefone.com> Objet : [JUNK-SPAM] Re: [SR-Users] : hight shared memory usage Am Mittwoch, 24. Oktober 2018, 15:24:05 CEST schrieb Laurent Schweizer: > I have 2 proxy running and we have a very big difference of memory > usage between them, moreover we have more connected users on the proxy > with less memory usage. > > We have this issue on the first proxy, today we have to increase the > shared memory as it was no more possible to setup new TCP connection. > > We use the same version of the proxy, script is quite the same, one > difference, on the proxy with the issue we increase the number of max > TLS connection to 20K > > Any idea ? > is TLS consuming more memory than TCP or UDP ? Hello Laurent, TLS is using more memory than TCP and than UDP, due to the higher workload and overhead for crypto/connection tracking. But looking to your registered user count this should not make a big difference in the end. Do you have maybe a different usage pattern on the first proxy comparing to the second one? So that different parts of the cfg or the code are executed? Why do you increased the number of max TLS connections on the first proxy, you had also some issues here? > First proxy (with high memory usage): > > > [cycle #: 3; if constant make sure server lives] Kamailio Runtime > Details: > kamailio 5.0.6 (x86_64/linux) > now: Wed Oct 24 15:18:55 2018 > up_since: Wed Oct 24 13:21:12 2018 > uptime: 7063 > > Transaction Statistics: > tmx:UAS_transactions = 56240 tmx:active_transactions = 4 > tmx:UAC_transactions = 0 tmx:inuse_transactions = 18 > > Stateless Server Statistics: > sl:sent_replies = 134317 sl:sent_err_replies = 0 > > UsrLoc Statistics: > usrloc:location_ch-contacts = 1463 usrloc:location_ch-users = 1181 > usrloc:location_ch-expires = 1076 usrloc:registered_users = 1181 > > Core Statistics: > core:rcv_requests = 214220 core:rcv_replies = 179145 > core:fwd_requests = 5495 core:fwd_replies = 73 > > Shared Memory Statistics: > shmem:fragments = 529 shmem:real_used_size = > 15862690496 shmem:free_size = 36566109504 shmem:total_size = > 52428800000 shmem:max_used_size = 16198927224 shmem:used_size = > 15854961104 > > > > cat /proc/net/netstat | cut -d" " -f12-17 ; cat /proc/net/sockstat TW > TWRecycled TWKilled PAWSPassive PAWSActive PAWSEstab > 339118 0 684 3195 0 4648 > InBcastOctets OutBcastOctets InCsumErrors InNoECTPkts InECT1Pkts > InECT0Pkts > 14620680 0 0 19142166496 9683 133135 > sockets: used 1951 > TCP: inuse 1029 orphan 0 tw 2 alloc 1036 mem 15 > UDP: inuse 540 mem 446 > UDPLITE: inuse 0 > RAW: inuse 0 > FRAG: inuse 0 memory 0 > > > > ------------------------------------------- > > > Second proxy (memory is OK) : > > [cycle #: 2; if constant make sure server lives] Kamailio Runtime > Details: > kamailio 5.0.6 (x86_64/linux) > now: Wed Oct 24 15:19:39 2018 > up_since: Mon Jul 2 00:31:48 2018 > uptime: 9902871 > > Transaction Statistics: > tmx:UAS_transactions = 86712048 tmx:active_transactions = 92 > tmx:UAC_transactions = 0 tmx:inuse_transactions = 178 > > Stateless Server Statistics: > sl:sent_replies = 641635175 sl:sent_err_replies = 0 > > UsrLoc Statistics: > usrloc:location-contacts = 3971 usrloc:location-users = 3845 > usrloc:location-expires = 286685 usrloc:registered_users = 3845 > > Core Statistics: > core:rcv_requests = 752644955 core:rcv_replies = 1181197213 > core:fwd_requests = 14482059 core:fwd_replies = 206909 > > Shared Memory Statistics: > shmem:fragments = 28437 shmem:real_used_size = 56447456 > shmem:free_size = 2091036192 shmem:total_size = 2147483648 > shmem:max_used_size = 82099768 shmem:used_size = 43354160 > > > cat /proc/net/netstat | cut -d" " -f12-17 ; cat /proc/net/sockstat TW > TWRecycled TWKilled PAWSPassive PAWSActive PAWSEstab > 273625 0 0 0 0 3524 > InBcastOctets OutBcastOctets InCsumErrors InNoECTPkts InECT1Pkts > InECT0Pkts > 2010 0 1 179031265416 81564 21432766 > sockets: used 4964 > TCP: inuse 576 orphan 0 tw 3 alloc 681 mem 105 > UDP: inuse 3908 mem 3117 > UDPLITE: inuse 0 > RAW: inuse 0 > FRAG: inuse 0 memory 0 Best regards, Henning -- Henning Westerholt - https://skalatan.de/blog/ Kamailio security assessment - https://skalatan.de/de/assessment

2 1

DMQ and DIALOG
by Phillman25 Kyriacou 24 Oct '18

24 Oct '18

Hi List! I currently have 3 Kamailio's (Version 5.1) in an ACTIVE-ACTIVE-ACTIVE scenario behind a load balancer all 3 nodes are listening and advertising the same virtual ip of the load balancer. Im using dmq module together with dialogue module to sync the state of the dialog to all 3 nodes. Is there a way or module that i can use to also sync every transaction? Problem that im facing right now is that an INVITE will come to Kamailio1 and the 100 TRYING or 183 RINGING or 200OK will go to Kamailio2 and since Kamailio1 hasn't received a response will retransmit the INVITE. Or is there a way with dmq to also update the other nodes for responses like 100 ,183 or 200 OK so that Kamailio1 knows not to retransmit? Maybe im going down the wrong path? :) Any assistance would be greatly appreciated My config for dmq and dialog: #=====================DIALOG==================================== modparam("dialog", "enable_dmq", 1) #=====================DMQ======================================= modparam("dmq", "server_address", "sip:x.x.x.x:5080") modparam("dmq", "notification_address", "sip:y.y.y.y:5080") modparam("dmq", "multi_notify", 1) modparam("dmq", "num_workers", 4) modparam("dmq", "ping_interval", 30) request_route { # MANAGE ALL DIALOGS dlg_manage(); if(is_method("KDMQ")) { dmq_handle_message(); } Thanks! Phillip

4 5

: hight shared memory usage
by Laurent Schweizer 24 Oct '18

24 Oct '18

Dear all, I have 2 proxy running and we have a very big difference of memory usage between them, moreover we have more connected users on the proxy with less memory usage. We have this issue on the first proxy, today we have to increase the shared memory as it was no more possible to setup new TCP connection. We use the same version of the proxy, script is quite the same, one difference, on the proxy with the issue we increase the number of max TLS connection to 20K Any idea ? is TLS consuming more memory than TCP or UDP ? BR Laurent First proxy (with high memory usage): [cycle #: 3; if constant make sure server lives] Kamailio Runtime Details: kamailio 5.0.6 (x86_64/linux) now: Wed Oct 24 15:18:55 2018 up_since: Wed Oct 24 13:21:12 2018 uptime: 7063 Transaction Statistics: tmx:UAS_transactions = 56240 tmx:active_transactions = 4 tmx:UAC_transactions = 0 tmx:inuse_transactions = 18 Stateless Server Statistics: sl:sent_replies = 134317 sl:sent_err_replies = 0 UsrLoc Statistics: usrloc:location_ch-contacts = 1463 usrloc:location_ch-users = 1181 usrloc:location_ch-expires = 1076 usrloc:registered_users = 1181 Core Statistics: core:rcv_requests = 214220 core:rcv_replies = 179145 core:fwd_requests = 5495 core:fwd_replies = 73 Shared Memory Statistics: shmem:fragments = 529 shmem:real_used_size = 15862690496 shmem:free_size = 36566109504 shmem:total_size = 52428800000 shmem:max_used_size = 16198927224 shmem:used_size = 15854961104 cat /proc/net/netstat | cut -d" " -f12-17 ; cat /proc/net/sockstat TW TWRecycled TWKilled PAWSPassive PAWSActive PAWSEstab 339118 0 684 3195 0 4648 InBcastOctets OutBcastOctets InCsumErrors InNoECTPkts InECT1Pkts InECT0Pkts 14620680 0 0 19142166496 9683 133135 sockets: used 1951 TCP: inuse 1029 orphan 0 tw 2 alloc 1036 mem 15 UDP: inuse 540 mem 446 UDPLITE: inuse 0 RAW: inuse 0 FRAG: inuse 0 memory 0 ------------------------------------------- Second proxy (memory is OK) : [cycle #: 2; if constant make sure server lives] Kamailio Runtime Details: kamailio 5.0.6 (x86_64/linux) now: Wed Oct 24 15:19:39 2018 up_since: Mon Jul 2 00:31:48 2018 uptime: 9902871 Transaction Statistics: tmx:UAS_transactions = 86712048 tmx:active_transactions = 92 tmx:UAC_transactions = 0 tmx:inuse_transactions = 178 Stateless Server Statistics: sl:sent_replies = 641635175 sl:sent_err_replies = 0 UsrLoc Statistics: usrloc:location-contacts = 3971 usrloc:location-users = 3845 usrloc:location-expires = 286685 usrloc:registered_users = 3845 Core Statistics: core:rcv_requests = 752644955 core:rcv_replies = 1181197213 core:fwd_requests = 14482059 core:fwd_replies = 206909 Shared Memory Statistics: shmem:fragments = 28437 shmem:real_used_size = 56447456 shmem:free_size = 2091036192 shmem:total_size = 2147483648 shmem:max_used_size = 82099768 shmem:used_size = 43354160 cat /proc/net/netstat | cut -d" " -f12-17 ; cat /proc/net/sockstat TW TWRecycled TWKilled PAWSPassive PAWSActive PAWSEstab 273625 0 0 0 0 3524 InBcastOctets OutBcastOctets InCsumErrors InNoECTPkts InECT1Pkts InECT0Pkts 2010 0 1 179031265416 81564 21432766 sockets: used 4964 TCP: inuse 576 orphan 0 tw 3 alloc 681 mem 105 UDP: inuse 3908 mem 3117 UDPLITE: inuse 0 RAW: inuse 0 FRAG: inuse 0 memory 0

2 2

How is ruid calculated
by Kjeld Flarup 24 Oct '18

24 Oct '18

I got two tablets registering with the same username, this used to work but now I got a bug report that only one of them gets a call. I found out that the problem is in the ruid column as they both end up with this ruid value uloc-1-5bd0abe9-83c-e4 How is that ruid value calculated, and how can I change this? -- -------------------- Med Liberalistiske Hilsner ---------------------- Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49 Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

1 0

Fwd: tcp Free fragment not found
by Diego Nadares 24 Oct '18

24 Oct '18

---------- Mensaje reenviado --------- De: Diego Nadares <dnadares(a)gmail.com> Fecha: El vie, 5 oct. 2018 a las 15:46 Asunto: Re: [SR-Users] tcp Free fragment not found Para: Daniel-Constantin Mierla <miconda(a)gmail.com> Hi Daniel, Sorry for the delay. -M 32 -m 128 Should I increase any/both of these params? Thanks again! Diego El jue., 4 oct. 2018 a las 3:31, Daniel-Constantin Mierla (< miconda(a)gmail.com>) escribió: > Hello, > > what are the values for -m and -M command line parameters? > > Cheers, > Daniel > > On 03.10.18 16:37, Diego Nadares wrote: > > Hi guys! I hope you are doing well. > > Any hint on this? I changed to json but sometimes i get the same error. > > 2018-10-03T10:12:11.066539-03:00 drwsip11 /usr/local/sbin/kamailio[28173]: > ERROR: <core> [mem/f_malloc.c:415]: fm_search_defrag(): fm_search_defrag(0 > x7f575c4ad000, 5352056); Free fragment not found! > 2018-10-03T10:12:11.067552-03:00 drwsip11 /usr/local/sbin/kamailio[28173]: > ERROR: <core> [mem/f_malloc.c:498]: fm_malloc(): fm_malloc(0x7f575c4ad000, > 5352056) called from core: tcp_main.c: _wbufq_add(636), module: core; > Free fragment not found! > 2018-10-03T10:12:11.068128-03:00 drwsip11 /usr/local/sbin/kamailio[28182]: > ERROR: <core> [tcp_main.c:3496]: handle_ser_child(): received CON_ERROR for > 0x7f575f6a6918 (id 12638), refcnt 3, flags 0x4018 > 2018-10-03T10:12:11.068397-03:00 drwsip11 /usr/local/sbin/kamailio[28173]: > ERROR: sl [../../forward.h:220]: msg_send_buffer(): tcp_send failed > 2018-10-03T10:12:11.068929-03:00 drwsip11 /usr/local/sbin/kamailio[28173]: > ERROR: xmlrpc [xmlrpc.c:795]: send_reply(): Error while sending reply > 2018-10-03T10:12:11.092080-03:00 drwsip11 /usr/local/sbin/kamailio[28173]: > WARNING: <core> [tcp_read.c:1666]: handle_io(): F_TCPCONN connection marked > as bad: 0x7f575f6a6918 id 12638 refcnt 1 > > Is there any stat to see? Or any additional configuration to make? > > Here is my tcp related config > > tcp_connection_lifetime=3605 > tcp_conn_wq_max=30000000 > tcp_rd_buf_size=5273226 > > We are running kamilio 4.4.5 > > Thanks in advance! > > Diego > > > > > El vie., 26 may. 2017 a las 16:12, Diego Nadares (<dnadares(a)gmail.com>) > escribió: > >> Hi guys! >> >> We have four a scripts that sends dlg.list command to kamailio through >> xmlrpc. They are not executed simultaneously. Sometimes, we are getting >> the following errors: >> >> fm_search_defrag(): fm_search_defrag(0x7f212c25a000, 5273984); Free >> fragment not found!2017-05-26T13:54:20.438736-03:00 drwsip02 >> /usr/local/sbin/kamailio[19833]: ERROR: <core> [mem/f_malloc.c:498]: >> fm_malloc(): fm_malloc(0x7f212c25a000, 5273984) called from core: >> tcp_main.c: tcpconn_new(957), module: core; Free fragment not >> found!2017-05-26T13:54:20.439101-03:00 drwsip02 >> /usr/local/sbin/kamailio[19833]: ERROR: <core> [tcp_main.c:959]: >> tcpconn_new(): mem. allocation failure2017-05-26T13:54:20.439344-03:00 >> drwsip02 /usr/local/sbin/kamailio[19833]: ERROR: <core> [tcp_main.c:3985]: >> handle_new_connect(): tcpconn_new failed, closing socket >> >> I all ready increased this two variables: >> >> tcp_conn_wq_max=30000000 >> tcp_rd_buf_size=5273226 >> >> How can I see how much memory xmlrpc is using? >> >> Any advice will be appreciated. >> >> Thanks in advance! >> >> Diego >> >> > > _______________________________________________ > Kamailio (SER) - Users Mailing Listsr-users@lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > > > -- > Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda > Kamailio World Conference -- www.kamailioworld.com > Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com > >

2 3

Double Session Description Protocol Version (v) 0 data when using rtpengine
by Wilkins, Steve 24 Oct '18

24 Oct '18

Hello all, I noticed double Session Description Protocol Version (v) 0 data in the SDP section when using rtpengine with Kamailio. Has any else noticed this? Is there a way for Kamailio to remove one of them? Thank you, -Steve

3 12

Double Session Description Protocol Version (v) 0 data when using rtpengine
by Wilkins, Steve 24 Oct '18

24 Oct '18

I was looking at the sdpops_mod.c code hoping that there was an easy way to remove a sess_version (Session Description Protocol Version (v): 0) structure, but there does not appear to be that functionality in that module. It might be a bit of work to remove a duplicate sess_version line. I am using Kamailio 5.1, does anyone know if this is an issue in later versions? Thank you, -Steve

2 4

Re: [SR-Users] htable 1 Millon registers
by Henning Westerholt 24 Oct '18

24 Oct '18

Am Dienstag, 23. Oktober 2018, 23:45:49 CEST schrieb Mauricio Tejeda: > Hello Henning. > Thanks for answered. > Yes, the failure is during the kamailio load. > > I'm increased the shared memory but there is no change, the failure > persists. > > I will try with redis Hello Mauricico, ok - if you want to look people on this list into the error you need to give more details, like some actual error messages from the Kamailio log. But as already pointed out, going with redis is indeed a valid option. Best regards, Henning -- Henning Westerholt - https://skalatan.de/blog/ Kamailio security assessment - https://skalatan.de/de/assessment

1 0

Info: Pre-announcement about Kamailio World 2019
by Daniel-Constantin Mierla 24 Oct '18

24 Oct '18

Hello, being asked couple of times recently, for now I am sending a short note to say that the next edition of Kamailio World Conference is likely to take place at the same location in the city center of Berlin, Germany, during May 6-8, 2019. There are still some bits to sort out before making the dates final, so just have the dates in mind at this moment. Once all is set from organising point of view, we will make the official announcement. Cheers, Daniel -- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda

1 0

kamailio+asterisk+webrtc
by arish haque 23 Oct '18

23 Oct '18

Hi, Thank you for the reply! I tried advertising udp port like this listen=udp:192.168.1.x:5060 advertise 182.70.xx.yy:5060. How to advertise RTP ports? Kamailio+RTPengine on a Centos s/m with a priv ip - 192.168.1.x Asterisk is on another CentOs s/m with a priv ip - 192.168.1.y pfsense on pub ip - 182.75.xx.yy PORT FORWARDING on pfsense- sip and rtp ports to kamailio+rtpengine server 192.168.1.x. How to make RTPengine listen on public interface-- 182.75.181.70? sip.conf ======== [general] context=external realm=192.168.1.y bindaddr=0.0.0.0:5080 tcpenable=no allowoverlap=no transport=udp,wss,ws srvlookup=yes qualify=yes directmedia=no canreinvite=no ;---------NAT SUPPORT--------- externip=182.75.xx.yy localnet=192.168.1.0/255.255.255.0 nat=yes ;nat=no //tried but no RTP ;nat=force_rport,comedia //tried but no RTP ;-----------RTP SUPPORT---------------- rtpkeepalive=30 disallow=all allow=gsm allow=ulaw allow=opus allow=alaw allow=g723 ================== and i am using asterisk realtime support for mysql to store peer details. With Regards, Arish Haque

1 0

kamailio + asterisk + webrtc
by arish haque 23 Oct '18

23 Oct '18

Hi, Thank you for the reply! I tried advertising udp port like this listen=udp:192.168.1.x:5060 advertise 182.70.xx.yy:5060. How to advertise RTP ports? Kamailio+RTPengine on a Centos s/m with a priv ip - 192.168.1.x Asterisk is on another CentOs s/m with a priv ip - 192.168.1.y pfsense on pub ip - 182.75.xx.yy PORT FORWARDING on pfsense- sip and rtp ports to kamailio+rtpengine server 192.168.1.x. sip.conf ======== [general] context=external realm=192.168.1.y bindaddr=0.0.0.0:5080 tcpenable=no allowoverlap=no transport=udp,wss,ws srvlookup=yes qualify=yes directmedia=no canreinvite=no ;---------NAT SUPPORT--------- externip=182.75.xx.yy localnet=192.168.1.0/255.255.255.0 nat=yes ;nat=no //tried but no RTP ;nat=force_rport,comedia //tried but no RTP ;-----------RTP SUPPORT---------------- rtpkeepalive=30 disallow=all allow=gsm allow=ulaw allow=opus allow=alaw allow=g723 ================== How to make RTPengine listen to public interface-- 182.75.181.70? With Regards, Arish Haque

1 0

kamailio + asterisk + webrtc
by arish haque 23 Oct '18

23 Oct '18

Hi, I tried advertising udp port like this listen=udp:192.168.1.x:5060 advertise 182.70.xx.yy:5060. How to advertise RTP ports? Kamailio+RTPengine on a Centos s/m with a priv ip - 192.168.1.x Asterisk is on another CentOs s/m with a priv ip - 192.168.1.y pfsense on pub ip - 182.75.xx.yy PORT FORWARDING on pfsense- sip and rtp ports to kamailio+rtpengine server 192.168.1.x. Config and logs are attached. Thank you for the reply! With Regards, Arish Haque

1 0

Re: [SR-Users] kamailio + asterisk + webrtc
by arish haque 23 Oct '18

23 Oct '18

Hi Fred, I have advertised the udp port in kamailio.cfg like below - listen=udp:192.168.1.x:5060 advertise 182.70.xx.yy:5060 But how to advertise rtp Ports?? I have attached sip.conf *Asterisk 1----\ * * \ ------ **Kamailio+RTPPROXY ----** FW (pfsense **182.75.xx.yy public-IP)**--- INTERNET** \ **(private ip - 192.168.1.x)* *Asterisk n------\ * *Th**anks & Regards,* *Arish Haque*

3 2

htable 1 Millon registers
by Mauricio Tejeda 23 Oct '18

23 Oct '18

Good afternoon. Trying to use the htables module to load an extensive table in memory, I can not start kamailio. If the table contains few records (5 and 10 in my examples), this works without problems, for everything else I lose the connection to the database "Lost connection to MySQL server during query" I modified the timeout of mariadb but I can not work. Someone with a similar problem or ideas on how to solve it? Thank you

3 3

RTPEngine set IDs
by Alex Balashov 22 Oct '18

22 Oct '18

Hi, I have a question about RTPEngine set IDs: As of Kamailio 5.x, it appears the RTPEngine module has got quite smart. Even if I don't set `setid_avp`, it still knows which RTPEngine instance and set ID was engaged by an initial rtpengine_offer() / rtpengine_manage() command. This knowledge persists even to delete calls in CANCEL / BYE handling, or in subsequent offer/answer calls in reinvites or UPDATEs. That's great, and very convenient. It saves me the trouble of having to store the set ID in an RR param or as a dialog variable, because everything Just Works. The problem, of course, is that if I restart Kamailio, all this state is forgotten. So, for example, if I set up a call, answer it, restart Kamailio, then hang it up, the delete command will go to the default set and not necessarily the non-zero set chosen. If I want proper RTPEngine call teardown to persist across restarts, as far as I can tell I will need to store the set ID in an RR param or some other reasonably stateless way. Am I missing anything here? Does the `rtpengine` module offer some means of persisting this data across restarts? As far as I can tell, its database backing is for the set definitions only and not for call state. Cheers, -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

1 0

kamailio + asterisk + webrtc
by arish haque 22 Oct '18

22 Oct '18

Hi all, I am using kamailio as sip server and asterisk as media server behind pf-sense firewall (NAT) with a public ip. Sip signalling as well as rtp packets are flowing correctly when the endpoints are within a network. But when trying from outside network sip signalling is working perfectly but there is no RTP. Public ip behind pfsense -> 182.70.xx.yy kamailio+rtpengine and asterisk servers are on private ips --> 192.168.1.x kamailio ip - 192.168.1.x asterisk ip - 192.168.1.y Please, feel free to ask for more information. Thanks & Regards, Arish Haque

4 3

Kamailio forwarding call via Public IP Address vs Private IP Address
by Wilkins, Steve 21 Oct '18

21 Oct '18

Good morning All, I have two almost Identical (Kamailio=>Asterisk) systems set up, but one of them is receiving calls and forwarding them to the Asterisk Public IP, and the other is Forwarding to the Asterisk Private IP. The call is coming in to the number and domain in both scenarios. Any ideas on what would cause this? Thank you, -Steve

1 2

Set a system variable in the request route
by Nicolas Breuer 20 Oct '18

20 Oct '18

Hello, How can I change a system variable within the route ? I can change a variable witk kamctl but any ideas in the code ? Thanks

2 2

Variable Kamailio version
by Nicolas Breuer 20 Oct '18

20 Oct '18

Hello, Can we get the Kamailio version into a variable ? Thanks

3 3

pause/waiting Timer kamailio
by eyas barhouk 19 Oct '18

19 Oct '18

Hello Dears if i need to make kamailio able to pause request processing for a Period of time is that possible ? for example when kamailio receive an INVITE request then it have to wait until 10 seconds before relay it to the second server. thanks in advance .

6 7

Acoounting with acc_radius when dialog terminates by default_timeout
by Denys Pozniak 19 Oct '18

19 Oct '18

Hello! How can I send RADIUS Accounting-Request in case of terminating dialog via default_timeout timer? I tried to catch Kamailio's own generated BYE in event_route AND tried to use cdr_expired_dlg_enable , but it looks like acc module is not triggered. event_route[dialog:end] { if ( dlg_isflagset(FLT_ACC_START) && is_method("BYE") ) { setflag(FLT_ACC); } dlg_resetflag(FLT_ACC_START); } modparam("acc", "log_flag", FLT_ACC) modparam("acc", "cdr_expired_dlg_enable", 1) modparam("acc_radius", "radius_config", "/etc/radiusclient/radiusclient.conf") modparam("acc_radius", "radius_flag", FLT_ACC) modparam("acc_radius", "radius_missed_flag", FLT_ACCMISSED) modparam("dialog", "default_timeout", 3600) modparam("dialog", "send_bye", 1) version: kamailio 4.4.2 (x86_64/linux) 892ad6 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_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 892ad6 compiled on 12:58:38 Aug 28 2017 with gcc 4.8.5 -- BR, Denys Pozniak

2 2

Help
by Olivier KOFFI 19 Oct '18

19 Oct '18

Good morning I want to use kamailio to send calls to an asterisk. My problem is that I want to define call prefixes. example If the subscriber calls the 6000, please call us 7000 on transfer to asterisk. Subscribers are at 6000.6001, etc. I want to know exactly which line to modify in kamailio.cfg thank you Sincerely KOFFI Koffi Olivier +225 79830005 +225 59098608 Directeur Technique LIFOR Sarl

2 1

Event route websocket:closed and function unregister
by Володимир Іванець 19 Oct '18

19 Oct '18

Hello all! I have *event_route[websocket:closed]* configured. By using *$si*, *$sp* variables and data from special hash table I can figure out information about account that was disconnected. I'm trying to use *unregister* function against but with no luck. 1. I'm creating variable which contains (as an example): " sip:100-test@127.0.0.1" string, where "100-test" is username. 2. lookup("location", "$var(user_uri)") - runs fine. I'm getting a match and lots of useful variables including *$ruid* are being set: */usr/sbin/kamailio[27169]: DEBUG: registrar [lookup.c:256]: lookup_helper(): contact for [100-test] found by address* 3. But unfortenately *unregister* with same variable does not work. unregister("location", "$var(user_uri)"): *DEBUG: <core> [core/parser/parse_uri.c:1282]: parse_uri(): bad uri, state 0 parsed: <you@> (4) / <you(a)kamailio.org <you(a)kamailio.org>> (16)* *ERROR: <core> [core/parser/parse_to.c:81]: parse_to_uri(): failed to parse To uri* *ERROR: registrar [save.c:1040]: unregister(): failed to extract Address Of Record* I was trying to manipulate *$var(user_uri)* variable's content but could not make it work. It's interesting that variant with *$ruid* - *unregister("location", "", "$ruid")* will work but unfortenately it works only with *modparam("usrloc", "db_mode", 1)*: *ERROR: usrloc [urecord.c:655]: delete_urecord_by_ruid(): delete_urecord_by_ruid currently available only in db_mode=3* I was wonderring if someone could tell me if I'm just using *unregister* function with uri parameter in wrong format or there might be some other problem. Thanks a lot!

2 4

Dispatcher Return
by Duarte Rocha 19 Oct '18

19 Oct '18

Greetings, I'm using Kamailio with Dispatcher and now i have the need to have more than one destination with the same IP:Port belonging to the same Destination Group. Those destinations will have different configurations unrelated to the Dispatcher. However, after ds_select_dst I only have access to IP and Port. Is it possible to Dispatcher to return another fields from the same table row? Or return any other way to identify the row. Thank you for your help. Best Regards, Duarte Rocha

1 0

Questions
by Olivier KOFFI 19 Oct '18

19 Oct '18

Bonjour Je veux utiliser kamailio pour transmettre des appels vers asterisk. Mon problème est que je veux définir les prefixes d'appels. exemple Si l’abonné appel le 6000 kamailio gère l'appel.mais s'il compose le 7000 on transfert à asterisk. Les abonné sont au 6000,6001,etc je veux savoir exactement quelle ligne modifier dans kamailio.cfg merci Cordialement KOFFI Koffi Olivier +225 79830005 +225 59098608 Directeur Technique LIFOR Sarl

2 1

HTTP Post with JSON
by eyas barhouk 18 Oct '18

18 Oct '18

Hello Dears i'm trying to send POST HTTP request with JSON content on Kamailio V 5.2.0. i have two main headers "content type" & "Authentication " in addition i have the json content . when i'm using curl request it look like : Curl -H "Authentication ket = xxxxx" -H "content type : JSON" -d " {the JSON content}" https://xxxxx.com/send So how can i use the Http_client module to send such requests ?? thanks in advance .

3 10

Http_async_client stops script execution
by Denys Pozniak 18 Oct '18

18 Oct '18

Hello! Please help me to understand how http_async_client module behaves. I am going to use it for call routing according to the http response. if (is_method("INVITE")) { t_newtran(); xlog("L_ERR", "ASYNC0-$fU-$rU-$rm---- \n"); http_set_timeout(1000); http_set_method("POST"); http_append_header("Content-Type: application/json"); http_async_query("http://10.10.10.10:8080/RPC", "{\"jsonrpc\": \"2.0\", \"method\": \"ul.lookup\", \"params\": [\"location\",\"user\"], \"id\": 1}", "HTTP_REPLY"); xlog("L_ERR", "ASYNC1-$fU-$rU-$rm---- \n"); } route[HTTP_REPLY] { xlog("L_ERR", "HTTP_REPLY: ok $http_ok \n"); xlog("L_ERR", "HTTP_REPLY: status $http_rs\n"); xlog("L_ERR", "HTTP_REPLY: body $http_rb\n"); xlog("L_ERR", "HTTP_REPLY: error $http_err)\n"); } In syslog I see HTTP_REPLY log strings with correct response, but do not see ASYNC1 string and script execution stops. What's wrong with this? # kamailio -v version: kamailio 4.4.2 (x86_64/linux) 892ad6 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_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: 892ad6 compiled on 12:58:38 Aug 28 2017 with gcc 4.8.5 -- BR, Denys Pozniak

2 8

No way to send SIP reply from app_perl or jsonrpc modules
by M S 18 Oct '18

18 Oct '18

Hi, I have a use case where I need to send a statefull (or stateless) reply to non-INVITE SIP transaction from PERL script using app_perl module's "moduleFunction" method, https://kamailio.org/docs/modules/5.0.x/modules/app_perl.html#ID-7b0efd72c8… It fails with error "function not found, missing load module?", even though the documentation says that at least "sl_send_reply" method should work. As an alternative, I tried to use JSONRPCS module to call RPC methods "tm.reply" and "tm.reply_callid" from PERL script (using libcurl), https://kamailio.org/docs/modules/5.0.x/modules/jsonrpcs.html https://kamailio.org/docs/modules/5.0.x/modules/tm.html#tm.rpc.reply https://kamailio.org/docs/modules/5.0.x/modules/tm.html#tm.rpc.reply_callid However, they only seems to work for INVITE transactions. If I try to use them for e.g. MESSAGE request I get "Request Timeout" on libcurl and "500 I am terribly sorry" on SIP client. Are these bugs or suppose to work this way? If so, then, is there any way i can send a SIP reply to non-INVITE SIP transaction from outside of the kamailio.cfg script? Please help. P.S. I am using Kamailio 5.0.x on debian wheezy 32bit virtual machine. Thank you.

1 0

Script @Startup
by Nicolas Breuer 17 Oct '18

17 Oct '18

Hello All, Is there a way to execute some codes/scripts at the launch of the Kamailio Server ? So only once when we launch the server. Thanks

2 2

Re: [SR-Users] Missing documentation ims_usrloc_scscf module
by Pan Christensen 17 Oct '18

17 Oct '18

Thanks Henning and Carsten. It should also be noted that the module is required by both IMS_ISC and IMS_REGISTRAR_SCSCF. The lacking documentation of IMS_USRLOC_SCSCF also make those modules difficult to implement. Pan B. Christensen Developer Phonect AS > -----Original Message----- > From: Henning Westerholt <hw(a)kamailio.org> > Sent: tirsdag 16. oktober 2018 20:27 > To: sr-users(a)lists.kamailio.org > Cc: Carsten Bock <carsten(a)ng-voice.com>; Pan Christensen > <pan.christensen(a)phonect.no> > Subject: *** SPAM *** Re: [SR-Users] Missing documentation > ims_usrloc_scscf module > > Am Dienstag, 16. Oktober 2018, 13:31:08 CEST schrieb Carsten Bock: > > can you open a ticket on the GitHub Tracker for this? Otherwise this > > might get lost at some point... I don't have time to take care of it > > immediately as I am travelling this and next week, more likely I would > > take care of it later in November. > > Hello Carsten, > > i have opened already a ticket about that one month ago. It is already > assigned to ngvoice. ;-) > > https://github.com/kamailio/kamailio/issues/1644 > > Best regards, > > Henning > > -- > Henning Westerholt - https://skalatan.de/blog/ Kamailio security assessment > - https://skalatan.de/de/assessment

1 0

Sharing xavp’s between nodes.
by Igor Olhovskiy 17 Oct '18

17 Oct '18

Hi! Is there any possibility to share xavp’s between Kamailio nodes? Idea is to share result of ds_select_dst between several nodes and as 5.2 Kamailio stores result in xavp - need to share this structure as well Right now sharing between nodes is done on sht + dmq and I’m not sure I can save xavp in sht. Regards, Igor

3 3

kamcli v1.1.0 released
by Daniel-Constantin Mierla 17 Oct '18

17 Oct '18

Hello, kamcli tool just got its first official release, a step forward in the process of packaging it. It is a command line tool that aims to be a modern alternative to the venerable kamctl, being written in Python and having already a large set of implemented sub-commands, such as: * subscriber – manage SIP subscribers * ul – manage user location records * address – manage permissions address records * aliasdb – manage database aliases * db – manage kamailio database content * dialog – manage active calls (dialog) * dialplan – manage dialplan records * dispatcher – manage load balancer (dispatcher) * group – manage group membership records (acl) * moni – continuous refresh of the values for a list of statistics * mtree – manage memory trees (mtree) * ps – print the details for kamailio running processes * rpc – interact with kamailio via jsonrpc control commands (alias of jsonrpc) * rpcmethods – return the list of available RPC methods (commands) * speeddial – manage speed dial records * srv – server management commands (sockets, aliases, …) * stats – get kamailio internal statistics * tls – management commands for TLS profiles and connections * uptime – print the uptime for kamailio instance The news article for this release is available at: * https://www.kamailio.org/w/2018/10/kamcli-v1-1-0-released/ The corresponding tag in the github repository being: * https://github.com/kamailio/kamcli/releases/tag/v1.1.0 How to install kamcli and examples of usage can be found at: * https://github.com/kamailio/kamcli/blob/v1.1/README.md Cheers, Daniel -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

2 6

Kamailio topoh and t_check_trans not working.
by José Seabra 17 Oct '18

17 Oct '18

Hi all, I noticed that using the module TOPOH with the parameter mask call id enabled and the t_check_trans together isn't working correctly. When i receive the BYE message my script call the function t_check_trans() in order to check if a message belongs or is related to a transaction. This function always returns false when used with the topoh mask call id enabled, once that the BYE belongs to an existing dialog it must return true. In the logs it says something like transaction doesn't match dialog using the RFC3261. If the TOPOH mask call id option is disabled everything works perfectly. Anyone here already faced this behavior? Thanks Regards -- José Seabra

2 3

Missing documentation
by Pan Christensen 16 Oct '18

16 Oct '18

Hello. The documentation for the ims_usrloc_scscf module seems to be missing: Not Found The requested URL /docs/modules/stable/modules/ims_usrloc_scscf.html was not found on this server. ________________________________ Apache/2.4.10 (Debian) Server at www.kamailio.org Port 443 Pan B. Christensen Utvikler Phonect AS Mail: pan.christensen(a)phonect.no<mailto:pan.christensen@phonect.no> + 47 41 88 88 00 [mail_footer]

4 5

Re: [SR-Users] Problem with callid as htable key
by Daniel-Constantin Mierla 16 Oct '18

16 Oct '18

If no operator is matched in the first two characters of expression part for $shtcn(...), then regexp is used. That's because initially the $shtcn() was doing only regexp matching, later it was added support for additional operators. Yes, == is the operator for equal. Cheers, Daniel On 16.10.18 11:53, jenus(a)cyberchaos.nl wrote: > Daniel, > > Ok so if i'm correct i can prefix the callid with for example 1234 to > avoid matching the eq. In other words eq will only match the regex > code if the callid string starts with it? > > And by mathing on equal you mean: $shtcn(ht_test=>==$var(htid)) ? > > Thanks, > > Jan > > Daniel-Constantin Mierla schreef op 2018-10-16 10:16: >> Just to add that regexp matching when using keys from the sip message >> such as call-id is exposed further to some issues -- for example, it is >> common to have . (dot) in call-id, which for a regexp is matching any >> char, so a call id having 123.456 is matching 123x456. So depending on >> what you want to count, might be better to match by equal or prefix >> rules. >> >> Cheers, >> Daniel >> >> On 16.10.18 10:03, jenus(a)cyberchaos.nl wrote: >>> Daniel, >>> >>> Thanks for the quick response, that indeed solves my problem. >>> >>> >>> Jan >>> >>> Daniel-Constantin Mierla schreef op 2018-10-16 09:55: >>>> Hello, >>>> >>>> the expression in the $shtcn(table=>exp) can have some operators at >>>> the >>>> beginning, see: >>>> >>>> - >>>> https://www.kamailio.org/wiki/cookbooks/devel/pseudovariables#shtcn_htable_… >>>> >>>> >>>> >>>> So, eq is one of them, the safest is to explicitly set the operator if >>>> you cannot predict what is the key, like in this case. If the operator >>>> is missing, then the exp is matched as regular expression, so you can >>>> do: >>>> >>>> $shtcn(ht_test=>~~$var(htid)) >>>> >>>> Cheers, >>>> Daniel >>>> >>>> >>>> On 16.10.18 09:47, jenus(a)cyberchaos.nl wrote: >>>>> Hello, >>>>> >>>>> I'm running kamailio 5.1.4 and running into a issue with htable. I >>>>> use >>>>> it to store some dialog data so i can use it in a http route. When i >>>>> use the callid as a key it creates a issue for callid's starting with >>>>> eq. Here some example code that i use to reproduce the issue: >>>>> >>>>> >>>>> modparam("htable", "htable", "ht_test=>size=16;autoexpire=10") >>>>> >>>>> $var(htable-val) = $_s($dlg(h_entry)) + "::" + $_s($dlg(h_id)) + "::" >>>>> + $Ts; >>>>> xlog("L_WARN", "HT_TEST: Adding $var(htable-val) to ht_test with key >>>>> eq1234"); >>>>> $var(htid) = "eq1234"; >>>>> $sht(ht_test=>$var(htid)) = $var(htable-val); >>>>> $var(htable-val) = $null; >>>>> >>>>> if ($shtcn(ht_test=>$var(htid)) > 0) >>>>> { >>>>> xlog("L_WARN", "HT_TEST: Key eq1234 found!"); >>>>> } else { >>>>> xlog("L_WARN", "HT_TEST: Key eq1234 NOT found!"); >>>>> } >>>>> $var(htid) = $null; >>>>> >>>>> Results in : >>>>> >>>>> Oct 16 09:36:31 sip03 /usr/sbin/kamailio[22344]: WARNING: <script>: >>>>> HT_TEST: Adding 531::926::1539675391 to ht_test with key eq1234 >>>>> Oct 16 09:36:31 sip03 /usr/sbin/kamailio[22344]: WARNING: <script>: >>>>> HT_TEST: Key eq1234 NOT found! >>>>> >>>>> >>>>> When i prefix eq with a 1 it works fine: >>>>> >>>>> modparam("htable", "htable", "ht_test=>size=16;autoexpire=10") >>>>> >>>>> $var(htable-val) = $_s($dlg(h_entry)) + "::" + $_s($dlg(h_id)) + "::" >>>>> + $Ts; >>>>> xlog("L_WARN", "HT_TEST: Adding $var(htable-val) to ht_test with key >>>>> eq1234"); >>>>> $var(htid) = "1eq1234"; >>>>> $sht(ht_test=>$var(htid)) = $var(htable-val); >>>>> $var(htable-val) = $null; >>>>> >>>>> if ($shtcn(ht_test=>$var(htid)) > 0) >>>>> { >>>>> xlog("L_WARN", "HT_TEST: Key eq1234 found!"); >>>>> } else { >>>>> xlog("L_WARN", "HT_TEST: Key eq1234 NOT found!"); >>>>> } >>>>> $var(htid) = $null; >>>>> >>>>> Results in: >>>>> >>>>> Oct 16 09:37:25 sip03 /usr/sbin/kamailio[22555]: WARNING: <script>: >>>>> HT_TEST: Adding 3050::1098::1539675445 to ht_test with key eq1234 >>>>> Oct 16 09:37:25 sip03 /usr/sbin/kamailio[22555]: WARNING: <script>: >>>>> HT_TEST: Key eq1234 found! >>>>> >>>>> >>>>> Am i running into a bug? Or are there some restrictions on the >>>>> key's i >>>>> can use? I'm still going trough the logs to check if there are more >>>>> callid's that have a issue with matching. >>>>> >>>>> >>>>> Thanks, >>>>> >>>>> Jan Hazenberg >>>>> >>>>> _______________________________________________ >>>>> Kamailio (SER) - Users Mailing List >>>>> sr-users(a)lists.kamailio.org >>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users >>> > -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

1 0

Re: [SR-Users] Problem with callid as htable key
by Daniel-Constantin Mierla 16 Oct '18

16 Oct '18

Just to add that regexp matching when using keys from the sip message such as call-id is exposed further to some issues -- for example, it is common to have . (dot) in call-id, which for a regexp is matching any char, so a call id having 123.456 is matching 123x456. So depending on what you want to count, might be better to match by equal or prefix rules. Cheers, Daniel On 16.10.18 10:03, jenus(a)cyberchaos.nl wrote: > Daniel, > > Thanks for the quick response, that indeed solves my problem. > > > Jan > > Daniel-Constantin Mierla schreef op 2018-10-16 09:55: >> Hello, >> >> the expression in the $shtcn(table=>exp) can have some operators at the >> beginning, see: >> >> - >> https://www.kamailio.org/wiki/cookbooks/devel/pseudovariables#shtcn_htable_… >> >> >> So, eq is one of them, the safest is to explicitly set the operator if >> you cannot predict what is the key, like in this case. If the operator >> is missing, then the exp is matched as regular expression, so you can >> do: >> >> $shtcn(ht_test=>~~$var(htid)) >> >> Cheers, >> Daniel >> >> >> On 16.10.18 09:47, jenus(a)cyberchaos.nl wrote: >>> Hello, >>> >>> I'm running kamailio 5.1.4 and running into a issue with htable. I use >>> it to store some dialog data so i can use it in a http route. When i >>> use the callid as a key it creates a issue for callid's starting with >>> eq. Here some example code that i use to reproduce the issue: >>> >>> >>> modparam("htable", "htable", "ht_test=>size=16;autoexpire=10") >>> >>> $var(htable-val) = $_s($dlg(h_entry)) + "::" + $_s($dlg(h_id)) + "::" >>> + $Ts; >>> xlog("L_WARN", "HT_TEST: Adding $var(htable-val) to ht_test with key >>> eq1234"); >>> $var(htid) = "eq1234"; >>> $sht(ht_test=>$var(htid)) = $var(htable-val); >>> $var(htable-val) = $null; >>> >>> if ($shtcn(ht_test=>$var(htid)) > 0) >>> { >>> xlog("L_WARN", "HT_TEST: Key eq1234 found!"); >>> } else { >>> xlog("L_WARN", "HT_TEST: Key eq1234 NOT found!"); >>> } >>> $var(htid) = $null; >>> >>> Results in : >>> >>> Oct 16 09:36:31 sip03 /usr/sbin/kamailio[22344]: WARNING: <script>: >>> HT_TEST: Adding 531::926::1539675391 to ht_test with key eq1234 >>> Oct 16 09:36:31 sip03 /usr/sbin/kamailio[22344]: WARNING: <script>: >>> HT_TEST: Key eq1234 NOT found! >>> >>> >>> When i prefix eq with a 1 it works fine: >>> >>> modparam("htable", "htable", "ht_test=>size=16;autoexpire=10") >>> >>> $var(htable-val) = $_s($dlg(h_entry)) + "::" + $_s($dlg(h_id)) + "::" >>> + $Ts; >>> xlog("L_WARN", "HT_TEST: Adding $var(htable-val) to ht_test with key >>> eq1234"); >>> $var(htid) = "1eq1234"; >>> $sht(ht_test=>$var(htid)) = $var(htable-val); >>> $var(htable-val) = $null; >>> >>> if ($shtcn(ht_test=>$var(htid)) > 0) >>> { >>> xlog("L_WARN", "HT_TEST: Key eq1234 found!"); >>> } else { >>> xlog("L_WARN", "HT_TEST: Key eq1234 NOT found!"); >>> } >>> $var(htid) = $null; >>> >>> Results in: >>> >>> Oct 16 09:37:25 sip03 /usr/sbin/kamailio[22555]: WARNING: <script>: >>> HT_TEST: Adding 3050::1098::1539675445 to ht_test with key eq1234 >>> Oct 16 09:37:25 sip03 /usr/sbin/kamailio[22555]: WARNING: <script>: >>> HT_TEST: Key eq1234 found! >>> >>> >>> Am i running into a bug? Or are there some restrictions on the key's i >>> can use? I'm still going trough the logs to check if there are more >>> callid's that have a issue with matching. >>> >>> >>> Thanks, >>> >>> Jan Hazenberg >>> >>> _______________________________________________ >>> Kamailio (SER) - Users Mailing List >>> sr-users(a)lists.kamailio.org >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users > -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- www.kamailioworld.com Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

2 1

Problem with callid as htable key
by jenus＠cyberchaos.nl 16 Oct '18

16 Oct '18

Hello, I'm running kamailio 5.1.4 and running into a issue with htable. I use it to store some dialog data so i can use it in a http route. When i use the callid as a key it creates a issue for callid's starting with eq. Here some example code that i use to reproduce the issue: modparam("htable", "htable", "ht_test=>size=16;autoexpire=10") $var(htable-val) = $_s($dlg(h_entry)) + "::" + $_s($dlg(h_id)) + "::" + $Ts; xlog("L_WARN", "HT_TEST: Adding $var(htable-val) to ht_test with key eq1234"); $var(htid) = "eq1234"; $sht(ht_test=>$var(htid)) = $var(htable-val); $var(htable-val) = $null; if ($shtcn(ht_test=>$var(htid)) > 0) { xlog("L_WARN", "HT_TEST: Key eq1234 found!"); } else { xlog("L_WARN", "HT_TEST: Key eq1234 NOT found!"); } $var(htid) = $null; Results in : Oct 16 09:36:31 sip03 /usr/sbin/kamailio[22344]: WARNING: <script>: HT_TEST: Adding 531::926::1539675391 to ht_test with key eq1234 Oct 16 09:36:31 sip03 /usr/sbin/kamailio[22344]: WARNING: <script>: HT_TEST: Key eq1234 NOT found! When i prefix eq with a 1 it works fine: modparam("htable", "htable", "ht_test=>size=16;autoexpire=10") $var(htable-val) = $_s($dlg(h_entry)) + "::" + $_s($dlg(h_id)) + "::" + $Ts; xlog("L_WARN", "HT_TEST: Adding $var(htable-val) to ht_test with key eq1234"); $var(htid) = "1eq1234"; $sht(ht_test=>$var(htid)) = $var(htable-val); $var(htable-val) = $null; if ($shtcn(ht_test=>$var(htid)) > 0) { xlog("L_WARN", "HT_TEST: Key eq1234 found!"); } else { xlog("L_WARN", "HT_TEST: Key eq1234 NOT found!"); } $var(htid) = $null; Results in: Oct 16 09:37:25 sip03 /usr/sbin/kamailio[22555]: WARNING: <script>: HT_TEST: Adding 3050::1098::1539675445 to ht_test with key eq1234 Oct 16 09:37:25 sip03 /usr/sbin/kamailio[22555]: WARNING: <script>: HT_TEST: Key eq1234 found! Am i running into a bug? Or are there some restrictions on the key's i can use? I'm still going trough the logs to check if there are more callid's that have a issue with matching. Thanks, Jan Hazenberg

2 2

Problem with Kamailio 4.2.0
by José Antonio Gutiérrez Delgado 16 Oct '18

16 Oct '18

Hi, I'm using Kamailio 4.2.0 and I'm developing a SIP-based application. Today I made a test connecting two devices directly to an S7 sharing the Internet, I usually use a VPN even if they are both connected to the same network because in the future they will be in different networks.Without the VPN calls were not received. This has never happened to me, I have repeated tests and in an S6 it has also happened to me. So I have checked my Kamailio server and I have detected that when executing: kamctl ul show, the received field did not appear: With VPN: Contact:: sip:pruebaT@47.60.42.40:10924;transport=udp Q= Expires:: 1992 Callid:: iwNoYb~QR- Cseq:: 21 User-agent:: Unknown (belle-sip/1.6.1) Received:: sip:47.60.42.40:10924 State:: CS_NEW Flags:: 0 Cflag:: 64 Socket:: udp:10.0.0.4:5060 Methods:: 4294967295 Ruid:: uloc-5a9d9097-9fa-431c Instance:: <urn:uuid:8b50dde3-d07f-4752-9a24-7b8ddf219a99> Reg-Id:: 0 Last-Keepalive:: 1539614732 Last-Modified:: 1539614732 Without VPN: Contact:: sip:pruebaT@37.10.156.189:51163;transport=udp Q= Expires:: 1996 Callid:: webjvHycBs Cseq:: 21 User-agent:: Unknown (belle-sip/1.6.1) State:: CS_NEW Flags:: 0 Cflag:: 0 Socket:: udp:10.0.0.4:5060 Methods:: 4294967295 Ruid:: uloc-5a9d9097-9fc-1feb Instance:: <urn:uuid:89306a81-e2d1-4b7a-8206-107e3cbc0688> Reg-Id:: 0 Last-Keepalive:: 1539614531 Last-Modified:: 1539614531 Would someone know why it happened? Thanks -- José Antonio Gutiérrez Delgado Responsable técnico Oficina: (+34) 923040031 <http://www.arsoft-company.com/> *Este mensaje se dirige exclusivamente a su destinatario/s y puede contener información privilegiada o confidencial. Si no es vd. el destinatario indicado, queda notificado de que la utilización, divulgación y/o copia sin autorización está prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción.* *Antes de imprimir, piensa si es necesario. Cuidar el medioambiente es tarea de todos.*

3 2

Hi guys,
by shailendra kumar 15 Oct '18

15 Oct '18

I am fresher and want to learn about Kamailio Soft switch, Anyone can provide me link or document from where i can learn. I will be thankful for such help, Thanks & Regards, Shailendra Kumar

2 1

Subscription from asterisk
by willy 15 Oct '18

15 Oct '18

Hello all. I'm trying to share states and presence from kamailio between asterisks. Is there a way to do this in kamailio? Thank you, willy d

2 1

SDP in fifth 200 OK is not the same as in first four
by Roman Romanchenko 15 Oct '18

15 Oct '18

Hi all, I have an issue with SDP from Kamailio side in the following scenario: simple call from A to B. When B answers a call and sends '200 OK' to A, A delays ACK for a while, so '200 OK' re-transmission happens. After the fourth try to re-send '200 OK' towards A, Kamailio changes SDP (specifically connection information 'c', IP address become address of A instead of proxy IP as it was in the previous attempts). At some point A sends ACK and call is established, but last received '200 OK' has invalid SDP and it prevents successful media establishment. I wonder if there any re-transmission counter or whatever what can affect this scenario and change SDP? Roman Romanchenko VoIP devel Sipwise GmbH

2 1

Dialog variables and persistence
by Alex Balashov 15 Oct '18

15 Oct '18

Hi, I forget, can $dlg_var(...) variables nowadays be reconstituted, along with dialog state in general, using database backing? What about profile membership? Last time I brushed with this topic was probably in 4.x days, and as I remember the general idea was that dialog state could be recovered on restart, but without dialog variables or profile counts. Is this accurate? Is it still true? Or has the amount of state serialised into database persistence increased since then? Thanks much! -- Alex -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/, http://www.csrpswitch.com/

2 1

UPDATE relayed from wrong socket
by Sergiu Pojoga 15 Oct '18

15 Oct '18

Hi ppl, I have this problem with call transfer, may be someone can help. The phone to the far right is registered with the Registrar to the far left using two PATH headers (trespassing two proxy ports, 5070 then 5060). As you can see in the graph below, after receiving the UPDATE request, Kamailio relays it further from port 5060, I expect it to be from 5070 just like the dialog forming INVITE and the CANCEL afterwards. [image: image.png] The UPDATE has a to-tag, but unlike the original INVITE - it has no Route header!??? route[*WITHINDLG*] { if (!has_totag()) return; if (loose_route()) { route(DLGURI); if (is_method("BYE")) { ... } else if ( is_method("ACK") ) { route(NATMANAGE); } else if ( is_method("NOTIFY") ) { record_route(); } route(RELAY); exit; } if ( is_method("ACK") ) { ... } # handle UPDATE method for in-dialog requests if (is_method("*UPDATE*")) { route(DLGURI); record_route(); route(RELAY); } } Thanks in advance.

2 7

Distorted uri / Route header replaces the uri
by Abdulaziz Alghosh 15 Oct '18

15 Oct '18

Greetings, in order to upgrade kamailio server from 3.0.3 to 5.1.4 version, I am conducting test calls and it is not completelly successful. The main components I have are: 1- Media Gateway (Asterisk) : 192.168.226.133 2- Signalling Gateway (Kamailio 5.1.4) 192.168.226.132 3- Global Dispatcher (Kamailio 3.0.3 in front of the Signalling Gateway.) : 192.168.226.130 Both caller and callee have the dispatcher's IP as a proxy and their registration requests is passed to be registered at the Signalling Gateway (Kamailio 5.1.4) and saved on the MySQL server. The caller reaches the callee properly, who in its turn answeres the call and sends the OK msg to the caller who gets it. Unfortunately, when the caller sends the ACK for this INVITE to the callee, the ACK does not reach the callee because it is trapped by the dispatcher at the last stage because the uri was dropped and the Route header was used instead. This behaviour is abnormal since as I know the Route header should be converted into a Via header and the uri stays untouchable. The ACK was looped into the dispatcher itself .i.e. the dispatcher sent it to itself adding always the via header ""Via: SIP/2.0/UDP 192.168.226.130;branch=0"" endlessly. Once again, here is an example of the ACK before the dispatcher and how the dispatcher forwards the ACK afterwards. the supposed path is as following: caller --> GDP--> SGW --> MGW--> SGW --> GDP --> callee Although the GDP (before the calle after the SGW) received the uri well from SGW inside the ACK as it appears below: ACK sip:yyyyyyyyyyyy@192.168.226.130:5060;rinstance=1608f7c153f40093;transport=UDP SIP/2.0 Record-Route: <sip:192.168.226.132;lr=on;ftag=as3b989c5f> Via: SIP/2.0/UDP 192.168.226.132;branch=z9hG4bK136f.1e8349c235fff01ee1849f3456f8868a.0 Via: SIP/2.0/UDP 192.168.226.133:5060;rport=5060;branch=z9hG4bK34871fe9 Route: <sip:192.168.226.130;lr;ftag=as3b989c5f;did=d5b.87890dc6> Max-Forwards: 69 From: "xxxxxxxxxxxxxx" <sip:xxxxxxxxxxxx@domain.com>;tag=as3b989c5f To: <sip:yyyyyyyyyyyyy@192.168.226.132:5060>;tag=1af2c424 Contact: <sip:xxxxxxxxx@192.168.226.133:5060> Call-ID: 7ed2ab533d4c43086746d0e620bdff06(a)domain.com CSeq: 102 ACK User-Agent: MGW Content-Length: 0 The global dipstacher (GDP) has used the Route header (which has no R-URI yyyyyyyyy) instead of the uri: ACK sip:192.168.226.130;lr;ftag=as3b989c5f;did=d5b.87890dc6 SIP/2.0 Record-Route: <sip:192.168.226.132;lr=on;ftag=as3b989c5f> Via: SIP/2.0/UDP 192.168.226.130;branch=0 Via: SIP/2.0/UDP 192.168.226.132;rport=5060;branch=z9hG4bK136f.1e8349c235fff01ee1849f3456f8868a.0 Via: SIP/2.0/UDP 192.168.226.133:5060;rport=5060;branch=z9hG4bK34871fe9 Max-Forwards: 68 From: "xxxxxxxxxx" <sip:xxxxxxxxxxx@domain.com>;tag=as3b989c5f To: <sip:yyyyyyyyy@192.168.226.132:5060>;tag=1af2c424 Contact: <sip:xxxxxxx@192.168.226.132:5060> Call-ID: 7ed2ab533d4c43086746d0e620bdff06(a)domain.com CSeq: 102 ACK User-Agent: MGW Content-Length: 0 Thanks in advance for your contribution Abdulaziz

2 1

DIALPLAN Module: doubts about regular expression usage
by Stefano Bertuola 15 Oct '18

15 Oct '18

Hi Experts. I did some tests with DIALPLAN module and I have some doubts about how to define the regular expressions in the database. For example, using the start character '^' (beginning of the string), it looks not working: kamcmd> dialplan.dump 1 { DPID: 1 ENTRIES: { ENTRY: { PRIO: 1 MATCHOP: 2 MATCHEXP: ^(\+39)(.*)$ MATCHLEN: 0 SUBSTEXP: ^(\+39)(.*)$ REPLEXP: \2 ATTRS: 1 } } } kamcmd> dialplan.translate 1 "+39123456" error: 500 - No translation Removing it, it works... but not as desired: kamcmd> dialplan.dump 1 { DPID: 1 ENTRIES: { ENTRY: { PRIO: 1 MATCHOP: 1 MATCHEXP: (\+39)(.*)$ MATCHLEN: 0 SUBSTEXP: (\+39)(.*)$ REPLEXP: \2 ATTRS: 1 } } } kamcmd> dialplan.translate 1 "+39123456" { Output: 123456" Attributes: 1 } kamcmd> dialplan.translate 1 "xxxxxxx+39123456" { Output: 123456" Attributes: 1 } Can someone help me understand how the regular expression should be used in DIALPLAN, please? Br. Stefano

4 8

DIALPLAN Module: how to get/use the Attributes value
by Stefano Bertuola 14 Oct '18

14 Oct '18

Hi experts. I intended ATTRIBUTES is a value that is returned by dialplan's dp_translate as the result as shown by kamcmd command: kamcmd> dialplan.translate 2 s:+3912345 { Output: 3912345 Attributes: test } Is my understanding correct? I tried many ways, including using AVP and XAVP for the result, but no success: dp_translate("2", "$rU/$xavp(dp_result)"); pv_xavp_print(); DEBUG: dialplan [dialplan.c:222]: dp_get_ivalue(): dpid is 2 from constant argument DEBUG: dialplan [dialplan.c:243]: dp_get_svalue(): searching 7 DEBUG: dialplan [dialplan.c:331]: dp_translate_f(): input is +3912345 DEBUG: dialplan [dp_repl.c:592]: translate(): regex operator testing over [+3912345] DEBUG: dialplan [dp_repl.c:662]: translate(): found a matching rule 0x7f56aef690d8: pr 1, match_exp ^\+39..... DEBUG: dialplan [dp_repl.c:481]: rule_translate(): copying match <3912345> token size 2 DEBUG: dialplan [dialplan.c:340]: dp_translate_f(): input +3912345 with dpid 2 => output 3912345 INFO: <core> [xavp.c:494]: xavp_print_list_content(): +++++ start XAVP list: 0x7f56aeffaaa8 (level=0) INFO: <core> [xavp.c:498]: xavp_print_list_content(): *** XAVP name: dp_result INFO: <core> [xavp.c:499]: xavp_print_list_content(): XAVP id: 3539756229 INFO: <core> [xavp.c:500]: xavp_print_list_content(): XAVP value type: 2 INFO: <core> [xavp.c:509]: xavp_print_list_content(): XAVP value: 3912345 INFO: <core> [xavp.c:531]: xavp_print_list_content(): ----- end XAVP list: 0x7f56aeffaaa8 (level=0) If possible, how can I get both OUTPUT and ATTRIBUTES as result? Stefano

2 1

db_mysql when compiling Kamailio
by Wilkins, Steve 12 Oct '18

12 Oct '18

Hello All, When db_mysql is selected in the make, the make looks for -lmariadb. However, I want MySQL, not mariadb. Is there a way to let the make know that MySQL is preferred ov mariadb? Thank you

2 1

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