sr-dev October 2015

sr-dev@lists.kamailio.org

28 participants
236 discussions

git:master:b450a769: Updated P-CSCF example with additional Rx_AAR params

by Richard Good

Module: kamailio Branch: master Commit: b450a769cff3b5c8ea0962299f6b087da089cd59 URL: https://github.com/kamailio/kamailio/commit/b450a769cff3b5c8ea0962299f6b087… Author: Richard Good <richard.good(a)smilecoms.com> Committer: Richard Good <richard.good(a)smilecoms.com> Date: 2014-12-17T10:58:00+02:00 Updated P-CSCF example with additional Rx_AAR params --- Modified: examples/pcscf/kamailio.cfg --- Diff: https://github.com/kamailio/kamailio/commit/b450a769cff3b5c8ea0962299f6b087… Patch: https://github.com/kamailio/kamailio/commit/b450a769cff3b5c8ea0962299f6b087… --- diff --git a/examples/pcscf/kamailio.cfg b/examples/pcscf/kamailio.cfg index c09cdc9..c2d5f55 100644 --- a/examples/pcscf/kamailio.cfg +++ b/examples/pcscf/kamailio.cfg @@ -983,7 +983,7 @@ route[Orig_Initial] #!ifdef WITH_RX xlog("L_DBG","Diameter: Orig authorizing media via Rx\n"); - if(Rx_AAR("ORIG_SESSION_AAR","orig")==0){ + if(Rx_AAR("ORIG_SESSION_AAR","orig","",-1)==0){ exit; } } @@ -1035,7 +1035,7 @@ onreply_route[Orig_Initial_reply] #!ifdef WITH_RX if (t_check_status("180|183|200")){ xlog("L_DBG","Diameter: Orig authorizing media via Rx\n"); - if(Rx_AAR("ORIG_SESSION_AAR_REPLY","orig")==0){ + if(Rx_AAR("ORIG_SESSION_AAR_REPLY","orig","",-1)==0){ exit; } } @@ -1089,7 +1089,7 @@ route[Term_Initial] #!ifdef WITH_RX xlog("L_DBG","Diameter: Term authorizing media via Rx\n"); - if(Rx_AAR("TERM_SESSION_AAR","term")==0){ + if(Rx_AAR("TERM_SESSION_AAR","term","",-1)==0){ exit; } } @@ -1138,7 +1138,7 @@ onreply_route[Term_Initial_reply] #!ifdef WITH_RX if (t_check_status("180|183|200")){ xlog("L_DBG","Diameter: Orig authorizing media via Rx\n"); - if(Rx_AAR("TERM_SESSION_AAR_REPLY","term")==0){ + if(Rx_AAR("TERM_SESSION_AAR_REPLY","term","",-1)==0){ exit; } }

6 years, 6 months

[kamailio] PID file permissions (#231)

by Arsen

ENV: Debian 8 So on most Linux systems the /var/run folder is a tmpfs and after which clears after each reboot As I try to start up kamailio after a reboot through kamctl I get the following error. "ERROR: PID file /var/run/kamailio.pid does not exist -- Kamailio start failed" Because kamailio does not have the permission to write to the /var/run folder as the kamailio user. Would it be possible to add in the "kamctl" code a section where the SPECIFIED PID LOCATION (/var/run/kamailio) is checked and if it does not exist create it as the root user and chown it to the SPECIFIED USER (kamailio)? The way I have patched it for now is to create a init script that creates a /var/run/kamailio folder and chmods it to kamailio:kamailio Thanks everyone! --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/231

7 years

[kamailio] consistency on name of main c file for a module (#82)

by Victor Seva

main file should be modulename.c or modulename_mod.c --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/82

7 years, 6 months

[kamailio] permissions: RPC AddressDump doesn't include mask size (#250)

by Olle E. Johansson

The new RPC command doesn't output the mask, only the IP. --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/250

7 years, 7 months

Outbound flow failure handling merged to master

by Hugh Waite

Hello, As you will see I have merged my branch back into master. These changes add a new event route [tm:branch-failure] to the tm module which is run when any failure response is received on a transaction. The event_route uses a new route type BRANCH_ROUTE which limits the functions that can be run in the route. The functions t_check_status(), t_next_contact_flow(), t_relay() and unregister() can be used in this route. A new pv $T_reply_ruid is accessible in this route which can be used to unregister a single contact entry. The following example route can be used on a registrar to handle failed or invalid flows: event_route[tm:branch-failure] { xlog("L_INFO", "event_route[tm:branch-failure]\n"); if (t_check_status("430|403")) { if (!unregister("location", "$tu", "$T_reply_ruid")) { xlog("L_WARN", "failed to unregister $tu with ruid $T_reply_ruid\n"); } if (!t_next_contact_flow()) { xlog("L_INFO", "No more flows\n"); } else { xlog("L_INFO", "Next flow\n"); t_relay(); } } } Any bugs, memory leaks etc. let me know! Hugh -- Hugh Waite Principal Design Engineer Crocodile RCS Ltd.

7 years, 8 months

[kamailio] pua: E_Tag miss match due to race between consecutive PUBLISH requests (#21)

by Ovidiu Sas

If a PUBLISH request is sent before a 200 OK for the previous PUBLISH request is received, the E-Tag is reset which leads to inconsistent presentity data in the presence server. This is happening because the second PUBLISH is sent with the same E-Tag as the previous one, but the presence server has an updated the E-Tag (generated while handling the first PUBLISH). The pua module should implement a queuing mechanism for subsequent PUBLISH request while a previous PUBLISH transaction is in progress. No new PUBLISH requests should be sent before a response to the previous PUBLISH request was received and the E-Tag updated. --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/21

7 years, 10 months

[kamailio] uac module (uac_req_send, register) doesn't do failover (#210)

by Alex

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

7 years, 11 months

git:master:b7c588df: tm: store last received response code before running onreply_route

by Daniel-Constantin Mierla

Module: kamailio Branch: master Commit: b7c588dff06030a82f305b210573be5bbc961cec URL: https://github.com/kamailio/kamailio/commit/b7c588dff06030a82f305b210573be5… Author: Daniel-Constantin Mierla <miconda(a)gmail.com> Committer: Daniel-Constantin Mierla <miconda(a)gmail.com> Date: 2015-09-07T15:56:45+02:00 tm: store last received response code before running onreply_route - otherwise an innapropriate cancel can happen if the current branch got before an 1xx response, and the script writer enforces another reply code with t_reply() - reported by Thomas Sevestre, GH#315 --- Modified: modules/tm/t_reply.c --- Diff: https://github.com/kamailio/kamailio/commit/b7c588dff06030a82f305b210573be5… Patch: https://github.com/kamailio/kamailio/commit/b7c588dff06030a82f305b210573be5… --- diff --git a/modules/tm/t_reply.c b/modules/tm/t_reply.c index b2e6e53..8da3205 100644 --- a/modules/tm/t_reply.c +++ b/modules/tm/t_reply.c @@ -2286,10 +2286,21 @@ int reply_received( struct sip_msg *p_msg ) backup_xavps = xavp_set_list(&t->xavps_list); #endif setbflagsval(0, uac->branch_flags); + if(msg_status>last_uac_status) { + /* current response (msg) status is higher that the last received + * on the same branch - set it temporarily so functions in onreply_route + * can access it (e.g., avoid sending CANCEL by forcing another t_relply() + * in onreply_route when a negative sip response was received) */ + uac->last_received = msg_status; + } + /* Pre- and post-script callbacks have already * been executed by the core. (Miklos) */ run_top_route(onreply_rt.rlist[onreply_route], p_msg, &ctx); + + /* restore brach last_received as before executing onreply_route */ + uac->last_received = last_uac_status; /* transfer current message context back to t */ if (t->uas.request) t->uas.request->flags=p_msg->flags; getbflagsval(0, &uac->branch_flags);

8 years

[kamailio] Module:sca Line seize does not release after some 'bye's (#341)

by Kevin Scott Adams

I have a situation that I can't get my head around. Every so often I have a SCA seized and I need to manually release it. Here is the log of the sca and bye from the event logs. messages-20150920:Sep 18 14:35:28 sip-registrar /usr/sbin/kamailio[7608]: ERROR: sca [sca_call_info.c:1580]: sca_call_info_bye_handler(): sca_call_info_bye_handler: sip:Mindfield@kamailio.newgarllc.com dialog leg 96b9ad37-9a7fa462-15c35d3(a)192.168.1.117;1c389191866 is not active messages-20150920:Sep 18 14:35:28 sip-registrar /usr/sbin/kamailio[7610]: NOTICE: acc [acc.c:317]: acc_log_request(): ACC: transaction answered: timestamp=1442601328;method=BYE;from_tag=76C3EC1F-114D759A;to_tag=1c389191866;call_id=96b9ad37-9a7fa462-15c35d3(a)192.168.1.117;code=200;reason=OK;src_user=Mindfield;src_domain=kamailio.newgarllc.com;src_ip=192.168.1.40;dst_ouser=Mindfield;dst_user=Mindfield;dst_domain=192.168.1.117 And the kamcmd showing the seize line (in this case both are seized) sip:Mindfield@kamailio.newgarllc.com 1 active 1442601278 sip:Mindfield@192.168.1.117 sip:1030@192.168.1.40:5060 96b9ad37-9a7fa462-15c35d3(a)192.168.1.117 76C3EC1F-114D759A 1c389191866 I am running Kamailio 4.2.6. The phones are Polycom VVX 310/410 running 5.3.1. And the PSTN gateway is an Audiocodes Mediant 1000 running 6.60A.292.001. The call volume is light so I don't think there is a lot of traffic but there is about 16 phones one SCA. It is not happening all time. Could be a couple days that nothing happens and then there could be a couple days that it happens multiple times a day. I can't find a common element that would be causing this unless the 'bye' is closing the call before the SCA has a chance to do something with it. Thanks Kev --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/341

8 years, 1 month

[kamailio] Lots of tcp_read_* errors in log, multi-transport server, lack of context in messages (#385)

by Andrey Utkin

Hi devs, The logs of our Kamailio servers are rich for such lines: ``` Oct 28 06:57:35 ip-172-31-0-139 /usr/local/sbin/kamailio[31963]: ERROR: <core> [tcp_read.c:271]: tcp_read_data(): error reading: Connection reset by peer (104) Oct 28 06:57:35 ip-172-31-0-139 /usr/local/sbin/kamailio[31963]: ERROR: <core> [tcp_read.c:1296]: tcp_read_req(): ERROR: tcp_read_req: error reading ``` The servers serve WS, WSS, UDP, TCP and TLS as connection transports. So we cannot figure what happens and if this is really a problem, but we get accused by whoever audits the servers. What could be done to make this more trackable? Or maybe these messages should be suppressed, if there's no way to track them and they don't mean any problem? --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/385

8 years, 2 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev October 2015