Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] Distributed User Location
Hello Adrian, The actual question is IF there is SOMETHING that can be done directly in the usrloc module to help with distributed scenario (to have some built-in functionality to have an auto-of-the-box solution). I'm fully aware you can combine the existing module with other kind of backends and do the work. Of course we can leave the usrloc module as it is and expect people to have their own fight to distributed it (as you did, as we did and many other did) - the idea is to have a ready to use approach here (if something like this exists) to address the most common and used cases. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 04/05/2013 08:51 AM, Adrian Georgescu wrote: Hello Vlad, We developed such a solution and is operational since 2005 but not in the open source domain. The start point was P2P protocols used for file sharing. Is less of a SIP server issue (we used stock OpenSER and stock OpenSIPS for years) but rather a generic self-organizing network design where SIP accounts map to certain nodes using Chord style hashing function. The problem you need to solve is not necessarily SIP related (as it turns out that it works with any sip servers of client out there) but simply making a join/leave protocol that allows for horizontal scalability and adding this adapter to OpenSIPS. This layer if is abstract enough you can use it for any other thing not just OpenSIPS. We use it to horizontally scale Asterisk servers, OpenXCAP servers, MSRP Relay servers, Media Proxy servers for example. Here is the design document: https://docs.sipthor.net/projects/documentation/wiki/SipThorDescription And here is some papers we wrote back in 2005/2006 about this concept which can provide some clues for whomever wants to build this in OpenSIPS. http://www.ag-projects.com/presentations-corporate-285/41-sip2007 Adrian On Apr 4, 2013, at 3:05 PM, Vlad Paiu wrote: Hello all, We would like to get suggestions and help on the matter of distributing the user location information. Extending the User Location with a built-in distributed support is not straight forward - it is not about simply sharing data - as it is really SIP dependent and network limited While now, by using the OpenSIPS trunk, it is possible to just share the actual usrloc info ( by using the db_cachedb module and storing the information in a MongoDB cluster ), you can encounter real-life scenarios where just sharing the info is not enough, like : - NAT-ed clients, where only the initial server that received the Register has the pin-hole open, and thus is the only server that can relay traffic back to the respective client - the user has a SIP client that only accepts traffic from the server IP that it's currently registered against, and thus would reject direct traffic from other IPs ( due to security reasons ) We would like to implement a true general solution for this issue, and would appreciate your feedback on this. Also we'd appreciate if you could share the needs that you would have from such a distributed user location feature, and the scenarios that you would use such a feature in real-life setups. Best Regards, -- Vlad Paiu OpenSIPS Developer http://www.opensips-solutions.com ___ Users mailing list us...@lists.opensips.org mailto:us...@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list us...@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] Distributed User Location
Hello Muhammad, Your approach is the correct one (from SIP perspective) IMHO. But there are questions on the implementation side too - like the Super Node is just a storage or it should have SIP capabilities? How much of this behavior should be hardcoded in the registrar + usrloc module ? Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 04/05/2013 04:57 AM, Muhammad Shahzad wrote: Well at 5 am in the morning while thinking on this topic the only thing ringing in my mind is a mechanism similar to IP to IP Gateway. Here is the main concept. 1. We have number of SIP servers running, say sip1.mydomain.com http://sip1.mydomain.com, sip2.mydomain.com http://sip2.mydomain.com ... sipN.mydomain.com http://sipN.mydomain.com, each serving domain mydomain.com http://mydomain.com and a SIP client A can select any one of these servers through DNS look-up (or whatever way possible) and registers to that server. Lets call these servers as Base Nodes. 2. Upon successful registration of client A to server sip1.mydomain.com http://sip1.mydomain.com, this Registrar Node fires an Event, which can be subscribed by a back-end SIP server, lets call it Super Node. This event will only contain following things, a). User part of all Contact URIs of client A with Expiry. b). Registrar Node information e.g. its IP address + Port. c). SIP domain of client A. (in case of multi-domain setup) 3. Super Node stores this information in some db back-end (memcache, redis, mysql etc.). This is sort of back-to-back register process but without SIP or authentication, since that has already been handled on Based Node anyway. The Super Node only needs to know which user is registered on which Base Node e.g. user 1001 is registered on node sip1.mydomain.com http://sip1.mydomain.com, user 1203 is registered on sip6.mydomain.com http://sip6.mydomain.com and so on. 4. When a SIP client B tries to send INVITE or MESSAGE or SUBSCRIBE to SIP client A. The SIP request will arrive on Base Node it is currently registered with, say sip2.mydomain.com http://sip2.mydomain.com. This node will first do local look-up for location of client A. Upon failure it will forward request to Super Node, which will do a look-up on Event database and finds that client A is registered on node sip1.mydomain.com http://sip1.mydomain.com, so it will send SIP redirect response 302 to requester Base Node. Now the request source node knows the address of request destination node, where it will send request next and they both, while acting as independent SIP servers, establish SIP session between caller and callee. This should work regardless if both nodes serve same or different SIP domains. 5. The Super Node will also give us global presence of all users currently registered to all Base Nodes, which may be useful for management and monitoring etc. Pros: 1. Completely independent of network topology and SIP. 2. Will work seamlessly for multi and federated domains. 3. Scale-able in every direction. 4. Minimal overhead for session establishment. Once supper node return destination base node address in SIP redirect response, session will establish directly between source and destination base node. Further optimizations are possible, e.g. base node can cache destination base node returned by supper node for any particular user and avoid querying super node for recurring SIP sessions. Cons: 1. Well, the key problem i can guess is of course the Event database size and speed, as it will have information on every user registered to every Base Node. I suggest memory cache db such as Redis would be idle for this storage. 2. Bandwidth consumed in Event transport. We can apply compression and make event queues as optimization. Comments and suggestions are highly welcome. Thank you. On Thu, Apr 4, 2013 at 2:05 PM, Vlad Paiu vladp...@opensips.org mailto:vladp...@opensips.org wrote: Hello all, We would like to get suggestions and help on the matter of distributing the user location information. Extending the User Location with a built-in distributed support is not straight forward - it is not about simply sharing data - as it is really SIP dependent and network limited While now, by using the OpenSIPS trunk, it is possible to just share the actual usrloc info ( by using the db_cachedb module and storing the information in a MongoDB cluster ), you can encounter real-life scenarios where just sharing the info is not enough, like : - NAT-ed clients, where only the initial server that received the Register has the pin-hole open, and thus is the only server that can relay traffic back to the respective client - the user has a SIP client that only accepts traffic from the server IP that it's currently registered against, and thus would reject direct traffic from other IPs ( due to security
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] Distributed User Location
The lookup function could be extended to determine which node is responsible for a given SIP URI based on a one-way hashing function. Chord is an example of algorithm that can be used to map the hashes to the nodes (practically is a integer comparison where all SIP URIs are attracted by the next integer that corresponds to the IP of the server). Same lookup function can then be used to route traffic for a give user to the right node. If this is baked in, you need only to create some module that maintains a list of all active nodes. When one node joins, this is made known to the location table module so its lookup can take it into consideration. When one node leaves same process occurs, the node is removed from the table and lookup will find another node. Adrian On Apr 5, 2013, at 2:34 PM, Bogdan-Andrei Iancu wrote: Hello Adrian, The actual question is IF there is SOMETHING that can be done directly in the usrloc module to help with distributed scenario (to have some built-in functionality to have an auto-of-the-box solution). I'm fully aware you can combine the existing module with other kind of backends and do the work. Of course we can leave the usrloc module as it is and expect people to have their own fight to distributed it (as you did, as we did and many other did) - the idea is to have a ready to use approach here (if something like this exists) to address the most common and used cases. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 04/05/2013 08:51 AM, Adrian Georgescu wrote: Hello Vlad, We developed such a solution and is operational since 2005 but not in the open source domain. The start point was P2P protocols used for file sharing. Is less of a SIP server issue (we used stock OpenSER and stock OpenSIPS for years) but rather a generic self-organizing network design where SIP accounts map to certain nodes using Chord style hashing function. The problem you need to solve is not necessarily SIP related (as it turns out that it works with any sip servers of client out there) but simply making a join/leave protocol that allows for horizontal scalability and adding this adapter to OpenSIPS. This layer if is abstract enough you can use it for any other thing not just OpenSIPS. We use it to horizontally scale Asterisk servers, OpenXCAP servers, MSRP Relay servers, Media Proxy servers for example. Here is the design document: https://docs.sipthor.net/projects/documentation/wiki/SipThorDescription And here is some papers we wrote back in 2005/2006 about this concept which can provide some clues for whomever wants to build this in OpenSIPS. http://www.ag-projects.com/presentations-corporate-285/41-sip2007 Adrian On Apr 4, 2013, at 3:05 PM, Vlad Paiu wrote: Hello all, We would like to get suggestions and help on the matter of distributing the user location information. Extending the User Location with a built-in distributed support is not straight forward - it is not about simply sharing data - as it is really SIP dependent and network limited While now, by using the OpenSIPS trunk, it is possible to just share the actual usrloc info ( by using the db_cachedb module and storing the information in a MongoDB cluster ), you can encounter real-life scenarios where just sharing the info is not enough, like : - NAT-ed clients, where only the initial server that received the Register has the pin-hole open, and thus is the only server that can relay traffic back to the respective client - the user has a SIP client that only accepts traffic from the server IP that it's currently registered against, and thus would reject direct traffic from other IPs ( due to security reasons ) We would like to implement a true general solution for this issue, and would appreciate your feedback on this. Also we'd appreciate if you could share the needs that you would have from such a distributed user location feature, and the scenarios that you would use such a feature in real-life setups. Best Regards, -- Vlad Paiu OpenSIPS Developer http://www.opensips-solutions.com ___ Users mailing list us...@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list us...@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] Distributed User Location
Bogdan, As you suggest, there are ways to achieve this now manually with custom scripting and glue, it its not very straightforward. What I think is the goal would be something drop in ready, that you could just enable for distributed location versus normal location. The solution may be to fork the registrar and usrloc modules into distributed versions of the modules. These would automatically support these distributed scenarios by using a combination of things discussed, and possibly a forced path flag that would route back to the home proxy by modifying the registrar request (perhaps with a path to home proxy). This way, it would not interfere with existing usage of these modules and allow for more flexibility when developing these new ones without breaking existing installations. What do you guys think? Thanks in advance, --Rudy Dynamic Packet Toll-Free: 888.929.VOIP ( 8647 ) On Fri, Apr 5, 2013 at 8:37 AM, Bogdan-Andrei Iancu bog...@opensips.org wrote: Hello Muhammad, Your approach is the correct one (from SIP perspective) IMHO. But there are questions on the implementation side too - like the Super Node is just a storage or it should have SIP capabilities? How much of this behavior should be hardcoded in the registrar + usrloc module ? Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 04/05/2013 04:57 AM, Muhammad Shahzad wrote: Well at 5 am in the morning while thinking on this topic the only thing ringing in my mind is a mechanism similar to IP to IP Gateway. Here is the main concept. 1. We have number of SIP servers running, say sip1.mydomain.com, sip2.mydomain.com ... sipN.mydomain.com, each serving domain mydomain.com and a SIP client A can select any one of these servers through DNS look-up (or whatever way possible) and registers to that server. Lets call these servers as Base Nodes. 2. Upon successful registration of client A to server sip1.mydomain.com, this Registrar Node fires an Event, which can be subscribed by a back-end SIP server, lets call it Super Node. This event will only contain following things, a). User part of all Contact URIs of client A with Expiry. b). Registrar Node information e.g. its IP address + Port. c). SIP domain of client A. (in case of multi-domain setup) 3. Super Node stores this information in some db back-end (memcache, redis, mysql etc.). This is sort of back-to-back register process but without SIP or authentication, since that has already been handled on Based Node anyway. The Super Node only needs to know which user is registered on which Base Node e.g. user 1001 is registered on node sip1.mydomain.com, user 1203 is registered on sip6.mydomain.com and so on. 4. When a SIP client B tries to send INVITE or MESSAGE or SUBSCRIBE to SIP client A. The SIP request will arrive on Base Node it is currently registered with, say sip2.mydomain.com. This node will first do local look-up for location of client A. Upon failure it will forward request to Super Node, which will do a look-up on Event database and finds that client A is registered on node sip1.mydomain.com, so it will send SIP redirect response 302 to requester Base Node. Now the request source node knows the address of request destination node, where it will send request next and they both, while acting as independent SIP servers, establish SIP session between caller and callee. This should work regardless if both nodes serve same or different SIP domains. 5. The Super Node will also give us global presence of all users currently registered to all Base Nodes, which may be useful for management and monitoring etc. Pros: 1. Completely independent of network topology and SIP. 2. Will work seamlessly for multi and federated domains. 3. Scale-able in every direction. 4. Minimal overhead for session establishment. Once supper node return destination base node address in SIP redirect response, session will establish directly between source and destination base node. Further optimizations are possible, e.g. base node can cache destination base node returned by supper node for any particular user and avoid querying super node for recurring SIP sessions. Cons: 1. Well, the key problem i can guess is of course the Event database size and speed, as it will have information on every user registered to every Base Node. I suggest memory cache db such as Redis would be idle for this storage. 2. Bandwidth consumed in Event transport. We can apply compression and make event queues as optimization. Comments and suggestions are highly welcome. Thank you. On Thu, Apr 4, 2013 at 2:05 PM, Vlad Paiu vladp...@opensips.org wrote: Hello all, We would like to get suggestions and help on the matter of distributing the user location information. Extending the User Location with a built-in distributed support is not straight forward - it is not about simply sharing data - as it
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] Distributed User Location
Rudy, You are one step ahead :) - indeed, we need to find the best approach on the implementation side (different modules? flags/parameters?). But the current step is finding the solution : how the distributed version of usrloc would look like ? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 04/05/2013 03:51 PM, Rudy wrote: Bogdan, As you suggest, there are ways to achieve this now manually with custom scripting and glue, it its not very straightforward. What I think is the goal would be something drop in ready, that you could just enable for distributed location versus normal location. The solution may be to fork the registrar and usrloc modules into distributed versions of the modules. These would automatically support these distributed scenarios by using a combination of things discussed, and possibly a forced path flag that would route back to the home proxy by modifying the registrar request (perhaps with a path to home proxy). This way, it would not interfere with existing usage of these modules and allow for more flexibility when developing these new ones without breaking existing installations. What do you guys think? Thanks in advance, --Rudy Dynamic Packet Toll-Free: 888.929.VOIP ( 8647 ) On Fri, Apr 5, 2013 at 8:37 AM, Bogdan-Andrei Iancubog...@opensips.org wrote: Hello Muhammad, Your approach is the correct one (from SIP perspective) IMHO. But there are questions on the implementation side too - like the Super Node is just a storage or it should have SIP capabilities? How much of this behavior should be hardcoded in the registrar + usrloc module ? Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 04/05/2013 04:57 AM, Muhammad Shahzad wrote: Well at 5 am in the morning while thinking on this topic the only thing ringing in my mind is a mechanism similar to IP to IP Gateway. Here is the main concept. 1. We have number of SIP servers running, say sip1.mydomain.com, sip2.mydomain.com ... sipN.mydomain.com, each serving domain mydomain.com and a SIP client A can select any one of these servers through DNS look-up (or whatever way possible) and registers to that server. Lets call these servers as Base Nodes. 2. Upon successful registration of client A to server sip1.mydomain.com, this Registrar Node fires an Event, which can be subscribed by a back-end SIP server, lets call it Super Node. This event will only contain following things, a). User part of all Contact URIs of client A with Expiry. b). Registrar Node information e.g. its IP address + Port. c). SIP domain of client A. (in case of multi-domain setup) 3. Super Node stores this information in some db back-end (memcache, redis, mysql etc.). This is sort of back-to-back register process but without SIP or authentication, since that has already been handled on Based Node anyway. The Super Node only needs to know which user is registered on which Base Node e.g. user 1001 is registered on node sip1.mydomain.com, user 1203 is registered on sip6.mydomain.com and so on. 4. When a SIP client B tries to send INVITE or MESSAGE or SUBSCRIBE to SIP client A. The SIP request will arrive on Base Node it is currently registered with, say sip2.mydomain.com. This node will first do local look-up for location of client A. Upon failure it will forward request to Super Node, which will do a look-up on Event database and finds that client A is registered on node sip1.mydomain.com, so it will send SIP redirect response 302 to requester Base Node. Now the request source node knows the address of request destination node, where it will send request next and they both, while acting as independent SIP servers, establish SIP session between caller and callee. This should work regardless if both nodes serve same or different SIP domains. 5. The Super Node will also give us global presence of all users currently registered to all Base Nodes, which may be useful for management and monitoring etc. Pros: 1. Completely independent of network topology and SIP. 2. Will work seamlessly for multi and federated domains. 3. Scale-able in every direction. 4. Minimal overhead for session establishment. Once supper node return destination base node address in SIP redirect response, session will establish directly between source and destination base node. Further optimizations are possible, e.g. base node can cache destination base node returned by supper node for any particular user and avoid querying super node for recurring SIP sessions. Cons: 1. Well, the key problem i can guess is of course the Event database size and speed, as it will have information on every user registered to every Base Node. I suggest memory cache db such as Redis would be idle for this storage. 2. Bandwidth consumed in Event transport. We can apply compression and make event queues as optimization. Comments and suggestions are highly welcome. Thank
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] Distributed User Location
Well, i am not much familiar with internals of opensips, i.e. its core and modules and how they interact with each other. But as an abstract idea, i suggest that both Base Node and Super Node should be opensips modules. No change in standard registrar or usrloc modules are actually needed. In the Super Node module, we will have, 1. one db table to store base node addresses for monitoring the Event. 2. one db table to store data received from the Event, lets call it Event Table. 3. one process to manage Event Table, pretty much the same way location table is managed by usrloc module. 4. some scripting functions for opensips.cfg, to look up in Event Table and do SIP redirect. 5. some MI functions to manually manage base node table and event table. In the Base Node module, we will have, 1. module parameters to define address of Super Node and event advertise socket (Super Node will connect to this socket to receive events). 2. a process to monitor usrloc table, such that as soon as a new user registers, it advertise this to event socket. 3. some scripting functions for opensips.cfg, to send call to Super Node if lookup function (from registrar module) fails and in reply route to handle SIP Redirect to send call to destination base node returned by Super Node. 4. some MI functions etc. Thank you. On Fri, Apr 5, 2013 at 1:37 PM, Bogdan-Andrei Iancu bog...@opensips.orgwrote: ** Hello Muhammad, Your approach is the correct one (from SIP perspective) IMHO. But there are questions on the implementation side too - like the Super Node is just a storage or it should have SIP capabilities? How much of this behavior should be hardcoded in the registrar + usrloc module ? Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developerhttp://www.opensips-solutions.com On 04/05/2013 04:57 AM, Muhammad Shahzad wrote: Well at 5 am in the morning while thinking on this topic the only thing ringing in my mind is a mechanism similar to IP to IP Gateway. Here is the main concept. 1. We have number of SIP servers running, say sip1.mydomain.com, sip2.mydomain.com ... sipN.mydomain.com, each serving domain mydomain.comand a SIP client A can select any one of these servers through DNS look-up (or whatever way possible) and registers to that server. Lets call these servers as Base Nodes. 2. Upon successful registration of client A to server sip1.mydomain.com, this Registrar Node fires an Event, which can be subscribed by a back-end SIP server, lets call it Super Node. This event will only contain following things, a). User part of all Contact URIs of client A with Expiry. b). Registrar Node information e.g. its IP address + Port. c). SIP domain of client A. (in case of multi-domain setup) 3. Super Node stores this information in some db back-end (memcache, redis, mysql etc.). This is sort of back-to-back register process but without SIP or authentication, since that has already been handled on Based Node anyway. The Super Node only needs to know which user is registered on which Base Node e.g. user 1001 is registered on node sip1.mydomain.com, user 1203 is registered on sip6.mydomain.com and so on. 4. When a SIP client B tries to send INVITE or MESSAGE or SUBSCRIBE to SIP client A. The SIP request will arrive on Base Node it is currently registered with, say sip2.mydomain.com. This node will first do local look-up for location of client A. Upon failure it will forward request to Super Node, which will do a look-up on Event database and finds that client A is registered on node sip1.mydomain.com, so it will send SIP redirect response 302 to requester Base Node. Now the request source node knows the address of request destination node, where it will send request next and they both, while acting as independent SIP servers, establish SIP session between caller and callee. This should work regardless if both nodes serve same or different SIP domains. 5. The Super Node will also give us global presence of all users currently registered to all Base Nodes, which may be useful for management and monitoring etc. Pros: 1. Completely independent of network topology and SIP. 2. Will work seamlessly for multi and federated domains. 3. Scale-able in every direction. 4. Minimal overhead for session establishment. Once supper node return destination base node address in SIP redirect response, session will establish directly between source and destination base node. Further optimizations are possible, e.g. base node can cache destination base node returned by supper node for any particular user and avoid querying super node for recurring SIP sessions. Cons: 1. Well, the key problem i can guess is of course the Event database size and speed, as it will have information on every user registered to every Base Node. I suggest memory cache db such as Redis would be idle for this storage. 2. Bandwidth consumed in Event transport. We can apply compression
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [POLL] GitHub versus SourceForge for GIT and Tracker hosting
Hi all, First, thanks to all who spent the time and taking the vote. The results are quite conclusive, I would say : http://www.opensips.org/Vote/GitResult ~80% for going for GitHub. So, let's do it :). As a plan of attack: 1) repository a) converting SVN repo to GIT not a problem b) GIT on GITHUB (master repo) to replicate all commits to SVN on SF (to be kept as read only for the current checkouts) help wanted here c) installing GITHUB hooks for commits (email alerts) to be evaluated d) migrating all current developers from SF to GH not a problem 2) trackers a) create the corresponding trackers on GH to be done b) all new reports to be opened on GH, no new reports on SF not a problem c) existing long term reports from SF to be moved on GH not a problem 3) we celebrate :) Who ever has experience and wants to get involved in the above tasks, please step forward - we would love to get help for free ;). Best regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 03/26/2013 02:08 PM, Bogdan-Andrei Iancu wrote: Hi, Following the discussion on migrating the OpenSISP repository from SVN to GIT (see [1]), we are evaluating the option of migrating the primary hosting of the project from SF to GH - GIT repository, tracker. SF project is to be kept only for a read-only SVN (for current checkouts), which will be synced with master GIT repo on GITHUB. For taking a decision on this, we would like to know the opinion of you all, via a public poll: http://www.opensips.org/Vote/Git Please take your time to vote - your vote is important for us ;) [1] http://lists.opensips.org/pipermail/users/2013-February/024712.html Regards, ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3607052 ] Load balancer - corrupt data when loading table
Bugs item #3607052, was opened at 2013-03-06 07:08 Message generated for change (Comment added) made by umautone You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3607052group_id=232389 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: modules Group: 1.9.x Status: Open Resolution: None Priority: 5 Private: No Submitted By: Umberto Mautone (umautone) Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Load balancer - corrupt data when loading table Initial Comment: Tested on 1.9.x Data table: id | group_id | dst_uri | resources | probe_mode +--+---+---+ 19 |1 | sip:192.168.1.5 | pstn=100 | 0 20 |1 | sip:192.168.1.8 | pstn=100 | 0 21 |2 | sip:192.168.1.100 | pstn=2500 | 0 I added this line in lb_db_load_data() to log the actual table fields being loaded: LM_ERR(Fields: %d %d %s %s\n, id, group, uri, resource); The first row loads correctly but subsequent rows seem to lose a pointer alignment somewhere: Mar 6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:lb_db_load_data: Fields: 19 1 sip:192.168.1.5 pstn=100 Mar 6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:lb_db_load_data: Fields: 20 1 sip:192.168.1.8 ¥Ý9w#177 Mar 6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:parse_resources_list: resource must has value! Mar 6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:add_lb_dsturi: failed to parse resourse string ¥Ý9w#177 Mar 6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:lb_db_load_data: failed to add destination 1 - skipping Mar 6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:lb_db_load_data: Fields: 21 2 sip:192.168.1.100 192.168.1.5 Mar 6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:parse_resources_list: resource must has value! Mar 6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:add_lb_dsturi: failed to parse resourse string 192.168.1.5 Mar 6 10:01:53 localhost opensips[1796]: ERROR:load_balancer:lb_db_load_data: failed to add destination 1 - skipping Also tested in 1.8.2 and the problem is not present. The bug seems to be only in the 1.9.x branch. -- Comment By: Umberto Mautone (umautone) Date: 2013-04-05 14:04 Message: Sorry for taking so long. This is using PostgreSQL 9.2 with unixODBC on a 64 bit box. Here is the output with debug=4 on startup: === Apr 5 16:57:24 localhost opensips: WARNING:core:warn: warning in config file /usr//etc/opensips/opensips.cfg, line 44, column 13-16: tls support not compiled in Apr 5 16:57:24 localhost opensips: INFO:core:init_tcp: using epoll_lt as the TCP io watch method (auto detected) Apr 5 16:57:24 localhost opensips[13284]: NOTICE:core:main: version: opensips 1.9.0-notls (x86_64/linux) Apr 5 16:57:24 localhost opensips[13284]: INFO:core:main: using 32 Mb shared memory Apr 5 16:57:24 localhost opensips[13284]: INFO:core:main: using 2 Mb private memory per process Apr 5 16:57:24 localhost opensips[13284]: INFO:core:evi_publish_event: Registered event E_CORE_THRESHOLD(0) Apr 5 16:57:24 localhost opensips[13284]: INFO:core:evi_publish_event: Registered event E_CORE_SHM_THRESHOLD(1) Apr 5 16:57:24 localhost opensips[13284]: INFO:core:evi_publish_event: Registered event E_CORE_PKG_THRESHOLD(2) Apr 5 16:57:24 localhost opensips[13284]: NOTICE:signaling:mod_init: initializing module ... Apr 5 16:57:24 localhost opensips[13284]: INFO:sl:mod_init: Initializing StateLess engine Apr 5 16:57:24 localhost opensips[13284]: INFO:tm:mod_init: TM - initializing... Apr 5 16:57:24 localhost opensips[13284]: INFO:rr:mod_init: rr - initializing Apr 5 16:57:24 localhost opensips[13284]: INFO:maxfwd:mod_init: initializing... Apr 5 16:57:24 localhost opensips[13284]: INFO:sipmsgops:mod_init: initializing... Apr 5 16:57:24 localhost opensips[13284]: INFO:dialog:mod_init: Dialog module - initializing Apr 5 16:57:24 localhost opensips[13284]: INFO:load_balancer:mod_init: Load-Balancer module - initializing Apr 5 16:57:24 localhost opensips[13284]: ERROR:load_balancer:parse_resources_list: resource must has value! Apr 5 16:57:24 localhost opensips[13284]: ERROR:load_balancer:add_lb_dsturi: failed to parse resourse string HÿóÇ*#177 Apr 5 16:57:24 localhost opensips[13284]: ERROR:load_balancer:lb_db_load_data: failed to add destination 3 - skipping Apr 5 16:57:24 localhost opensips[13284]: ERROR:core:parse_uri: bad uri, state 0 parsed: 72.0 (4) / 1.2.3.179 (12) Apr 5 16:57:24 localhost opensips[13284]: ERROR:load_balancer:add_lb_dsturi: bad uri [1.2.3.179] for destination Apr 5 16:57:24 localhost opensips[13284]: ERROR:load_balancer:lb_db_load_data: failed to add destination 3 -
