sr-dev July 2016

sr-dev@lists.kamailio.org

29 participants
297 discussions

[kamailio/kamailio] Calling jsonrpc_notification fail in failure route when fr_timer timeout (#713)
by Ian Yu-Hsun Lin 12 Sep '16

12 Sep '16

## Environment Kamailio 4.3.3 Ubuntu 14.04.1 x86_64 ## Problem I'm using `t_suspend()` and `t_continue()` for mobile push notification scenario. Before calling `t_suspend()` I set the `fr_timer` to 12 seconds and `t_on_failure()` to my custom failure route (e.g. `failure_route[MY_FAILURE_ROUTE]`). The scenario is fairly similar to [[SR-Users] Timeout after t_suspend and failure route][1], the only difference is I try to use `jsonrpc_notificaion()` to notify the user asynchronously in my custom failure route. There are 2 different results depending on how it goes to the failure route: 1. Caller cancel the call before `fr_timer` expires - `jsonrpc_notification` can successfully be called in failure route 2. The `fr_timer` did timeout after 12 seconds - An error occurred while calling `jsonrpc_notification`: - `jsonrpc_notification(): failed to write to io pipe: Bad file descriptor` ## Investigation For the first case that perform normally, the IDs of Kamailio processes being used are the same for both **calling t_suspend()** and **entering failure route**, while in the second case the processes are different. Following added some debug messages in Kamailio's `main.c` it showed that the process being used in the failure route of case 2 is `slow timer process`, and from `jsonrpc_mod.c`'s `child_init()` function, the rank of `slow timer process` is **-1** therefore it doesn't assign the `fd` to this process. My workaround was just assigning the `fd` to each child during `child_init()` in `jsonrpc_mod.c` but that's definitely not a good way to go. I am appreciated if you can give me some advice to solve this problem correctly. Cheers, Ian [1]: http://lists.sip-router.org/pipermail/sr-users/2015-March/087519.html --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/713

2 5

[kamailio/kamailio] Kamailio 4.4) sipcapture_module: ERROR: parse_msg: message=<HEP3#003�> (#599)
by goseeped 12 Sep '16

12 Sep '16

The sipcapture module works great when you send hepv3 packets over the UDP transport however if kamailio start listening those hepv3 packtes on TCP and sending those hepv3 on TCP it will concern about it. **This is what Kamilio receives over TCP.** > T 52.10.155.177:47283 -> 172.19.8.21:9060 [AP] > HEP3.0................... > ......... > ...........[............. > W*y6... > . > ..h...... > .................OPTIONS sip:edge.rarevase.com;transport=tcp SIP/2.0. > Via: SIP/2.0/TCP 172.19.16.130:53083;rport;branch=z9hG4bKPj66df463f-ca4b-4f98-ba17-722fe3fc4a92;alias. > From: <sip:asterisk@172.19.16.130>;tag=86ebab1d-eb4e-4986-898d-c7392b6b747b. > To: <sip:edge.rarevase.com>. > Contact: <sip:asterisk@172.19.16.130:53083;transport=TCP>. > Call-ID: ed24ab3c-4f42-4a9d-8e2d-9a3acd5b5b70. > CSeq: 3809 OPTIONS. > Max-Forwards: 70. > User-Agent: Asterisk PBX 13.8.0. > Content-Length: 0. > . > > ## > T 52.10.155.177:47283 -> 172.19.8.21:9060 [AP] > HEP3.\................... > ......... > ...................[..... > W*y6... > . > ..|...... > .................SIP/2.0 200 OK. > Via: SIP/2.0/TCP 172.19.16.130:53083;rport=53083;received=172.19.16.130;branch=z9hG4bKPj66df463f-ca4b-4f98-ba17-722fe3fc4a92;alias. > From: <sip:asterisk@172.19.16.130>;tag=86ebab1d-eb4e-4986-898d-c7392b6b747b. > To: <sip:edge.rarevase.com>;tag=24voZr. > Call-ID: ed24ab3c-4f42-4a9d-8e2d-9a3acd5b5b70. > CSeq: 3809 OPTIONS. > Max-Forwards: 70. > Content-Length: 0. > Supported: path,gruu,outbound. > Accept: */*. > Allow: INVITE,ACK,CANCEL,BYE,OPTIONS,INFO,UPDATE,SUBSCRIBE,NOTIFY,REFER,MESSAGE,REGISTER. > . > **This are the logs on the Kamailio.** `May 4 22:44:05 ip-172-19-8-21 /usr/sbin/kamailio[19285]: INFO: <core> [parser/parse_fline.c:144]: parse_first_line(): ERROR:parse_first_line: method not followed by SP May 4 22:44:05 ip-172-19-8-21 /usr/sbin/kamailio[19285]: ERROR: <core> [parser/parse_fline.c:257]: parse_first_line(): parse_first_line: bad message (offset: 0) May 4 22:44:05 ip-172-19-8-21 /usr/sbin/kamailio[19285]: DEBUG: <core> [parser/msg_parser.c:604]: parse_msg(): parse_msg: invalid message May 4 22:44:05 ip-172-19-8-21 /usr/sbin/kamailio[19285]: ERROR: <core> [parser/msg_parser.c:690]: parse_msg(): ERROR: parse_msg: message=<HEP3#003<98>> May 4 22:44:05 ip-172-19-8-21 /usr/sbin/kamailio[19285]: ERROR: <core> [receive.c:173]: receive_msg(): core parsing of SIP message failed (52.10.155.177:59607/2)` --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/599

4 9

[kamailio/kamailio] Segfault when working as sipcapture node (#723)
by Sebastian Damm 07 Sep '16

07 Sep '16

We are running Kamailio 4.4.2 as a sipcapture node and every now and then it crashes. This is what the backtrace says: ``` (gdb) bt #0 get_str_fparam (dst=dst@entry=0x7ffe50aa0610, msg=msg@entry=0x7f105b8654b8, param=param@entry=0x1a) at sr_module.c:1650 #1 0x00007f1059213346 in w_report_capture (_m=0x7f105b8654b8, _table=0x7f105b8648b8 " \250q[\020\177", _corr=0x7f105b864938 "\230\237q[\020\177", _data=0x1a <Address 0x1a out of bounds>) at sipcapture.c:1040 #2 0x000000000042b618 in do_action (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b719640, msg=msg@entry=0x7f105b8654b8) at action.c:1060 #3 0x000000000042a10a in run_actions (h=h@entry=0x7ffe50aa3ab0, a=0x7f105b718530, msg=msg@entry=0x7f105b8654b8) at action.c:1549 #4 0x000000000042bcf2 in do_action (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b71a1e8, msg=msg@entry=0x7f105b8654b8) at action.c:1049 #5 0x000000000042a10a in run_actions (h=h@entry=0x7ffe50aa3ab0, a=0x7f105b71a1e8, msg=msg@entry=0x7f105b8654b8) at action.c:1549 #6 0x000000000042bcf2 in do_action (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b71a318, msg=msg@entry=0x7f105b8654b8) at action.c:1049 #7 0x000000000042a10a in run_actions (h=h@entry=0x7ffe50aa3ab0, a=0x7f105b71a318, msg=msg@entry=0x7f105b8654b8) at action.c:1549 #8 0x000000000042bcf2 in do_action (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b71a448, msg=msg@entry=0x7f105b8654b8) at action.c:1049 #9 0x000000000042a10a in run_actions (h=h@entry=0x7ffe50aa3ab0, a=0x7f105b71a448, msg=msg@entry=0x7f105b8654b8) at action.c:1549 #10 0x000000000042bcf2 in do_action (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b71a578, msg=msg@entry=0x7f105b8654b8) at action.c:1049 #11 0x000000000042a10a in run_actions (h=h@entry=0x7ffe50aa3ab0, a=0x7f105b71a578, msg=msg@entry=0x7f105b8654b8) at action.c:1549 #12 0x000000000042bcf2 in do_action (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b719888, msg=msg@entry=0x7f105b8654b8) at action.c:1049 #13 0x000000000042a10a in run_actions (h=h@entry=0x7ffe50aa3ab0, a=0x7f105b719888, msg=msg@entry=0x7f105b8654b8) at action.c:1549 #14 0x000000000042bcf2 in do_action (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b7199b8, msg=msg@entry=0x7f105b8654b8) at action.c:1049 #15 0x000000000042a10a in run_actions (h=h@entry=0x7ffe50aa3ab0, a=0x7f105b7199b8, msg=msg@entry=0x7f105b8654b8) at action.c:1549 #16 0x000000000042bcf2 in do_action (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b719ae8, msg=msg@entry=0x7f105b8654b8) at action.c:1049 #17 0x000000000042a10a in run_actions (h=h@entry=0x7ffe50aa3ab0, a=0x7f105b719ae8, msg=msg@entry=0x7f105b8654b8) at action.c:1549 #18 0x000000000042bcf2 in do_action (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b719c18, msg=msg@entry=0x7f105b8654b8) at action.c:1049 #19 0x000000000042a10a in run_actions (h=h@entry=0x7ffe50aa3ab0, a=a@entry=0x7f105b6abc80, msg=msg@entry=0x7f105b8654b8) at action.c:1549 #20 0x00000000004375d0 in run_top_route (a=0x7f105b6abc80, msg=msg@entry=0x7f105b8654b8, c=c@entry=0x0) at action.c:1635 #21 0x0000000000504386 in receive_msg ( buf=buf@entry=0xa366b7 "PUBLISH sip:collector@109.68.96.98:5099 SIP/2.0\r\nVia: SIP/2.0/UDP 192.168.178.32:5060;branch=z9hG4bK122ceb41cd4777873\r\nRoute: <sip:proxy.live.sipgate.de:5060;lr>\r\nMax-Forwards: 70\r\nFrom: \"2362760e6\" <"..., len=<optimized out>, len@entry=728, rcv_info=rcv_info@entry=0x7ffe50aa3e80) at receive.c:240 #22 0x00007f105920ce17 in parsing_hepv3_message (buf=<optimized out>, len=<optimized out>) at hep.c:498 #23 0x00007f105920e80d in hepv3_received (buf=<optimized out>, len=<optimized out>, ri=<optimized out>) at hep.c:230 #24 0x00000000005f6e17 in udp_rcv_loop () at udp_server.c:446 #25 0x00000000004b2625 in main_loop () at main.c:1600 #26 0x0000000000427e2b in main (argc=<optimized out>, argv=<optimized out>) at main.c:2616 (gdb) ``` Does anybody see anything already? We can provide more info if needed. (And since it's the sipcapture module: @adubovikov) --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/723

4 22

[kamailio/kamailio] The changes in this PR implement DNS failover for locally generated requests (#727)
by Alex 30 Aug '16

30 Aug '16

The first patch does the actual failover part. Second is for readability. Third adds onsend_route support for local requests. This fixes #210. As this touches tm, a review would be welcomed. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/727 -- Commit Summary -- * tm: uac: Add failover support for local requests * tm: uac: Split t_uac_prepare * tm: uac: Add support for onsend route to local request -- File Changes -- M modules/tm/uac.c (447) -- Patch Links -- https://github.com/kamailio/kamailio/pull/727.patch https://github.com/kamailio/kamailio/pull/727.diff --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/727

2 1

[kamailio] uac module (uac_req_send, register) doesn't do failover (#210)
by Alex 30 Aug '16

30 Aug '16

Requests send with uac module's functions like uac_req_send() and remote registrations use the TM module, but don't actually do (DNS) failover when a destination is unreachable or sends a 503. In the tm's uac.c, t_uac_prepare() function, i can already see that the dns handle is stored in a throwaway variable instead of in the transaction, but fixing the issue isn't as simple as just storing it in the transaction (print_uac_request_from_buf() needs a uas in the transaction). Due to github not supporting attachments to issues, the sample config and debug log are inline.... :( DNS entry: ``` $ host -t SRV _sip._udp.failover.test.speakup.nl _sip._udp.failover.test.speakup.nl has SRV record 10 0 1111 try1.test.speakup.nl. _sip._udp.failover.test.speakup.nl has SRV record 100 0 2222 try2.test.speakup.nl. ``` Log snippet: ```syslog Jun 15 10:00:03 rio UACFailover[18178]: INFO: <script>: Sending OPTIONS request to sip:failover.test.speakup.nl Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: tm [uac.c:249]: t_uac_prepare(): DEBUG:tm:t_uac: next_hop=<sip:failover.test.speakup.nl> Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:537]: _dns_hash_find(): (_sip._udp.failover.test.speakup.nl(34), 33), h=825 Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [resolve.c:937]: get_record(): skipping 8 NS (p=0x9ea284, end=0x9ea3e9) Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [resolve.c:952]: get_record(): parsing 9 ARs (p=0x9ea335, end=0x9ea3e9) Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:1741]: dns_get_related(): (0x7f225233eb38 (_sip._udp.failover.test.speakup.nl, 33), 33, *0x7f2257baf2b8) (0) Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:840]: dns_cache_add_unsafe(): adding _sip._udp.failover.test.speakup.nl(34) 33 (flags=0) at 825 Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:840]: dns_cache_add_unsafe(): adding try1.test.speakup.nl(20) 1 (flags=0) at 310 Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:840]: dns_cache_add_unsafe(): adding try2.test.speakup.nl(20) 1 (flags=0) at 307 Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:2336]: dns_srv_get_nxt_rr(): (0x7f225233eb38, 0, 0, 1597643831): selected 0/1 in grp. 0 (rand_w=0, rr=0x7f225233eba0 rd=0x7f225233ebb8 p=10 w=0 rsum=0) Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:537]: _dns_hash_find(): (try1.test.speakup.nl(20), 1), h=310 Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:2926]: dns_a_resolve(): (try1.test.speakup.nl, 0) returning 0 Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:3169]: dns_srv_resolve_ip(): ("_sip._udp.failover.test.speakup.nl", 0, 0), ret=0, ip=192.168.1.245 Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [dns_cache.c:3260]: dns_srv_sip_resolve(): (failover.test.speakup.nl, 0, 0), srv0, ret=0 Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: tm [uac.c:150]: dlg2hash(): DEBUG: dlg2hash: 54501 Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: tm [uac.c:351]: t_uac_prepare(): executing event_route[tm:local-request] Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:606]: parse_msg(): SIP Request: Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:608]: parse_msg(): method: <OPTIONS> Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:610]: parse_msg(): uri: <sip:failover.test.speakup.nl> Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:612]: parse_msg(): version: <SIP/2.0> Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/parse_via.c:1254]: parse_via_param(): Found param type 232, <branch> = <z9hG4bK5e4d.47adbbf5000000000000000000000000.0>; state=16 Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/parse_via.c:2642]: parse_via(): end of header reached, state=5 Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:496]: parse_headers(): parse_headers: Via found, flags=2 Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:498]: parse_headers(): parse_headers: this is the first via Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/parse_addr_spec.c:894]: parse_addr_spec(): end of header reached, state=10 Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:173]: get_hdr_field(): DEBUG: get_hdr_field: <To> [22]; uri=[sip:to.example.com] Jun 15 10:00:03 rio UACFailover[18178]: [97B blob data] Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [parser/msg_parser.c:153]: get_hdr_field(): get_hdr_field: cseq <CSeq>: <10> <OPTIONS> Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: pv [pv_core.c:376]: pv_get_xto_attr(): no Tag parameter Jun 15 10:00:03 rio UACFailover[18178]: INFO: <script>: [udp:172.28.4.128:6789] [10 OPTIONS] Request (cid: 6cd531e47cc63e20-18178(a)172.28.4.128 Branch: -1 ToTag: <null> len:382) To <sip:failover.test.speakup.nl> via <sip:failover.test.speakup.nl> Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [usr_avp.c:631]: destroy_avp_list(): destroying list (nil) Jun 15 10:00:03 rio UACFailover[18178]: DEBUG: <core> [xavp.c:446]: xavp_destroy_list(): destroying xavp list (nil) Jun 15 10:00:05 rio UACFailover[18176]: DEBUG: tm [t_reply.c:1230]: t_should_relay_response(): ->>>>>>>>> T_code=0, new_code=408 Jun 15 10:00:05 rio UACFailover[18176]: WARNING: tm [t_reply.c:957]: run_failure_handlers(): Warning: run_failure_handlers: no UAC support (1, 0) Jun 15 10:00:05 rio UACFailover[18176]: DEBUG: tm [t_reply.c:2016]: local_reply(): DEBUG: local_reply: branch=0, save=0, winner=0 Jun 15 10:00:05 rio UACFailover[18176]: DEBUG: tm [t_reply.c:2053]: local_reply(): DEBUG: local transaction completed ``` Sample config: ```python #------------------ # Flags #------------------ debug=3 memdbg=5 mem_summary=5 #fork=no # This option should not be present to enable forking but disable daemonize, also -D commandline parameter is needed log_stderror=no sip_warning=no listen=172.28.4.128 port=6789 children=2 shm_mem_size=64 log_name="UACFailover" check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) dns_use_search_list=no use_dns_failover=yes dns_srv_lb=yes disable_tcp=yes mpath="/usr/lib/x86_64-linux-gnu/kamailio/modules/" loadmodule "pv.so" loadmodule "tm.so" loadmodule "tmx.so" loadmodule "sl.so" loadmodule "xlog.so" loadmodule "rr.so" loadmodule "uac.so" loadmodule "rtimer.so" # ----------------------------------------------------------------- # Module settings # ----------------------------------------------------------------- modparam("pv", "varset", "server=s:LOGNAME") modparam("tm", "auto_inv_100", 0) # Time until provisional response (eg "100 Trying") is received modparam("tm", "fr_timer", 2000) # Time to await final response on INVITE per branch (eg per branch ring time) modparam("tm", "fr_inv_timer", 10000) # Time to await final response on INVITE (eg ring time) modparam("tm", "max_inv_lifetime", 20000) modparam("tm", "restart_fr_on_each_reply", 0) modparam("tm", "failure_reply_mode", 3) modparam("rtimer", "timer", "name=uac;interval=10;mode=1;") modparam("rtimer", "exec", "timer=uac;route=TIMER") route { xlog("L_NOTICE", "[$pr:$si:$sp] [$cs $rm] Request. (cid: $ci <$fu> => <$ru> len: $ml)"); drop(); } event_route[tm:local-request] { xlog("L_INFO", " [$pr:$si:$sp] [$cs $rm] Request (cid: $ci Branch: $T_branch_idx ToTag: $tt len:$ml) To <$ru> via <$du>"); } onreply_route { xlog("L_INFO", " [$pr:$si:$sp] [$cs $rm] Reply (cid: $ci Branch: $T_branch_idx Status: $rs $rr ToTag: $tt len:$ml)"); } route[TIMER] { if not $var(done) == 1 { $var(done) = 1; $uac_req(method) = "OPTIONS"; $uac_req(ruri) = "sip:failover.test.speakup.nl"; $uac_req(furi) = "sip:from.example.com"; $uac_req(turi) = "sip:to.example.com"; xlog("L_INFO", "Sending $uac_req(method) request to $uac_req(ruri)"); uac_req_send(); } } ``` --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/210

2 3

[kamailio/kamailio] Bugfix presence race 2 (#726)
by Phil Lavin 22 Aug '16

22 Aug '16

presentity: don't update terminated presentity entries in the database - This fix is pull requested based on the stuff in pull request #724. That is because the stuff done here builds on that earlier work. #724 probably wants to be merged before this one. - Fixes a race condition caused by, for example, the call being answered at almost exactly the same time as the caller cancels. This causes a terminated state to change back to completed. The dialog is then removed from the database and the presentity entry stays in place until it expires. - This fix explicitly prevents terminated entries being updated as the state machine in RFC 4235 prohibits this behaviour. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/726 -- Commit Summary -- * presence: Always check if a record exists for this dialog before inserting * presence: fix memory leak introduced by last commit * presence: log when presentity is deleted due to already existing * presentity: don't update terminated presentity entries in the database -- File Changes -- M modules/presence/presentity.c (297) -- Patch Links -- https://github.com/kamailio/kamailio/pull/726.patch https://github.com/kamailio/kamailio/pull/726.diff --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/726

2 2

[kamailio/kamailio] presence: Always check if a record exists for this dialog before inserting (#724)
by Phil Lavin 22 Aug '16

22 Aug '16

- The presence implementation is a little dubious, to say the least. It probably wants re-writing at some stage. However, this fixes a race condition that could have a number of causes in which the PUA is unaware of the eTag at the point it sends the PUBLISH. The mechanism is such that the PUA passes the eTag that should be updated in the database into a main Kamailio process via a header in the PUBLISH. It is made aware of the new eTag by the main Kamailio process in the 200 OK. In the scenario when the PUA has not received the 200 OK for the `Trying` `PUBLISH` before it sends the `early` `PUBLISH`, it will send the `early` PUBLISH with no eTag. This results in both `Trying` and `early` being inserted into the database. Only the `early` is updated, as it is the most recent, meaning the `Trying` will stick around in the table until it expires. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/724 -- Commit Summary -- * presence: Always check if a record exists for this dialog before inserting -- File Changes -- M modules/presence/presentity.c (134) -- Patch Links -- https://github.com/kamailio/kamailio/pull/724.patch https://github.com/kamailio/kamailio/pull/724.diff --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/724

2 9

[kamailio/kamailio] Kamailio can not start with TLS (#714)
by ovoshlook 13 Aug '16

13 Aug '16

Hi installed yesterday and today on 2 different servers kamialio 4.4 > kamailio -v > version: kamailio 4.4.2 (x86_64/linux) 12777a > 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: 12777a > compiled on 06:45:41 Jul 17 2016 with gcc 5.4.0 and today > kamailio -v > version: kamailio 4.4.2 (x86_64/linux) 12777a > 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: 12777a > compiled on 14:34:16 Jul 18 2016 with gcc 5.4.0 start with TLS gives this error on both. Debug log gives nothing about tls. Just these strings. ERROR: tls [tls_init.c:490]: tls_pre_init(): Unable to set the memory allocation functions ERROR: <core> [sr_module.c:607]: load_module(): /usr/local/lib64/kamailio/modules/tls.so: mod_register failed Saw you made some changes on TLS module. Suppose it is because of it. Will give access to the server if it needs --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/714

2 10

[kamailio/kamailio] 4.4.x TOPOS - bad sip message or missing Contact hdr on OPTIONS messages (#715)
by darencrew 09 Aug '16

09 Aug '16

topos is complaining about missing contact, but on an OPTIONS message, contact is not mandatory 23(12470) ERROR: topos [tps_storage.c:305]: tps_storage_link_msg(): bad sip message or missing Contact hdr So, should "OPTIONS" be added to the exceptions in the code or is there a way to stop storing OPTIONS messages informations? --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/715

2 7

[kamailio/kamailio] 4.4.x TOPOS - parse_rr() error when using topos (#716)
by darencrew 09 Aug '16

09 Aug '16

On a setup i made, when using record_route without topos, the dialogs are well followed The same setup with topos activated leads to parse_rr() errors like this one: ERROR: <core> [parser/parse_rr.c:119]: do_parse_rr_body(): parse_rr(): Text after comma missing I made some SQL captures to see more about the issue, but nothing convincing except topos seems to be looking for a missing record in its database This record seems to have never been recorded [log-topos.txt](https://github.com/kamailio/kamailio/files/370286/log-topos.… Thank you for your help in diagnosing this issue --- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/716

2 11

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev July 2016