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
Re: [OpenSIPS-Devel] [OpenSIPS-Users] [RELEASE] 1.9 Major Release becomes stable GA today!
Fantastic! Another amazing release full of exciting features to explore. Thanks to everyone for their contributions. Best regards, --Rudy Dynamic Packet Toll-Free: 888.929.VOIP ( 8647 ) On Wed, Feb 27, 2013 at 1:48 PM, Brett Nemeroff br...@nemeroff.com wrote: Great job guys! This is one exciting build -Brett On Wed, Feb 27, 2013 at 12:13 PM, Bogdan-Andrei Iancu bog...@opensips.org wrote: After one month of successful beta testing, the 1.9.0 major released turned into a fully stable GA releasesuitable for production usage. Feel free to download and torture it - it will proudly do the job for you :) ! Once again, many thanks to all people who got involved in the testing, reporting and fixing during the beta stage - it was a great job: http://opensips.svn.sourceforge.net/viewvc/opensips/branches/1.9/CREDITS Regards, Bogdan ___ 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-Patches-3513177 ] Substitutions in configuration file
Bogdan, Hey buddy! Conditionals are important too and m4 is a great tool, don't get me wrong. It ends up being case of many ways to skin the cat as they say. I think whats happening is just a result of OpenSIPs continued growth. There is a demand not simply for OpenSIPs as a component, but more as a platform for building solutions. This is something we should all keep in mind when continuing to push in different directions when extending OpenSIPs. Perhaps there is a happy medium for everyone here... maybe Nick can write a patch for opensipsctl where it would run m4 against config.m4 if it exists and compile it into config before starting opensips. Nick, keep in mind, you should handle not just opensips.cfg but any file passed as a -f argument in STARTOPTIONS env variable. What do you think about this Bogdan? I would be in support of such a change and it should be seamless to everyone else. Thanks in advance, --Rudy Dynamic Packet Toll-Free: 888.929.VOIP ( 8647 ) On Mon, Apr 2, 2012 at 11:52 AM, Bogdan-Andrei Iancu bog...@opensips.org wrote: ups...forgot the most important - the conditionals ;) Regards, Bogdan On 04/02/2012 06:49 PM, Bogdan-Andrei Iancu wrote: Hi Rudy, Even if you asked Saul, let me tell you I'm using m4 for - not only for define like replacement, but also for more advanced stuff like simulating functions, simple functions, or loops (to repeat blocks of scripts with different input, just to make it nicer). Regards, Bogdan On 03/30/2012 10:00 PM, Rudy wrote: Hi All, Not that I particularly support the addition of substitutions inside the current config parser, but one thing I have wanted myself is something similar to defines. Flipping the question to Saul, assuming we are all familiar with m4, what kind of parser additions would you need to completely omit m4 from your current configurations? This seems to be like an opportunity to brainstorm some new ideas, not only for 1.x branch, but possibly for 2.0 configuration files. Thanks in advance, --Rudy Dynamic Packet Toll-Free: 888.929.VOIP ( 8647 ) On Fri, Mar 30, 2012 at 1:43 PM, Saúl Ibarra Corretgé s...@ag-projects.com wrote: Hi, On Mar 30, 2012, at 4:22 PM, Nick Altmann wrote: I'm not agree with you, because I use m4 now. Such functionality was really useful together with include functionality. For example, when I have errors with m4 it's hard to understand in what line these errors occurred. m4 is not always convenient, I should compile my configuration every time, but I don't need all power of m4, I need only substitutions. m4 is not a panacea for all occasions. I agree with Vlad here. I maintain a huge configuration file consisting of several m4 files and never felt the need to stretch the configuration file syntax. Regards, -- Saúl Ibarra Corretgé AG Projects ___ 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 -- Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com ___ 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
[OpenSIPS-Devel] Patch for sipmsgops, adding change_reply_status
Team, Attached is a patch for trunk that adds change_reply_status() to the sipmsgops module. This useful in various scenarios when you need to convert a specific reply from one to another without completely discarding the reply. Regards, --Rudy Dynamic Packet Toll-Free: 888.929.VOIP ( 8647 ) sipmsgops.patch Description: Binary data ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
