[OpenSIPS-Devel] [RFC] Distributed User Location
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 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3610016 ] Memory Leak RabbitMQ
Bugs item #3610016, was opened at 2013-04-04 06:56 Message generated for change (Tracker Item Submitted) made by digipigeon You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610016group_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: Digipigeon (digipigeon) Assigned to: Nobody/Anonymous (nobody) Summary: Memory Leak RabbitMQ Initial Comment: After upgrading from 1.8.2 to 1.9.x (latest), and also confirming the error on the trunk head. I am getting crashes of opensips: CRITICAL:core:qm_free: freeing already freed pointer, first free: rabbitmq_send.c: rmq_process(323) - aborting CRITICAL:core:qm_free: freeing already freed pointer, first free: dlg_profile.c: destroy_linkers(610) - aborting BT FULL #0 0x7fac6d858425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #1 0x7fac6d85bb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #2 0x00503425 in qm_free (qm=optimised out, p=0x7fac0be20d80, file=optimised out, func=optimised out, line=optimised out) at mem/q_malloc.c:450 f = optimised out size = optimised out __FUNCTION__ = qm_free #3 0x7fac63049bb7 in rmq_process (rank=optimised out) at rabbitmq_send.c:323 __FUNCTION__ = rmq_process #4 0x004b585d in start_module_procs () at sr_module.c:585 m = 0x7fac6985a850 n = optimised out l = optimised out x = optimised out __FUNCTION__ = start_module_procs #5 0x00414edc in main_loop () at main.c:818 i = optimised out pid = optimised out si = optimised out startup_done = 0x0 chd_rank = 0 rc = optimised out load_p = 0x0 #6 main (argc=optimised out, argv=optimised out) at main.c:1557 cfg_log_stderr = optimised out cfg_stream = optimised out c = optimised out r = optimised out tmp = 0x7fff847dcf81 tmp_len = optimised out port = optimised out proto = optimised out options = 0x5843d0 f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o: ret = -1 seed = 2612855874 rfd = -496847072 __FUNCTION__ = main I believe that the problem is related to rabbitmq module, as it does not appear to crash when I don't use enable the module -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610016group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3610016 ] Memory Leak RabbitMQ
Bugs item #3610016, was opened at 2013-04-04 06:56 Message generated for change (Comment added) made by razvancrainea You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610016group_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: Digipigeon (digipigeon) Assigned to: Razvan Crainea (razvancrainea) Summary: Memory Leak RabbitMQ Initial Comment: After upgrading from 1.8.2 to 1.9.x (latest), and also confirming the error on the trunk head. I am getting crashes of opensips: CRITICAL:core:qm_free: freeing already freed pointer, first free: rabbitmq_send.c: rmq_process(323) - aborting CRITICAL:core:qm_free: freeing already freed pointer, first free: dlg_profile.c: destroy_linkers(610) - aborting BT FULL #0 0x7fac6d858425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #1 0x7fac6d85bb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #2 0x00503425 in qm_free (qm=optimised out, p=0x7fac0be20d80, file=optimised out, func=optimised out, line=optimised out) at mem/q_malloc.c:450 f = optimised out size = optimised out __FUNCTION__ = qm_free #3 0x7fac63049bb7 in rmq_process (rank=optimised out) at rabbitmq_send.c:323 __FUNCTION__ = rmq_process #4 0x004b585d in start_module_procs () at sr_module.c:585 m = 0x7fac6985a850 n = optimised out l = optimised out x = optimised out __FUNCTION__ = start_module_procs #5 0x00414edc in main_loop () at main.c:818 i = optimised out pid = optimised out si = optimised out startup_done = 0x0 chd_rank = 0 rc = optimised out load_p = 0x0 #6 main (argc=optimised out, argv=optimised out) at main.c:1557 cfg_log_stderr = optimised out cfg_stream = optimised out c = optimised out r = optimised out tmp = 0x7fff847dcf81 tmp_len = optimised out port = optimised out proto = optimised out options = 0x5843d0 f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o: ret = -1 seed = 2612855874 rfd = -496847072 __FUNCTION__ = main I believe that the problem is related to rabbitmq module, as it does not appear to crash when I don't use enable the module -- Comment By: Razvan Crainea (razvancrainea) Date: 2013-04-04 07:21 Message: Hi! Does this happen at startup or later, at runtime? Do you see any errors before opensips displays the Critical warning? Also, can you confirm that the two Critical messages are from different runs. Finally, please confirm that after removing the rabbitmq you are able to run your platform normally. Best regards, Răzvan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610016group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3610016 ] Memory Leak RabbitMQ
Bugs item #3610016, was opened at 2013-04-04 06:56 Message generated for change (Comment added) made by digipigeon You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610016group_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: Digipigeon (digipigeon) Assigned to: Razvan Crainea (razvancrainea) Summary: Memory Leak RabbitMQ Initial Comment: After upgrading from 1.8.2 to 1.9.x (latest), and also confirming the error on the trunk head. I am getting crashes of opensips: CRITICAL:core:qm_free: freeing already freed pointer, first free: rabbitmq_send.c: rmq_process(323) - aborting CRITICAL:core:qm_free: freeing already freed pointer, first free: dlg_profile.c: destroy_linkers(610) - aborting BT FULL #0 0x7fac6d858425 in raise () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #1 0x7fac6d85bb8b in abort () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #2 0x00503425 in qm_free (qm=optimised out, p=0x7fac0be20d80, file=optimised out, func=optimised out, line=optimised out) at mem/q_malloc.c:450 f = optimised out size = optimised out __FUNCTION__ = qm_free #3 0x7fac63049bb7 in rmq_process (rank=optimised out) at rabbitmq_send.c:323 __FUNCTION__ = rmq_process #4 0x004b585d in start_module_procs () at sr_module.c:585 m = 0x7fac6985a850 n = optimised out l = optimised out x = optimised out __FUNCTION__ = start_module_procs #5 0x00414edc in main_loop () at main.c:818 i = optimised out pid = optimised out si = optimised out startup_done = 0x0 chd_rank = 0 rc = optimised out load_p = 0x0 #6 main (argc=optimised out, argv=optimised out) at main.c:1557 cfg_log_stderr = optimised out cfg_stream = optimised out c = optimised out r = optimised out tmp = 0x7fff847dcf81 tmp_len = optimised out port = optimised out proto = optimised out options = 0x5843d0 f:cCm:M:b:l:n:N:rRvdDETSVhw:t:u:g:P:G:W:o: ret = -1 seed = 2612855874 rfd = -496847072 __FUNCTION__ = main I believe that the problem is related to rabbitmq module, as it does not appear to crash when I don't use enable the module -- Comment By: Digipigeon (digipigeon) Date: 2013-04-04 07:28 Message: Hi, The problem does not happen at start-up. I haven't noticed any other errors apart from what I have wrote. Those two messages were from the same run, they were output just before opensips crashed. At present I am 2 hours into running ver 1.9 (excluding rabbitmq), without any crashes or error messages. Previously the crash happened within the first 15 minutes, so I believe that it is stable, but I will update if this instance crashes. Regards Jonathan -- Comment By: Razvan Crainea (razvancrainea) Date: 2013-04-04 07:21 Message: Hi! Does this happen at startup or later, at runtime? Do you see any errors before opensips displays the Critical warning? Also, can you confirm that the two Critical messages are from different runs. Finally, please confirm that after removing the rabbitmq you are able to run your platform normally. Best regards, Răzvan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610016group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Bugs-3610045 ] [DROUTING] Crash on use_next_gw/get_gw_by_id
Bugs item #3610045, was opened at 2013-04-04 15:31 Message generated for change (Tracker Item Submitted) made by r0nald11 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610045group_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: Ronald Cepres (r0nald11) Assigned to: Nobody/Anonymous (nobody) Summary: [DROUTING] Crash on use_next_gw/get_gw_by_id Initial Comment: Drouting crashes when selecting next gateway. Did a little investigation, and FWIW the next gateway's carrier status is disabled but the carrier's only gateway is enabled. Looked at the backtrace of the core dump, and found that it crashed while comparing two strings on get_gw_by_id called by use_next_gw. The strings compared were apparently GW ID strings. I attached the GDB btfull logs (replaced some sensitive info with dummy text) for reference. Take note that 'dont optimize' flag was not set so some of the values were optimized and the crash happened randomly so I can't actually reproduce the crash. I'm using Opensips 1.9 using this source tarball: http://opensips.org/pub/opensips/latest/src/opensips-1.9.0_src.tar.gz -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=1086410aid=3610045group_id=232389 ___ 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
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 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 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 http://www.opensips-solutions.com __**_ Users mailing list us...@lists.opensips.org http://lists.opensips.org/cgi-**bin/mailman/listinfo/usershttp://lists.opensips.org/cgi-bin/mailman/listinfo/users -- Mit freundlichen Grüßen Muhammad Shahzad --- CISCO Rich Media Communication Specialist (CRMCS) CISCO
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RFC] Distributed User Location
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 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
