Module: kamailio
Branch: master
Commit: 7725dc8673bde0a35e820ed334e4e5f378455ac4
URL: https://github.com/kamailio/kamailio/commit/7725dc8673bde0a35e820ed334e4e5f…
Author: Kamailio Dev <kamailio.dev(a)kamailio.org>
Committer: Kamailio Dev <kamailio.dev(a)kamailio.org>
Date: 2018-02-13T09:01:32+01:00
modules: readme files regenerated - ndb_redis ... [skip ci]
---
Modified: src/modules/ndb_redis/README
---
Diff: https://github.com/kamailio/kamailio/commit/7725dc8673bde0a35e820ed334e4e5f…
Patch: https://github.com/kamailio/kamailio/commit/7725dc8673bde0a35e820ed334e4e5f…
---
diff --git a/src/modules/ndb_redis/README b/src/modules/ndb_redis/README
index c51fe48c3b..dd04331adc 100644
--- a/src/modules/ndb_redis/README
+++ b/src/modules/ndb_redis/README
@@ -49,6 +49,7 @@ Carsten Bock
3.6. allowed_timeouts (integer)
3.7. disable_time (integer)
3.8. flush_on_reconnect (integer)
+ 3.9. allow_dynamic_nodes (integer)
4. Functions
@@ -67,9 +68,10 @@ Carsten Bock
1.6. Set allowed_timeots parameter
1.7. Set disable_time parameter
1.8. Set flush_on_reconnect parameter
- 1.9. redis_cmd usage
- 1.10. redis_execute usage
- 1.11. redis_free usage
+ 1.9. Set allow_dynamic_nodes parameter
+ 1.10. redis_cmd usage
+ 1.11. redis_execute usage
+ 1.12. redis_free usage
Chapter 1. Admin Guide
@@ -91,6 +93,7 @@ Chapter 1. Admin Guide
3.6. allowed_timeouts (integer)
3.7. disable_time (integer)
3.8. flush_on_reconnect (integer)
+ 3.9. allow_dynamic_nodes (integer)
4. Functions
@@ -134,6 +137,7 @@ Chapter 1. Admin Guide
3.6. allowed_timeouts (integer)
3.7. disable_time (integer)
3.8. flush_on_reconnect (integer)
+ 3.9. allow_dynamic_nodes (integer)
3.1. server (str)
@@ -284,6 +288,28 @@ modparam("ndb_redis", "disable_time", 30)
modparam("ndb_redis", "flush_on_reconnect", 1)
...
+3.9. allow_dynamic_nodes (integer)
+
+ If set to 1, the module will connect to servers indicated in the
+ "MOVED" reply, even if they are not specified at startup.
+
+ When “cluster” is enabled the module supports redirections ("MOVED")
+ replies. Set “allow_dynamic_nodes” to 1 to avoid listing all the nodes
+ at startup. You can only list one node, e.g. by using a DNS name for
+ the cluster instead of an IP address. The module will add dynamically
+ the new nodes as the MOVED replies are received. Only works if
+ “cluster” is set to 1.
+
+ Default value is “0” (disabled).
+
+ Example 1.9. Set allow_dynamic_nodes parameter
+...
+modparam("ndb_redis", "server", "name=redis_cluster;addr=127.0.0.1;port=26008")
+...
+modparam("ndb_redis", "cluster", 1)
+modparam("ndb_redis", "allow_dynamic_nodes", 1)
+...
+
4. Functions
4.1. redis_cmd(srvname, command, ..., replyid)
@@ -320,7 +346,7 @@ modparam("ndb_redis", "flush_on_reconnect", 1)
The first value[n] references the element in the first array, while the
next key references an element of the referenced array.
- Example 1.9. redis_cmd usage
+ Example 1.10. redis_cmd usage
...
if(redis_cmd("srvN", "INCR cnt", "r")) {
# success - the incremented value is in $redis(r=>value)
@@ -399,7 +425,7 @@ if (redis_cmd("srvN", "EXEC", "r")) {
If cluster parameter is set to 1, this function will log an error and
do nothing.
- Example 1.10. redis_execute usage
+ Example 1.11. redis_execute usage
...
After several redis command calls:
redis_pipe_cmd("srvA", "SET foo bar", "r1");
@@ -447,7 +473,7 @@ d commands. The call is not necessary
function. When ndb_redis module closes, all pending replies are freed
automatically.
- Example 1.11. redis_free usage
+ Example 1.12. redis_free usage
...
After a redis command call:
redis_cmd("srvN", "INCR cnt", "r");
<!-- Kamailio Pull Request Template -->
<!--
IMPORTANT:
- for detailed contributing guidelines, read:
https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md
- pull requests must be done to master branch, unless they are backports
of fixes from master branch to a stable branch
- backports to stable branches must be done with 'git cherry-pick -x ...'
- code is contributed under BSD for core and main components (tm, sl, auth, tls)
- code is contributed GPLv2 or a compatible license for the other components
- GPL code is contributed with OpenSSL licensing exception
-->
#### Pre-Submission Checklist
<!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply -->
<!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above-->
<!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list -->
- [x] Commit message has the format required by CONTRIBUTING guide
- [x] Commits are split per component (core, individual modules, libs, utils, ...)
- [x] Each component has a single commit (if not, squash them into one commit)
- [x] No commits to README files for modules (changes must be done to docbook files
in `doc/` subfolder, the README file is autogenerated)
#### Type Of Change
- [ ] Small bug fix (non-breaking change which fixes an issue)
- [x] New feature (non-breaking change which adds new functionality)
- [ ] Breaking change (fix or feature that would change existing functionality)
#### Checklist:
<!-- Go over all points below, and after creating the PR, tick the checkboxes that apply -->
- [ ] PR should be backported to stable branches
- [x] Tested changes locally
- [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description
<!-- Describe your changes in detail -->
This change provides support in `ndb_redis` for a scenario where the Redis server is part of a cluster _and_ the IP addresses of the nodes are either not known in advance or are subject to change (for example in case the cluster sees new nodes being added).
Before this change `ndb_redis` supports the `cluster` option, so that after a `MOVED` response from a node `ndb_redis` will perform again the same query but towards the redirection target. The caveat is that `ndb_redis` must know in advance which IP addresses will be used by the nodes.
A`MOVED` response is in the form `-MOVED 1234 1.2.3.4:6379.`, indicating the hash for the request and the redirection target IP address and port.
Every node in the cluster must have a modparam entry with `name=IP_ADDRESS:PORT;addr=IP_ADDRESS;port=PORT`.
With the changes in this PR, ndb_redis doesn't need to have in advance the list of nodes but it can "discover" them at runtime.
There is a caveat to this solution: while defining the nodes in advance allows to define also `pass`, `sock` and `db`, this is currently not supported (and default values are used). If this change will be accepted though, we could add a module parameter to define `pass`, `sock` and `db` for the dynamic nodes.
You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/1436
-- Commit Summary --
* ndb_redis: dynamic discovery of nodes
-- File Changes --
M src/modules/ndb_redis/doc/ndb_redis_admin.xml (30)
M src/modules/ndb_redis/ndb_redis_mod.c (2)
M src/modules/ndb_redis/redis_client.c (53)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/1436.patchhttps://github.com/kamailio/kamailio/pull/1436.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/1436
Kamailio takes care of sending in-dialog keep-alives using OPTIONS when dlg_set_attribute ka-src and ka-dst is used. It also sends OPTIONS to correct address if a client sends Re-Invite indicating a network change, which is a common case with mobile clients (switching between mobile-data and Wifi) fixed in #273
The problem is that it ends the dialog on missing even one keep-alive response. Missing a response is possible when the client is handling the network change and keep-alive is sent around that time.
Thus, having a configurable counter after which you expect to end the dialog might be helpful. For eg. you decide to end the dialog after we miss 3 responses for keep-alives in a row.
Something like dlg_set_attribute(ka-src, 3) where 3 indicates the number of responses that can be missed before ending the dialog.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/438
<!--
Kamailio Project uses GitHub Issues only for bugs in the code or feature requests.
If you have questions about using Kamailio or related to its configuration file,
ask on sr-users mailing list:
* http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
If you have questions about developing extensions to Kamailio or its existing
C code, ask on sr-dev mailing list
* http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Please try to fill this template as much as possible for any issue. It helps the
developers to troubleshoot the issue.
If you submit a feature request (or enhancement), you can delete the text of
the template and only add the description of what you would like to be added.
If there is no content to be filled in a section, the entire section can be removed.
You can delete the comments from the template sections when filling.
You can delete next line and everything above before submitting (it is a comment).
-->
### Description
<!--
Explain what you did, what you expected to happen, and what actually happened.
-->
### Troubleshooting
#### Reproduction
<!--
If the issue can be reproduced, describe how it can be done.
-->
#### Debugging Data
<!--
If you got a core dump, use gdb to extract troubleshooting data - full backtrace,
local variables and the list of the code at the issue location.
gdb /path/to/kamailio /path/to/corefile
bt full
info locals
list
If you are familiar with gdb, feel free to attach more of what you consider to
be relevant.
-->
```
(paste your debugging data here)
```
#### Log Messages
<!--
Check the syslog file and if there are relevant log messages printed by Kamailio, add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
(paste your log messages here)
```
#### SIP Traffic
<!--
If the issue is exposed by processing specific SIP messages, grab them with ngrep or save in a pcap file, then add them next, or attach to issue, or provide a link to download them (e.g., to a pastebin site).
-->
```
(paste your sip traffic here)
```
### Possible Solutions
<!--
If you found a solution or workaround for the issue, describe it. Ideally, provide a pull request with a fix.
-->
### Additional Information
* **Kamailio Version** - output of `kamailio -v`
```
(paste your output here)
```
* **Operating System**:
<!--
Details about the operating system, the type: Linux (e.g.,: Debian 8.4, Ubuntu 16.04, CentOS 7.1, ...), MacOS, xBSD, Solaris, ...;
Kernel details (output of `uname -a`)
-->
```
(paste your output here)
```
--
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/1137
Module: kamailio
Branch: master
Commit: 92451536a0ef985ff1d16c5531c232cd657532e1
URL: https://github.com/kamailio/kamailio/commit/92451536a0ef985ff1d16c5531c232c…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2018-02-12T10:15:47+01:00
presence: return on having a full match on states in xml document
- better handling after previous commit, related to GH #1427
---
Modified: src/modules/presence/presentity.c
---
Diff: https://github.com/kamailio/kamailio/commit/92451536a0ef985ff1d16c5531c232c…
Patch: https://github.com/kamailio/kamailio/commit/92451536a0ef985ff1d16c5531c232c…
---
diff --git a/src/modules/presence/presentity.c b/src/modules/presence/presentity.c
index 5f0eef6368..4674f0ad49 100644
--- a/src/modules/presence/presentity.c
+++ b/src/modules/presence/presentity.c
@@ -338,6 +338,7 @@ int ps_match_dialog_state_from_body(str body, int *is_dialog, char *vstate)
if (tmp_state != NULL)
{
if(strcmp(tmp_state, vstate)!=0) {
+ /* state not matched */
xmlFree(tmp_state);
rmatch = 0;
goto done;
@@ -550,8 +551,8 @@ int ps_match_dialog_state(presentity_t* presentity, char* vstate)
rmatch = ps_match_dialog_state_from_body(tmp_db_body,
&db_is_dialog, vstate);
- if(rmatch<=0) {
- /* failure or not a match */
+ if(rmatch==1) {
+ /* having a full match */
pa_dbf.free_result(pa_db, result);
result = NULL;
return rmatch;
Hello all,
It seems there has been a regression between kamailio 5.1.0 and 5.1.1 with the topos module.
### Description
Kamailio acts as a proxy for asterisk instances residing in a private IP range and other entities (subscribers, peers) residing on other networks. This is a multihomed installation, with 4 interfaces total (but mhomed is set to no).
Just by upgrading to 5.1.1, topos will complain with:
`tps_storage_record(): no local address - do record routing for all initial requests`
for re-INVITEs within an established dialog. This warning is also printed for other in-dialog requests (BYE, ACK).
Also common behaviour with all those in-dialog requests is that if the request received by kamailio had a Contact header, topos will strip it before relaying (true for re-INVITE and ACK).
For ACK there seem to be no obvious side-effects, because there's no response to it. For BYE, its 200 OK response is routed properly, in contrast with the 200 OK to the re-INVITE.
During the processing of 200 OK to re-INVITE, the following relevant lines are printed in the logs:
```
DEBUG: topos [tps_msg.c:1031]: tps_response_sent(): handling outgoing response
DEBUG: topos [tps_msg.c:1038]: tps_response_sent(): no x-branch header - nothing to do
```
During the processing of 200 OK to BYE, the following relevant lines are printed in the logs:
```
DEBUG: topos [tps_msg.c:1031]: tps_response_sent(): handling outgoing response
DEBUG: topos [tps_msg.c:376]: tps_pack_message(): compacted headers - x_via1: [SIP/2.0/UDP 192.168.1.1:5060;rport=5060;received=2.2.2.2;branch=z9hG4bK-c1a29abe](86) - x_via2: [](0) - x_vbranch1: [z9hG4bK-c1a29abe](16)
DEBUG: topos [tps_msg.c:485]: tps_pack_message(): compacted headers - a_rr: [](0) - b_rr: [](0) - s_rr: [](0)
DEBUG: topos [tps_msg.c:490]: tps_pack_message(): compacted headers - as_contact: [](0) - bs_contact: [](0)
DEBUG: topos [tps_storage.c:124]: tps_storage_lock_get(): tps lock get: 436
```
### Troubleshooting
Downgrading to 5.1.0 fixes the issue, with no changes in configuration.
#### Reproduction
Most SIP logic adheres to the sample configuration file, one difference being that record_route() is performed regardless of request method, as required for topos (although to reproduce this issue this change is not needed, as record_route() is performed for INVITEs anyway with the sample configuration file).
To reproduce on my setup, I initiate a call which kamailio will forward to asterisk, making sure topos is loaded. I then put the call on hold to generate a re-INVITE and watch as a) outgoing INVITE lacks a Contact header and b) Final reply to re-INVITE won't be routed, instead causing several retransmissions from asterisk.
#### SIP Traffic
I'm not sure SIP Traffic is relevant here, as only the Contact header missing is what strikes me as most odd. I can share pcaps and logs privately if needed.
### Additional Information
* **Kamailio Version**
Kamailio 5.1.1 on debian stretch from sipwise's repo
* **Operating System**:
```
Debian 9.1
```
* **Other pertinent configuration information**:
* The following issues might be relevant: #1356, #1350
* This kamailio box has several network interfaces. mhomed is not used, instead force_send_socket is called where necessary.
--
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/1421