Module: sip-router
Branch: master
Commit: acb0ae899ca7341f06fa4418c88f3b42d3460f49
URL: http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=commit;h=acb0ae8…
Author: Vicente Hernando <vhernando(a)systemonenoc.com>
Committer: Vicente Hernando <vhernando(a)systemonenoc.com>
Date: Fri Jul 6 18:23:09 2012 +0200
ndb_redis: update README file
---
modules/ndb_redis/README | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/modules/ndb_redis/README b/modules/ndb_redis/README
index 7d72d58..b71d796 100644
--- a/modules/ndb_redis/README
+++ b/modules/ndb_redis/README
@@ -167,19 +167,18 @@ if(redis_cmd("srvN", "HMGET foo_key field1 field3", "r")) {
4.2. redis_free(replyid)
- Free a previous reply from memory. After this function call, accessing
- to a freed replyid returns null value.
+ Frees data in a previous reply from memory. After this function call,
+ accessing to a freed replyid returns null value.
It is not necessary to free a reply to use it again in a new redis_cmd
function. When ndb_redis module closes, all pending replies are freed
- automatically, so you only need to use this function if you perform a
- lot of redis command requests with different replyid.
+ automatically.
Example 1.3. redis_free usage
...
After a redis command call:
redis_cmd("srvN", "INCR cnt", "r");
-when reply not used anymore:
+free reply data:
redis_free("r");
...
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#241 - Incorrect outbound interface used in Via and Record-Route
User who did this - Hugh Waite (hugh.waite)
----------
I see from main.c:1530 and forward.c:328 that kamailio does pick the first interface for outbound sockets (used by get_send_socket() in tm module).
A comment from forward.c says that finding the correct TCP socket might be "too complicated" and I believe it would need to know the network mask to work this out.
I have created a workaround by doing my own is_in_subnet() checks and then a force_send_socket(192.168.10.61:5060) which works fine.
Are there any potential future enhancements that would make this work automatically?
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=241#comment703
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
Hi,
I have just a small amount of additional testing to do and then I think
I will be ready to merge the WebSocket module (and associated changes to
other parts of Kamailio for the new transport type) from the
pd/websocket branch into master.
I would like to do this sometime over the next day or so, unless anyone
has an objection?
Regards,
Peter
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has been changed. The changes are listed below. For full information about what has changed, visit the URL and click the History tab.
FS#242 - ndb_redis redisc_free_reply bug
User who did this: Vicente Hernando (vicente)
Severity: Critical -> Medium
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=242
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
Vicente Hernando has taken ownership of the following task:
FS#242 - ndb_redis redisc_free_reply bug
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=242
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Vicente Hernando (vicente)
Attached to Project - sip-router
Summary - ndb_redis redisc_free_reply bug
Task Type - Bug Report
Category - Module
Status - Unconfirmed
Assigned To -
Operating System - All
Severity - Critical
Priority - Normal
Reported Version - Development
Due in Version - Undecided
Due Date - Undecided
Details - Due to ndb_redis redisc_free_reply function I created in redis_client.c file, a bug has appeared able to crash kamailio.
In pv_get_redisc function in ndb_redis_mod.c these lines appear:
if(rpv->reply==NULL)
{
rpv->reply = redisc_get_reply(&rpv->rname);
if(rpv->reply==NULL)
return pv_get_null(msg, param, res);
}
That means it stores old redisc_reply_t in rpv->reply and if it has been freed with redisc_free_reply function a segmentation fault would happen.
I find three solutions:
patch one changes if(rpv->reply==NULL) into if(1). Disadvantage is it will always have to search the reply using redisc_get_reply adding some overhead.
patch two changes redisc_free_reply function and deletes only inner redisReply structure. So once a redisc_reply_t is created it could be reused, but never deleted.
Another solution would be completely deleting redisc_free_reply function.
In my opinion second and third approaches are the best.
Any comments?
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=242
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#241 - Incorrect outbound interface used in Via and Record-Route
User who did this - Hugh Waite (hugh.waite)
----------
To explain the attached trace:
This trace is taken on a 'load-balancer' server. Clients send all traffic to this virtual IP address, but it is handled by another server which sends the traffic back to the LB. The load balancer has 2 interfaces eth0 and eth1 and there is a client on each interface. The main servers are all on the first network.
The call flow is therefore:
Client A - (192.168.0.185)
Load balancer - (192.168.0.75 advertised)
SIP router - (192.168.0.63)
Load balancer - (192.168.0.75 / 192.168.10.75 advertised)
Client B - (192.168.10.23)
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=241#comment702
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.