sr-users January 2015

sr-users@lists.kamailio.org

94 participants
134 discussions

Start a nNew thread

why do not support tcp:eth1:5062，only support eht1:5062

by 张顺通

why do not support tcp:eth1:5062，only support eht1:5062? I need to bind on eth1 only tcp.

9 years, 9 months

tls_port_no maybe do not work

by 张顺通

I set cfg like this: tls_port_no=9004 listen=bond0:9002 but result is: udp: 10.232.98.23 [10.232.98.23]:9002 tcp: 10.232.98.23 [10.232.98.23]:9002 tls: 10.232.98.23 [10.232.98.23]:9003

9 years, 9 months

Wrong location entries when using usrloc with Mongo

by Mickael Marrache

Hi, I start with no location nor in Mongo, nor in memory. My UA registers successfully and I can see the location entry in Mongo. Then, I close my UA which unregisters (by setting Expires header to 0). Then, I open the app again and a new registration is made. The entry after first registration. Looks okay. { "_id" : ObjectId("54cb38f684e58133783f2b42"), "username" : "A", "contact" : "sip:A@192.168.1.3:54217;rinstance=DFAEBBC7;transport=tcp", "expires" : ISODate("2015-01-30T08:55:34Z"), "q" : -1, "callid" : "297EC55073A07BF78F0C05822A6CCDFB47E48705", "cseq" : 8809, "flags" : 0, "cflags" : 0, "user_agent" : "Acrobits Softphone Business/3.1", "received" : "sip:XXXXXXXXXXX:54217;transport=tcp", "path" : "<sip:XXXXXXXXXX;lr;received=sip:XXXXXXXXXXX:54217%3Btransport%3Dtcp>", "socket" : "udp:XXXXXXXXX:5060", "methods" : 4751, "last_modified" : ISODate("2015-01-30T07:55:34Z"), "ruid" : "uloc-54cb38df-3378-2", "instance" : null, "reg_id" : 0 } The same entry after un register (Expires 0). Note that the username field is missing. In any case, I expected the entry to be deleted. { "_id" : ObjectId("54cb38f684e58133783f2b42"), "expires" : ISODate("2015-01-30T08:56:51Z"), "q" : -1, "cseq" : 8811, "flags" : 0, "cflags" : 0, "user_agent" : "Acrobits Softphone Business/3.1", "received" : "sip: XXXXXXXXX:54217;transport=tcp", "path" : "<sip: XXXXXXXXX;lr;received=sip: XXXXXXXXX:54217%3Btransport%3Dtcp>", "socket" : "udp: XXXXXXXXX:5060", "methods" : 4751, "last_modified" : ISODate("2015-01-30T07:56:51Z"), "callid" : "297EC55073A07BF78F0C05822A6CCDFB47E48705", "instance" : null, "reg_id" : 0, "contact" : "sip:A@192.168.1.3:54217;rinstance=DFAEBBC7;transport=tcp" } The entries after second registration. The new entry looks okay. But, the old entry is still here. { "_id" : ObjectId("54cb38f684e58133783f2b42"), "expires" : ISODate("2015-01-30T08:56:51Z"), "q" : -1, "cseq" : 8811, "flags" : 0, "cflags" : 0, "user_agent" : "Acrobits Softphone Business/3.1", "received" : "sip: XXXXXXXXX:54217;transport=tcp", "path" : "<sip: XXXXXXXXX;lr;received=sip: XXXXXXXXX:54217%3Btransport%3Dtcp>", "socket" : "udp: XXXXXXXXX:5060", "methods" : 4751, "last_modified" : ISODate("2015-01-30T07:56:51Z"), "callid" : "297EC55073A07BF78F0C05822A6CCDFB47E48705", "instance" : null, "reg_id" : 0, "contact" : "sip:A@192.168.1.3:54217;rinstance=DFAEBBC7;transport=tcp" } { "_id" : ObjectId("54cb3a7884e581337a25b895"), "username" : "A", "contact" : "sip:A@192.168.1.3:54217;rinstance=DFAEBBC7;transport=tcp", "expires" : ISODate("2015-01-30T09:02:00Z"), "q" : -1, "callid" : "297EC55073A07BF78F0C05822A6CCDFB47E48705", "cseq" : 8813, "flags" : 0, "cflags" : 0, "user_agent" : "Acrobits Softphone Business/3.1", "received" : "sip: XXXXXXXXX:54217;transport=tcp", "path" : "<sip: XXXXXXXXX;lr;received=sip: XXXXXXXXX:54217%3Btransport%3Dtcp>", "socket" : "udp: XXXXXXXXX:5060", "methods" : 4751, "last_modified" : ISODate("2015-01-30T08:02:00Z"), "ruid" : "uloc-54cb38df-337a-1", "instance" : null, "reg_id" : 0 } The issue is the entry is not deleted after un registering. I precise that registrations are dispatched over multiple registrars with all accesses the same Mongo cluster. Thanks, Mickael

9 years, 9 months

Can kamailio generate a PRACK

by Rahul MathuR

Hello, I was wondering whether Kamailio (as proxy) can generate a PRACK on its own ( since one of the custom written dialer is not sending PRACK) ? Is there any way I can achieve this ? -- Warm Regds. MathuRahul

9 years, 9 months

Core dump while saving user location in mongo

by Mickael Marrache

Hi, When my proxy receives a REGISTER request, it crashes while saving the user location in MongoDB. This is the backtrace from the core dump: #0 0x0000003f08e32625 in raise () from /lib64/libc.so.6 #1 0x0000003f08e33e05 in abort () from /lib64/libc.so.6 #2 0x00000000006196f9 in fm_free (qm=0x7f4368bf7010, p=0x210add0, file=0x7f4367fd7608 "<core>: db_res.c", func=0x7f4367fd8100 "db_free_columns", line=86) at mem/f_malloc.c:588 #3 0x00007f4367fc37ab in db_free_columns (_r=0x7f4368ca0430) at db_res.c:86 #4 0x00007f4367fc479e in db_free_result (_r=0x7f4368ca0430) at db_res.c:134 #5 0x00007f4367da37cb in db_mongodb_free_result (_h=0x7f4368c94718, _r=0x7f4368ca0430) at mongodb_dbase.c:646 #6 0x00007f4367da5d65 in db_mongodb_query (_h=0x7f4368c94718, _k=0x7fffa03d5550, _op=0x0, _v=0x7fffa03d5510, _c=0x7fffa03d5560, _n=1, _nc=16, _o=0x7f4365ed2c80, _r=0x7fffa03d5508) at mongodb_dbase.c:783 #7 0x00007f4365cac7d2 in db_load_urecord (_c=0x7f4368c94718, _d=0x7f436154a0e8, _aor=0x7fffa03d59d0) at udomain.c:601 #8 0x00007f4365cb1e8e in get_urecord (_d=0x7f436154a0e8, _aor=0x7fffa03d59d0, _r=0x7fffa03d5760) at udomain.c:1106 #9 0x00007f4365a75dea in add_contacts (_m=0x7f4368cbdc40, _d=0x7f436154a0e8, _a=0x7fffa03d59d0, _mode=1, _use_regid=1) at save.c:832 #10 0x00007f4365a77d32 in save (_m=0x7f4368cbdc40, _d=0x7f436154a0e8, _cflags=4, _uri=0x0) at save.c:986 #11 0x00007f4365a606db in w_save2 (_m=0x7f4368cbdc40, _d=0x7f436154a0e8 "H\240TaC\177", _cflags=0x4 <Address 0x4 out of bounds>) at reg_mod.c:447 #12 0x000000000041d489 in do_action (h=0x7fffa03d6180, a=0x7f4368c71e98, msg=0x7f4368cbdc40) at action.c:1100 #13 0x0000000000429a7a in run_actions (h=0x7fffa03d6180, a=0x7f4368c71e98, msg=0x7f4368cbdc40) at action.c:1583 #14 0x000000000042a0df in run_actions_safe (h=0x7fffa03d7470, a=0x7f4368c71e98, msg=0x7f4368cbdc40) at action.c:1648 #15 0x0000000000540b7c in rval_get_int (h=0x7fffa03d7470, msg=0x7f4368cbdc40, i=0x7fffa03d6658, rv=0x7f4368c72830, cache=0x0) at rvalue.c:924 #16 0x0000000000544db4 in rval_expr_eval_int (h=0x7fffa03d7470, msg=0x7f4368cbdc40, res=0x7fffa03d6658, rve=0x7f4368c72828) at rvalue.c:1918 #17 0x00000000005451aa in rval_expr_eval_int (h=0x7fffa03d7470, msg=0x7f4368cbdc40, res=0x7fffa03d6ae0, rve=0x7f4368c72070) at rvalue.c:1926 #18 0x000000000041ce4e in do_action (h=0x7fffa03d7470, a=0x7f4368c73148, msg=0x7f4368cbdc40) at action.c:1064 #19 0x0000000000429a7a in run_actions (h=0x7fffa03d7470, a=0x7f4368c71cc0, msg=0x7f4368cbdc40) at action.c:1583 #20 0x0000000000419dea in do_action (h=0x7fffa03d7470, a=0x7f4368c3bdb8, msg=0x7f4368cbdc40) at action.c:712 #21 0x0000000000429a7a in run_actions (h=0x7fffa03d7470, a=0x7f4368c33898, msg=0x7f4368cbdc40) at action.c:1583 #22 0x000000000042a1a7 in run_top_route (a=0x7f4368c33898, msg=0x7f4368cbdc40, c=0x0) at action.c:1669 #23 0x000000000050747e in receive_msg ( buf=0xa6f780 "REGISTER sip:XXXXXXXXXXXX:5060;transport=tcp SIP/2.0\r\nVia: SIP/2.0/UDP XXXXXXXXX;branch=z9hG4bK242c.26de52a75c8675f6757e0958454a0ad5.0;i=1\r\nv: SIP/2.0/TCP XXXXXXXXXX:62051;received=XXXXXXXX"..., len=1004, rcv_info=0x7fffa03d7760) at receive.c:216 #24 0x0000000000606e76 in udp_rcv_loop () at udp_server.c:521 #25 0x00000000004a5c97 in main_loop () at main.c:1629 #26 0x00000000004aaf2a in main (argc=13, argv=0x7fffa03d7b78) at main.c:2561 I tested multiple times, it occurs everytime. Let me know if you need more information. Thanks, Mickael

9 years, 9 months

Does forking impact max_inv_lifetime?

by Alex Balashov

Hi, In this serial forking-based failover scenario UAC --> Proxy --> UAS 1 UAS 2 ... UAS 3 I've got a requirement to terminate the call and return an error to the UAC if there is no final response within 60 seconds. The usual fr_inv_timer / restart_fr_on_each_reply combination won't do, because even when restart_fr_on_each_reply == 0, the timer is still restarted on provisional replies of increasing response code value (e.g. 183 after 180). As the documentation states, fr_inv_timer is a branch-level construct anyway, so this approach doesn't make sense here. That's why I looked into max_inv_lifetime. However, when I set it to 60000, I still get the same result, but only when there are new branches being formed on the proxy -> UAS side. It works fine if there is no forking and a single gateway does not provide a final reply within 60 seconds. So, my sense is that the max_inv_lifetime timeout is reset when a new branch is created to UAS 2...UAS N. Is this accurate? Thanks, -- Alex Balashov - Principal Evariste Systems LLC 235 E Ponce de Leon Ave Suite 106 Decatur, GA 30030 United States Tel: +1-678-954-0670 Web: http://www.evaristesys.com/, http://www.alexbalashov.com/

9 years, 9 months

gruu within dialog

by samuel

Hi all, I'm having some issues treating requests within dialogs with gruu enabled with kamailio 4.1.2. I've got the "standard" configuration of WITHIN route with the adition of the next lines: if(is_gruu()){ route(LOCATION); }; before the the RELAY route call in the loose_route section. The "problem" is that the ACK with a pub-gruu on the Req-URI is not properly lookup. In the logs I can see the following statements: 2(4232) DEBUG: registrar [lookup.c:123]: lookup(): looking up pub gruu [urn:uuid:d63b1c4f-d7dc-4f4e-87f1-948123266dc0] 2(4232) DEBUG: registrar [lookup.c:158]: lookup(): 'sam(a)A.B.C.D' Not found in usrloc Where A.B.C.D is the local IP of the UA. Looking at the code, this last line looks like is looking for the "standard" URI (username@domain) instead of using the pub gruu. Am I right with this assumption or am I missing something from the code? As far as I could look, it looks like there's an exit -1 statement in the line 158 of lookup.c which disables the following gruu treatment. Since the username with IP is not registered, this ACK is lost and the sesion is not stablished (lost ACK). Can anyone provide some hints why is this failing? Thanks a lot in advance! Samuel.

9 years, 9 months

Dialog module is crashing after setting track_cseq_updates to 1

by Fernando Aquilino

Hi, after setting track_cseq_updates to 1 in module dialog (and calling dlg_manage() from request_route) I'm getting reproducible crashes in both stable (4.2.2) and dev (4.3.0-dev3, 2015-01-28) releases. I made the change to cope with CSeq not being incremented when sending another INVITE with authentication information with by calling uac_auth()/append_branch()/t_relay(). The SIP trunk on the asterisk server I'm forwarding the request to requires so and sends me an "401 Unauthorized" message after the first INVITE. Anyone using it would help me with the configuration? Should I post to the dev list? Thanks for any help, Fernando Aquilino -------------------- kamailio.cfg -------------------- modparam("uac","credential","username:domain:password") modparam("uac","auth_realm_avp","$avp(i:101)") modparam("uac","auth_username_avp","$avp(i:102)") modparam("uac","auth_password_avp","$avp(i:103)") modparam("uac","restore_mode","none") modparam("dialog", "track_cseq_updates", 1) modparam("dialog", "dlg_flag", 4) ... failure_route["serial"] { if (t_check_status("401|407")) { if (isflagset(auth_sent)) { xlog("Authentication failed on SIP Trunk: $ru"); } else { #realm $avp(i:101) = "asterisk"; #username $avp(i:102) = "user123"; #password $avp(i:103) = "pass123"; if (uac_auth()) { setflag(auth_sent); t_on_failure("serial"); append_branch(); t_relay(); } } exit; } if (!t_next_contacts()) { exit; } t_on_failure("serial"); t_relay(); } ------------------------------------------------------------ -------------------- debug log -------------------- Jan 28 17:40:12 kamailio /usr/sbin/kamailio[9838]: DEBUG: dialog [dlg_cseq.c:215]: dlg_cseq_msg_sent(): traking cseq updates Jan 28 17:40:12 kamailio /usr/sbin/kamailio[9838]: DEBUG: dialog [dlg_hash.c:633]: dlg_lookup(): ref dlg 0x7f9eeb4aec20 with 1 -> 2 Jan 28 17:40:12 kamailio /usr/sbin/kamailio[9838]: DEBUG: dialog [dlg_hash.c:635]: dlg_lookup(): dialog id=9870 found on entry 2115 Jan 28 17:40:12 kamailio /usr/sbin/kamailio[9838]: DEBUG: dialog [dlg_cseq.c:249]: dlg_cseq_msg_sent(): uac auth request - cseq inc needed Jan 28 17:40:12 kamailio /usr/sbin/kamailio[9838]: DEBUG: dialog [dlg_var.c:248]: print_lists(): Internal var-list ((nil)): Jan 28 17:40:12 kamailio /usr/sbin/kamailio[9838]: DEBUG: dialog [dlg_var.c:258]: print_lists(): Dialog var-list (0x7f9eeb4b2f38): Jan 28 17:40:12 kamailio /usr/sbin/kamailio[9838]: DEBUG: dialog [dlg_var.c:263]: print_lists(): cseq_diff=1 (flags 1) Jan 28 17:40:12 kamailio /usr/sbin/kamailio[9856]: CRITICAL: <core> [pass_fd.c:275]: receive_fd(): EOF on 20 Jan 28 17:40:12 kamailio /usr/sbin/kamailio[9856]: DEBUG: <core> [tcp_main.c:3445]: handle_ser_child(): dead child 10, pid 9838 (shutting down?) Jan 28 17:40:12 kamailio /usr/sbin/kamailio[9856]: DEBUG: <core> [io_wait.h:598]: io_watch_del(): DBG: io_watch_del (0x96cfe0, 20, -1, 0x0) fd_no=37 called Jan 28 17:40:12 kamailio /usr/sbin/kamailio[9828]: ALERT: <core> [main.c:727]: handle_sigs(): child process 9838 exited by a signal 11 Jan 28 17:40:12 kamailio /usr/sbin/kamailio[9828]: ALERT: <core> [main.c:730]: handle_sigs(): core was not generated Jan 28 17:40:12 kamailio /usr/sbin/kamailio[9828]: INFO: <core> [main.c:742]: handle_sigs(): terminating due to SIGCHLD ------------------------------------------------------------ -------------------- core dump* -------------------- root@kamailio:/etc/kamailio# gdb kamailio core GNU gdb (GDB) 7.4.1-debian Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html > This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>... Reading symbols from /usr/sbin/kamailio...Reading symbols from /usr/lib/debug/.build-id/62/86ce2a5e0241120986e5ec3ed803be5b945076.debug...done. done. [New LWP 3077] warning: Can't read pathname for load map: Input/output error. [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by ` '. Program terminated with signal 11, Segmentation fault. #0 0x00007fbe4ba33dae in memcpy (__len=18446744073709551522, __src=0x7fbe47c9f121, __dest=0x7ffff12ada6d) at /usr/include/x86_64-linux-gnu/bits/string3.h:52 52 return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest)); (gdb) bt #0 0x00007fbe4ba33dae in memcpy (__len=18446744073709551522, __src=0x7fbe47c9f121, __dest=0x7ffff12ada6d) at /usr/include/x86_64-linux-gnu/bits/string3.h:52 #1 dlg_cseq_msg_sent (data=0x7ffff12bda40) at dlg_cseq.c:298 #2 0x0000000000000000 in ?? () (gdb) bt full #0 0x00007fbe4ba33dae in memcpy (__len=18446744073709551522, __src=0x7fbe47c9f121, __dest=0x7ffff12ada6d) at /usr/include/x86_64-linux-gnu/bits/string3.h:52 No locals. #1 dlg_cseq_msg_sent (data=0x7ffff12bda40) at dlg_cseq.c:298 msg = {id = 0, pid = 0, tval = {tv_sec = 0, tv_usec = 0}, fwd_send_flags = {f = 0 '\000', blst_imask = 0 '\000'}, rpl_send_flags = {f = 0 '\000', blst_imask = 0 '\000'}, first_line = {type = 1, flags = 1, len = 44, u = {request = {method = { s = 0x7fbe47c9f038 "INVITE sip:030636111@192.168.2.151 SIP/2.0\r\nRecord-Route: <sip:192.168.2.160;lr;did=34e.1782>\r\nRecord-Route: <sip:192.168.2.163;lr>\r\nCSeq: 1 INVITE\r\nVia: SIP/2.0/UDP 192.168.2.160;branch=z9hG4bKa7ee.0"..., len = 6}, uri = { s = 0x7fbe47c9f03f "sip:030636111@192.168.2.151 SIP/2.0\r\nRecord-Route: <sip:192.168.2.160;lr;did=34e.1782>\r\nRecord-Route: <sip:192.168.2.163;lr>\r\nCSeq: 1 INVITE\r\nVia: SIP/2.0/UDP 192.168.2.160;branch=z9hG4bKa7ee.0337c5a7"..., len = 27}, version = { s = 0x7fbe47c9f05b "SIP/2.0\r\nRecord-Route: <sip:192.168.2.160;lr;did=34e.1782>\r\nRecord-Route: <sip:192.168.2.163;lr>\r\nCSeq: 1 INVITE\r\nVia: SIP/2.0/UDP 192.168.2.160;branch=z9hG4bKa7ee.0337c5a75bfeebaef0700dd30e433800.1\r\n"..., len = 7}, method_value = 1}, reply = {version = { s = 0x7fbe47c9f038 "INVITE sip:030636111@192.168.2.151 SIP/2.0\r\nRecord-Route: <sip:192.168.2.160;lr;did=34e.1782>\r\nRecord-Route: <sip:192.168.2.163;lr>\r\nCSeq: 1 INVITE\r\nVia: SIP/2.0/UDP 192.168.2.160;branch=z9hG4bKa7ee.0"..., len = 6}, status = { s = 0x7fbe47c9f03f "sip:030636111@192.168.2.151 SIP/2.0\r\nRecord-Route: <sip:192.168.2.160;lr;did=34e.1782>\r\nRecord-Route: <sip:192.168.2.163;lr>\r\nCSeq: 1 INVITE\r\nVia: SIP/2.0/UDP 192.168.2.160;branch=z9hG4bKa7ee.0337c5a7"..., len = 27}, reason = { s = 0x7fbe47c9f05b "SIP/2.0\r\nRecord-Route: <sip:192.168.2.160;lr;did=34e.1782>\r\nRecord-Route: <sip:192.168.2.163;lr>\r\nCSeq: 1 INVITE\r\nVia: SIP/2.0/UDP 192.168.2.160;branch=z9hG4bKa7ee.0337c5a75bfeebaef0700dd30e433800.1\r\n"..., len = 7}, statuscode = 1}}}, via1 = 0x7fbe504594b8, via2 = 0x7fbe50456778, headers = 0x7fbe50459230, last_header = 0x7fbe504598c8, parsed_flag = 134284414, h_via1 = 0x7fbe50458810, h_via2 = 0x7fbe50459320, callid = 0x7fbe5044fee0, to = 0x7fbe504598c8, cseq = 0x7fbe50459020, from = 0x7fbe5045a3b0, contact = 0x0, maxforwards = 0x0, route = 0x0, record_route = 0x7fbe50459230, content_type = 0x0, content_length = 0x0, authorization = 0x0, expires = 0x0, proxy_auth = 0x0, supported = 0x7fbe50459108, require = 0x0, proxy_require = 0x0, unsupported = 0x0, allow = 0x0, event = 0x0, accept = 0x0, accept_language = 0x0, organization = 0x0, priority = 0x0, subject = 0x0, user_agent = 0x7fbe50459a60, server = 0x0, content_disposition = 0x0, diversion = 0x0, rpid = 0x0, refer_to = 0x0, session_expires = 0x0, min_se = 0x0, sipifmatch = 0x0, subscription_state = 0x0, date = 0x0, identity = 0x0, identity_info = 0x0, pai = 0x0, ppi = 0x0, path = 0x0, privacy = 0x0, body = 0x0, eoh = 0x0, unparsed = 0x7fbe47c9f2d8 "Contact: \"Fernando Aquilino\" < sip:200@192.168.1.72:5060>\r\nAllow: INVITE,ACK,OPTIONS,BYE,CANCEL,SUBSCRIBE,NOTIFY,REFER,MESSAGE,INFO,PING,PRACK\r\nContent-Length: 252\r\nContent-Type: application/sdp\r\nMax-F"..., rcv = {src_ip = {af = 0, len = 0, u = {addrl = {0, 0}, addr32 = {0, 0, 0, 0}, addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, addr = '\000' <repeats 15 times>}}, dst_ip = {af = 0, len = 0, u = {addrl = {0, 0}, addr32 = {0, 0, 0, 0}, addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, addr = '\000' <repeats 15 times>}}, src_port = 0, dst_port = 0, proto_reserved1 = 0, proto_reserved2 = 0, src_su = {s = {sa_family = 0, sa_data = '\000' <repeats 13 times>}, sin = {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = { sin6_family = 0, sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}}, bind_address = 0x0, proto = 0 '\000'}, buf = 0x7fbe47c9f038 "INVITE sip:030636111@192.168.2.151 SIP/2.0\r\nRecord-Route: <sip:192.168.2.160;lr;did=34e.1782>\r\nRecord-Route: <sip:192.168.2.163;lr>\r\nCSeq: 1 INVITE\r\nVia: SIP/2.0/UDP 192.168.2.160;branch=z9hG4bKa7ee.0"..., len = 1357, new_uri = {s = 0x0, len = 0}, dst_uri = {s = 0x0, len = 0}, parsed_uri_ok = 0, parsed_uri = {user = { s = 0x0, len = 0}, passwd = {s = 0x0, len = 0}, host = {s = 0x0, len = 0}, port = {s = 0x0, len = 0}, params = {s = 0x0, len = 0}, sip_params = {s = 0x0, len = 0}, headers = {s = 0x0, len = 0}, port_no = 0, proto = 0, type = ERROR_URI_T, flags = 0, transport = {s = 0x0, len = 0}, ttl = {s = 0x0, len = 0}, user_param = {s = 0x0, len = 0}, maddr = {s = 0x0, len = 0}, method = {s = 0x0, len = 0}, lr = {s = 0x0, len = 0}, r2 = {s = 0x0, len = 0}, gr = {s = 0x0, len = 0}, transport_val = {s = 0x0, len = 0}, ttl_val = {s = 0x0, len = 0}, user_param_val = {s = 0x0, len = 0}, maddr_val = {s = 0x0, len = 0}, method_val = {s = 0x0, len = 0}, lr_val = {s = 0x0, len = 0}, r2_val = {s = 0x0, len = 0}, gr_val = {s = 0x0, len = 0}}, parsed_orig_ruri_ok = 0, parsed_orig_ruri = {user = {s = 0x0, len = 0}, passwd = {s = 0x0, len = 0}, host = {s = 0x0, len = 0}, port = {s = 0x0, len = 0}, params = {s = 0x0, len = 0}, sip_params = {s = 0x0, len = 0}, headers = {s = 0x0, len = 0}, port_no = 0, proto = 0, type = ERROR_URI_T, flags = 0, transport = {s = 0x0, len = 0}, ttl = {s = 0x0, len = 0}, user_param = {s = 0x0, len = 0}, maddr = {s = 0x0, len = 0}, method = { s = 0x0, len = 0}, lr = {s = 0x0, len = 0}, r2 = {s = 0x0, len = 0}, gr = {s = 0x0, len = 0}, transport_val = {s = 0x0, len = 0}, ttl_val = {s = 0x0, len = 0}, user_param_val = {s = 0x0, len = 0}, maddr_val = {s = 0x0, len = 0}, method_val = {s = 0x0, len = 0}, lr_val = {s = 0x0, len = 0}, r2_val = {s = 0x0, len = 0}, gr_val = { s = 0x0, len = 0}}, add_rm = 0x0, body_lumps = 0x0, reply_lump = 0x0, add_to_branch_s = '\000' <repeats 57 times>, add_to_branch_len = 0, hash_index = 0, msg_flags = 0, flags = 0, set_global_address = {s = 0x0, len = 0}, set_global_port = {s = 0x0, len = 0}, force_send_socket = 0x0, path_vec = {s = 0x0, len = 0}, instance = {s = 0x0, len = 0}, reg_id = 0, ruid = {s = 0x0, len = 0}, location_ua = {s = 0x0, len = 0}, ldv = {flow = {decoded = 0, rcv = {src_ip = {af = 0, len = 0, u = {addrl = {0, 0}, addr32 = {0, 0, 0, 0}, addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, addr = '\000' <repeats 15 times>}}, dst_ip = {af = 0, len = 0, u = {addrl = {0, 0}, addr32 = {0, 0, 0, 0}, addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, addr = '\000' <repeats 15 times>}}, src_port = 0, dst_port = 0, proto_reserved1 = 0, proto_reserved2 = 0, src_su = {s = { sa_family = 0, sa_data = '\000' <repeats 13 times>}, sin = {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0}, sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 0, sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>, __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}}, bind_address = 0x0, proto = 0 '\000'}}}} ---Type <return> to continue, or q <return> to quit--- obuf = 0x7ffff12bda40 direction = 1 t = <optimized out> ninc = <optimized out> vinc = <optimized out> dlg = 0x7fbe47c9a8e0 nval = {s = 0xa0ce84 "2", len = 1} pval = <optimized out> tbuf = "INVITE sip:030636111@192.168.2.151 SIP/2.0\r\nRecord-Route: <sip:192.168.2.160;lr;did=34e.1782>\r\nRecord-Route: <sip:192.168.2.163;lr>\r\nCSeq: 1 INVITE\r\nVia: SIP/2.0/UDP 192.168.2.160;branch=z9hG4bKa7ee.0"... tbuf_len = 237 via = <optimized out> __FUNCTION__ = "dlg_cseq_msg_sent" #2 0x0000000000000000 in ?? () No symbol table info available. (gdb) ------------------------------------------------------------ *I generated a core dump by running kamailio from the shell as "kamailio -D -d -E -l 192.168.2.160:5060"

9 years, 9 months

Issue with non static values for sleep in the Async module

by Will Ferrer

Hi I am having an issue with the Async module. The async_route function doesn't seem able to take a dynamic value as is it's duration. The module docs states: The sleep parameter represent the number of seconds to suspend the processing of a SIP request. Maximum value is 100. The parameter can be a static integer or a variable holding an integer. Docs here: http://kamailio.org/docs/modules/4.2.x/modules/async.html#async.f.async_rou… However when I try: async_route("WITHINDLG_DELAYED", $avp(buffer_duration) ); I get the following error when trying to restart kamailio: parse error in config file /etc/kamailio/switchsoftk amailio/includes/deployments/develop/callprocessing/../../../default.cfg, line 866, column 41-61: function async_route: parameter 2 is not constant ... failed! I also tried with $var instead of an AVP, and even tried having perl call the function (since we have gotten around this sort of limitation in the past using perl). Perl gives: Jan 24 03:27:07 develop-callprocessing /usr/sbin/kamailio[1424]: ERROR: app_perl [kamailioxs.xs:289]: moduleFunc(): Module function 'async_route' is unsafe. Call is refused. Jan 24 03:27:07 develop-callprocessing /usr/sbin/kamailio[1424]: ERROR: app_perl [kamailioxs.xs:986]: XS_Kamailio__Message_moduleFunction(): calling module function 'async_route' failed. Missing loadmodule? I have gotten around this issue with a large if else structure like the following: if ($avp(buffer_duration) == 1) { async_route("WITHINDLG_DELAYED", 1); } else if ($avp(buffer_duration) == 2) { async_route("WITHINDLG_DELAYED", 2); ......... This is messy but works for us. The bug is not blocking our progress due to this work around but I wanted to post it any way incase it helps improve the module. All the best. Will Ferrer Switchsoft

9 years, 9 months

CDRs for failed calls

by Mickael Marrache

Hi, Is there a way to write CDRs for failed calls? I tried calling the acc_db_request command from my script, but it inserts a transaction log not a CDR. Thanks, Mickael

9 years, 9 months

← Newer
1
2
3
4
5
6
7
...
14
Older →

Jump to page:

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 January 2015