[OpenSIPS-Devel] Idea: Linking CPL with OpenSIPS' route scripts
Hello, I'm looking into the possibilities of the CPL module. Some thinking (included below) leads me to the conclusion that it would be ideal to have a better integration between CPL and the normal routing scripts, to simplify local extensions to the CPL syntax through additional XML namespaces. I can see two modular ways of supporting CPL extensions: 1. call main script routes from CPL to implement extensions; 2. map CPL to OpenSIPS' bytecode for normal routing scripts (I cannot find this bytecode for normal routing scripts in the source code, but assume it exists -- where should I look?) Being able to extend CPL without doing it in its module means that the flexibility of OpenSIPS' scripts is available to the administrator, and that CPL extensions are possible for local use. This gives the admin good control over a language with which users can flexibly specify their call routing. I'm very curious to your reactions to this line of thought! Best wishes, Rick van Rein OpenFortress --- 8< --- 8< --- 8< --- 8< --- 8< --- Specific Problems - There are many extensions to CPL that might be useful, and the RFC permits those through the use of name spaces... * SDP matching (Video? IPv6 and/or IPv4? blacklisted media IP?) * CPL-configured client authentication * Handle messaging through CPL All these could be made as CPL extensions, and could be implemented in the module. General Problem --- The CPL module in OpenSIPS could be expanded, but that would either be difficult to maintain, or it would mean publishing local wishes to the rest of the world. This could easily lead to an incredibly big CPL module... The functionality of the CPL module would end up replicating much of what is already part of OpenSIPS. Except that it lacked the flexibility that OpenSIPS has due to its scripts. The only advantage of the CPL form would be that it is per-user and that only those namespaces would be selected that implement what the administrator will permit. General Solution A better solution would seem to be to let CPL handling jump out to parts of the scripts. The already existing routes (including those for failure and reply) are well suited for this. Given an XML node, the configuration of the CPL module could then relay handling it to a main script route. It could pass arguments as script variables of some sort. modparam ("cpl-c", "xmlns", "urn:ietf:params:xml:ns:cpl cpl.xsd") modparam ("cpl-c", "hook xmpp:messaging", "CPLMESSAGE") modparam ("cpl-c", "failure_hook location", "CPLAUTH($userid,$realm)") modparam ("cpl-c", "xmlns:sdp", "http://what/ev/er";) modparam ("cpl-c", "hook sdp:address-family-switch", "SDPMATCH($patn):all-ipv6,all-ipv4,otherwise") An example of using the last structure would be (of course limited by the XML Schema for xmlns:sdp): This would enable CPL structures like: ... ... The hook, failure_hook and reply_hook options could be very generally applied by the CPL compiler by matching them with an XML Path expression, and then executed as the equivalent of: $patn = "$od"; route (SDPMATCH); if ($cplnext == "all-ipv6") { ... } elif ($cplnext == "all-ipv4") { ... } else { ... } An example of a useful XML Path to implement a route could be "/cpl/incoming//sdp:match" or "/cpl/incoming//location/busy". The variable $cplnext is defined as the CPL instruction variable to be used on returns, modparam ("cpl-c", "instruction_return_variable", "$cplnext") It is probably useful to handle a route return by simply moving on to the single next node. Specific Solutions -- To match against SDP, a hook could invoke a route, and return the result in a script variable. The handling in this route could use pattern matching, existing modules like the NAT helper, or define its own SDP-processing module that could even include loops over the SDP content (for all c= there should be an m= so that...) To provide client authentication, a failure route is invoked with parameters that specify the authentication triplet, with the username, realm and password. This makes an invocation of uac_client possible, and does not risk sharing credentials among CPL scripts. Alternately, one could define separate password entries within the incoming and outgoing sections, and use those to pass information to a route that stores them. To handle messaging, one could introduce a namespace with the corresponding routing statements, next to incoming and outgoing declarations. Remaining problems -- * Stored (binary) CPL scripts may be invalidated when the support for a facility is dropped from a script. This is difficult to relay to the users/creators of those scripts. ___ Devel mailing list Devel
[OpenSIPS-Devel] [ opensips-Patches-3564846 ] Linux futex support for locks
Patches item #3564846, was opened at 2012-09-04 16:33 Message generated for change (Settings changed) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3564846&group_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: core Group: trunk Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: Ryan Bullock (rrb3942) >Assigned to: Vladut-Stefan Paiu (vladut-paiu) Summary: Linux futex support for locks Initial Comment: This patch adds the option for using futexs under Linux with FAST_LOCK. Implementation was taken from http://people.redhat.com/drepper/futex.pdf, and modified to add support for an Adaptive Wait loop in the case of a single waiter. Uses a modified version of the tsl() fuction from fastlock.h as an atomic xchg operation. It uses gcc builtins for atomic cmpxchg. To use futexes FAST_LOCK and USE_FUTEX must both be defined. Since the logic for using the futex is notably different than FAST_LOCK it is implemented separately in futex_lock.h, however we still require FAST_LOCK be defined to ensure support for the atomic_xchg. In my testing, using opensips in a virtual machine allocated 2 processors and using 16 children in a fairly pathological locking scenario this shows a large performance boost over just FAST_LOCK. Some Benchmark numbers after 5 minutes of runtime with sipp attempting 1000 CPS with 6 second durations: USE_FUTEX Sep 4 15:06:00 labproxy /usr/local/sbin/opensips[17196]: benchmark (timer lock_test [0]): 309 [ msgs/total/min/max/avg - LR: 100/14797/21/2049/147.97 | GB: 599600/98709250/0/20102/987092.50] Sep 4 15:06:00 labproxy /usr/local/sbin/opensips[17202]: benchmark (timer lock_test [0]): 120 [ msgs/total/min/max/avg - LR: 100/15584/85/317/155.84 | GB: 599700/98724834/0/20102/987248.34] Sep 4 15:06:00 labproxy /usr/local/sbin/opensips[17192]: benchmark (timer lock_test [0]): 150 [ msgs/total/min/max/avg - LR: 100/19241/86/4076/192.41 | GB: 599800/98744075/0/20102/987440.75] Sep 4 15:06:00 labproxy /usr/local/sbin/opensips[17205]: benchmark (timer lock_test [0]): 124 [ msgs/total/min/max/avg - LR: 100/22005/74/6166/220.05 | GB: 599900/98766080/0/20102/987660.80] Sep 4 15:06:00 labproxy /usr/local/sbin/opensips[17206]: benchmark (timer lock_test [0]): 105 [ msgs/total/min/max/avg - LR: 100/19022/21/848/190.22 | GB: 60/98785102/0/20102/987851.02] Sep 4 15:06:01 labproxy /usr/local/sbin/opensips[17203]: benchmark (timer lock_test [0]): 155 [ msgs/total/min/max/avg - LR: 100/18633/85/1386/186.33 | GB: 600100/98803735/0/20102/988037.35] Sep 4 15:06:01 labproxy /usr/local/sbin/opensips[17203]: benchmark (timer lock_test [0]): 107 [ msgs/total/min/max/avg - LR: 100/18284/81/2873/182.84 | GB: 600200/98822019/0/20102/988220.19] Sep 4 15:06:01 labproxy /usr/local/sbin/opensips[17207]: benchmark (timer lock_test [0]): 106 [ msgs/total/min/max/avg - LR: 100/16327/83/747/163.27 | GB: 600300/98838346/0/20102/988383.46] Sep 4 15:06:01 labproxy /usr/local/sbin/opensips[17204]: benchmark (timer lock_test [0]): 40 [ msgs/total/min/max/avg - LR: 100/16664/27/5093/166.64 | GB: 600400/98855010/0/20102/988550.10] Sep 4 15:06:01 labproxy /usr/local/sbin/opensips[17205]: benchmark (timer lock_test [0]): 43 [ msgs/total/min/max/avg - LR: 100/4938/26/222/49.38 | GB: 600500/98859948/0/20102/988599.48] FAST_LOCK Sep 4 15:15:44 labproxy /usr/local/sbin/opensips[2360]: benchmark (timer lock_test [0]): 159 [ msgs/total/min/max/avg - LR: 100/16685/78/380/166.85 | GB: 600600/347519878/0/137058/3475198.78] Sep 4 15:15:44 labproxy /usr/local/sbin/opensips[2361]: benchmark (timer lock_test [0]): 153 [ msgs/total/min/max/avg - LR: 100/24353/0/2216/243.53 | GB: 600700/347544231/0/137058/3475442.31] Sep 4 15:15:44 labproxy /usr/local/sbin/opensips[2355]: benchmark (timer lock_test [0]): 95 [ msgs/total/min/max/avg - LR: 100/16816/75/465/168.16 | GB: 600800/347561047/0/137058/3475610.47] Sep 4 15:15:44 labproxy /usr/local/sbin/opensips[2359]: benchmark (timer lock_test [0]): 131 [ msgs/total/min/max/avg - LR: 100/20270/81/3535/202.70 | GB: 600900/347581317/0/137058/3475813.17] Sep 4 15:15:44 labproxy /usr/local/sbin/opensips[2346]: benchmark (timer lock_test [0]): 87 [ msgs/total/min/max/avg - LR: 100/17892/87/872/178.92 | GB: 601000/347599209/0/137058/3475992.09] Sep 4 15:15:44 labproxy /usr/local/sbin/opensips[2361]: benchmark (timer lock_test [0]): 178 [ msgs/total/min/max/avg - LR: 100/16425/81/354/164.25 | GB: 601100/347615634/0/137058/3476156.34] Sep 4 15:15:44 labproxy /usr/local/sbin/opensips[2351]: benchmark (timer lock_test [0]): 45 [ msgs/total/min/max/avg - LR: 100/14298/0/1367/142.98 | GB: 601200/347629
[OpenSIPS-Devel] [ opensips-Patches-3545859 ] Web Sockets VIA header parsing support
Patches item #3545859, was opened at 2012-07-19 05:32 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3545859&group_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: core Group: trunk Status: Open >Resolution: Accepted Priority: 5 Private: No Submitted By: Muhammad Shahzad (shari_786pk) >Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Web Sockets VIA header parsing support Initial Comment: This patch adds support for VIA header parsing for WS (Web Socket) and WSS (Web Socket Secure) protocols, allowing WebRTC clients to get registered and make calls using an intermediate proxy such as OverSIP. Using advanced OpenSIPs features like B2BUA and Topo-hiding etc., it may be possible to bridge WebRTC enabled and non-WebRTC enabled SIP endpoints to communicate with each other. The patch is tested against trunk and 1.8.x, whoever, it should work with 1.7.x and 1.6.x as well without any problem. -- >Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-12-07 02:57 Message: Hi Muhammad - thank for the patch - I will shortly review it and upload it on SVN trunk . Best regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3545859&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-3591017 ] Remove headers by wildcard
Patches item #3591017, was opened at 2012-11-29 05:13 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3591017&group_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: trunk Status: Open Resolution: None Priority: 5 Private: No Submitted By: https://www.google.com/accounts () >Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: Remove headers by wildcard Initial Comment: changes sipmsgops.c. uses fnmatch() to remove headers by wildcard. usage example: remove_hf_wc("P-hint*"); // removes all headers that start with P-hint remove_hf_wc("*orig-ip*"); //removes all headers that that have orig-ip in their name -- >Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-12-07 02:54 Message: Hi, First, I would suggest changing a bit the name of the function - having the "wc" token is not the most fortunate choice :) Secondly, I see you use file-name like wildcard - what about a more generic approach and using regexp ? Regards, Bogdan -- Comment By: https://www.google.com/accounts () Date: 2012-11-29 05:26 Message: attached a patch agains opensips_1_8 as well as trunk -- Comment By: https://www.google.com/accounts () Date: 2012-11-29 05:14 Message: by bratner : ratn...@gmail.com -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3591017&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Patches-3593300 ] setdebug Negative Levels
Patches item #3593300, was opened at 2012-12-06 12:12 Message generated for change (Comment added) made by bogdan_iancu You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3593300&group_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: core Group: 1.8.x >Status: Closed >Resolution: Accepted Priority: 5 Private: No Submitted By: David Sanders (dmsanders) >Assigned to: Bogdan-Andrei Iancu (bogdan_iancu) Summary: setdebug Negative Levels Initial Comment: Currently it is a scripting error to try and pass a negative value to setdebug (ie setdebug(-2)). Doing so it useful if you want to suppress errors in a section of your script while still allowing for critical and alert messages. The attached patch is a simple one line fix that allows negative numbers for setdebug. Note that I did not have a chance to regression test to make sure setdebug(1), etc still work correctly. The patch may also make setdebug(+2) valid, but I went for minimal code change for the patch. -- >Comment By: Bogdan-Andrei Iancu (bogdan_iancu) Date: 2012-12-07 02:43 Message: Hi David, Patch uploaded, thank you! Regards, Bogdan -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086412&aid=3593300&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[9483] branches/1.8/cfg.y
Revision: 9483 http://opensips.svn.sourceforge.net/opensips/?rev=9483&view=rev Author: bogdan_iancu Date: 2012-12-07 10:43:04 + (Fri, 07 Dec 2012) Log Message: --- backport from trunk (rev #9482): - fixed setdebug() to accept also negative logging levels (like -1 = L_ERR) Credits go to David Sanders Closes patch #3593300 Revision Links: -- http://opensips.svn.sourceforge.net/opensips/?rev=9482&view=rev Modified Paths: -- branches/1.8/cfg.y This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[9484] branches/1.7/cfg.y
Revision: 9484 http://opensips.svn.sourceforge.net/opensips/?rev=9484&view=rev Author: bogdan_iancu Date: 2012-12-07 10:43:05 + (Fri, 07 Dec 2012) Log Message: --- backport from trunk (rev #9482): - fixed setdebug() to accept also negative logging levels (like -1 = L_ERR) Credits go to David Sanders Closes patch #3593300 Revision Links: -- http://opensips.svn.sourceforge.net/opensips/?rev=9482&view=rev Modified Paths: -- branches/1.7/cfg.y This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] SF.net SVN: opensips:[9482] trunk/cfg.y
Revision: 9482 http://opensips.svn.sourceforge.net/opensips/?rev=9482&view=rev Author: bogdan_iancu Date: 2012-12-07 10:40:28 + (Fri, 07 Dec 2012) Log Message: --- - fixed setdebug() to accept also negative logging levels (like -1 = L_ERR) Credits go to David Sanders Closes patch #3593300 Modified Paths: -- trunk/cfg.y This was sent by the SourceForge.net collaborative development platform, the world's largest Open Source development site. ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
[OpenSIPS-Devel] [ opensips-Feature Requests-3593567 ] SIPMSGOPS: sipmsg_validate()
Feature Requests item #3593567, was opened at 2012-12-07 02:05 Message generated for change (Tracker Item Submitted) made by nikbyte You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=3593567&group_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: trunk Status: Open Priority: 5 Private: No Submitted By: Nick Altmann (nikbyte) Assigned to: Nobody/Anonymous (nobody) Summary: SIPMSGOPS: sipmsg_validate() Initial Comment: I suggest to add check to sipmsg_validate() for REGISTER has no totag. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=1086413&aid=3593567&group_id=232389 ___ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel