sr-dev July 2015

sr-dev@lists.kamailio.org

26 participants
301 discussions

[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, 10 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, 12 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

8 years, 1 month

[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

8 years, 2 months

[kamailio] rr: add enable_double_rr_always option (#257)

by Andrey Utkin

This patch helps us to handle inadequatness of Linphone mobile apps (both iOS and Android flavours are affected) without reinventing a lot of logics to handle each transport (we use TCP, TLS, WS, WSS). E.g. if we have two TLS-based Linphone clients, even with enable_double_rr for gentle cross-forwarding we would get single RR header without transport= attribute, resulting in Linphone sending ACK and BYE via UDP. This new option, being enabled, results in two RR headers being always inserted, with transport attribute being always added. I believe this cannot harm the installation with enable_double_rr, just makes instructions more explicit. The Linphone's behaviour looks like a set of different bugs, but it would get us much more efforts to fix. I don't know if any other useragent needs such workaround. So I would perfectly understand if this commit wouldn't be accepted upstream. Also this commit currently lacks README doc rebuild, because I don't know how to do that. Only XML doc is updated. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/257 -- Commit Summary -- * rr: add enable_double_rr_always option -- File Changes -- M modules/rr/doc/rr_admin.xml (24) M modules/rr/record.c (14) M modules/rr/rr_mod.c (2) M modules/rr/rr_mod.h (1) M tcp_read.c (5) -- Patch Links -- https://github.com/kamailio/kamailio/pull/257.patch https://github.com/kamailio/kamailio/pull/257.diff --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/257

8 years, 9 months

[kamailio] P-Charging-Vector handling as RFC3455 (#215)

by Emmanuel BUU

Here are some proposed modifications to handle the P-Charging-Vector header as defined in rfc3455 section 4.6 to - parse charging vector from SIP message - generate new unique charging vector - remove a charging vector header a new pseudo variable pseudo variables are exported and enable Read onlly access to charging vector fields $pcv = whole field $pcv.value = icid-value field (see RFC3455 section 5.6) $pcv.genaddr = icid-generated-at field (see RFC3455 section 5.6) a new function acc_charging_vector() - g = generate a new charging vector or forward the orginal one - f = generate a new charging vector regardless of the orginal charging vector - r = remote the P-Charging vector header from the packet You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/215 -- Commit Summary -- * P-Charging-Vector implementation * Merge remote branch 'upstream/master' * P-Charging-Vector -- File Changes -- M modules/acc/acc_mod.c (18) A modules/acc/chargingvector.c (435) A modules/acc/chargingvector.h (18) -- Patch Links -- https://github.com/kamailio/kamailio/pull/215.patch https://github.com/kamailio/kamailio/pull/215.diff --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/215

8 years, 9 months

[kamailio] sipcapture README does not document sip_capture script function (#63)

by juha-h

--- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/63

8 years, 10 months

[kamailio] debugger: config test report (#8)

by Victor Seva

In testing environment It would be nice to be able to append sip headers `X-Kamailio-test` and `X-Kamailio-test-ID` as a way to identify a collection of request/responses related to a a single test. Be able to generate tests reports via debugger RPC command using the value of `X-Kamailio-test` as key. The content of report could be: * SIP message received * SIP messages sended * flow of config execution routes ( `start`, `end`, `exit` ) * list of the variable and its value --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/8

8 years, 10 months

[kamailio] event on table location Duplicate entry for key 'ruid_idx' (#30)

by ovoshlook

Hello. We use 2 kamailio servers cluster and we have porblems with db. Database failed pecause of error: Could not execute Write_rows_v1 event on table production.location; Duplicate entry 'uloc-54aae947-86d-a67' for key 'ruid_idx', Error_code: 1062; handler error HA_ERR_FOUND_DUPP_KEY; the event's master log FIRST, end_log_pos 380, Internal MariaDB error code: 1062 But a location table no row 'ruid_idx' and no entry uloc-54aae947-86d-a67. --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/issues/30

8 years, 10 months

[kamailio] Added modparam id_in_avp for carrierroute (#221)

by Thomas Boros

We have 2M lines in carrierroute, so we often need to get back the ID of the line from the DB from carrierroute. This commit creates a new modparam "id_in_avp" for the module carrierroute which may be 0 - 2 0 - no ID, only the description is saved in the avp 1 - ID and descrptiotion is saved in the AVP 2 - Only ID is saved in the AVP. You can view, comment on, or merge this pull request online at: https://github.com/kamailio/kamailio/pull/221 -- Commit Summary -- * Added modparam id_in_avp for carrierroute so the ID may be returned to the AVP variable for easier debugging -- File Changes -- M modules/carrierroute/carrierroute.c (7) M modules/carrierroute/cr_db.c (61) -- Patch Links -- https://github.com/kamailio/kamailio/pull/221.patch https://github.com/kamailio/kamailio/pull/221.diff --- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/221

8 years, 10 months

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

sr-dev July 2015