On 10/11/2010 12:31 PM, Henning Westerholt wrote: Hello I will add a patch later today(to master branch). Still some tests and documentation to write. Marius

Hello, thank you very much! Where exactly will I find the git for sip-router?? (sorry I'm new to all that) I'll be able to try it tomorrow and let you know if I can get it working... Regards, Nicolas -------- Original-Nachricht -------- -- GRATIS! Movie-FLAT mit über 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome

On 10/13/2010 05:25 PM, "Nicolas Rüger" wrote: Hello The patch is not yet ported to 3.1 (hadn't the time to test it to well but basic tests showed it worked). As this is a new feature I think it will be pushed into 3.1.1, so you have to wait a little longer for official release. The good news is that you can apply it from git: You can cherry-pick the patch from the master branch to 3.1 (local so don't worry) using cd /usr/local/src/kamailio-3.1.0 rm -rf kamailio #start with a new fresh clone git clone --depth 1 git://git.sip-router.org/sip-router kamailio cd kamailio git checkout -b 3.1 origin/3.1 #this is the new step git cherry-pick 2f8f8e58 You should then see something like Finished one cherry-pick. [3.1 e4f7cd8] modules_k/userblacklist : extended userblacklist module so also alphanumerical matches are possible 5 files changed, 86 insertions(+), 27 deletions(-) Then go ahead with the steps in the document. Marius

Hello, Sorry for the advice, -depth 1 means no commit history which is fine :D The patch I was referring is here http://git.sip-router.org/cgi-bin/gitweb.cgi?p=sip-router;a=commitdiff;h=2f… You can save it into a file (starting with the line diff --git a/modules_k/userblacklist/README b/modules_k/userblacklist/README) and use the "patch" utility to patch the module. Then compile. Marius ________________________________________ From: "Nicolas Rüger" [NicolasRueger(a)gmx.de] Sent: Wednesday, October 13, 2010 5:46 PM To: Marius Zbihlei Cc: sr-users(a)lists.sip-router.org Subject: Re: [SR-Users] userblacklist error using characters Hey Marius, thanks for the detailed answer but after git cherry-pick 2f8f8e58 I get the error: fatal: Cannot find '2f8f8e58' Any ideas??? Thank you. Regards, Nicolas -- GRATIS! Movie-FLAT mit über 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome

On 10/13/2010 09:57 PM, "Nicolas Rüger" wrote: Hello, Are you sure that you rebuilt userblacklist module after the patch (you can go to modules_k/userblacklist and run make from there)? Did the patch applied without error? Also, have you explicitly enabled the alpha numerical match mode modparam("userblacklist", "match_mode", 128) in you cfg file? Cheers Marius

On 10/14/2010 11:36 AM, "Nicolas Rüger" wrote: Hello You are right, I have never tested with $fU given so I was a bug in the code. It should be fixed by commit d128ac966beeb2ddfd3332a20fdd93ae292d81b1. The bug affected alphanum match mode only if the $fU had trailing non-digit chars. Can you check if it works... Thank you. Marius

On 10/14/2010 12:34 PM, "Nicolas Rüger" wrote: Hello You have to apply both patches , the original one (that introduced the new feature) and the bugfix. Marius

Hello, Marius Zbihlei has patched the userblacklist module, so that it can handle characters as well (NOT in main release 3.1 yet). Thanks Marius. Therefore it might now be possible to filter general SIP-URIs!?? My idea is simple and described here. Please give some Feedback!!! As the "prefix"-functionality up to now was referring to SIP-URIs consisting of digits (=real telephon numbers) like 004930123456(a)1und1.de the general URI might be something like my_user_001(a)server.domain.de So far the "prefix"-functionality works because usernames that are real telephone numbers, that always start with country-code, followed by town- or regional-code and end with a unique number of the user (in this example 0049=Germany, (0)30=Berlin, 123456=user's unique number). To use "prefix"-functionality with general (including non-digits) URIs it must be evaluated reverse (from back to front) as the domain ends with the country- or top-level-domain and becomes more detailed the reverse way. So the IDEA is: Insert the domain as prefix in userblacklist-table in reverse, to use the functionality. I would use a perl-script to reverse the SIP-URI of the calling party in routing logic and then check it against the already reverted domain in the userblacklist-table. Do you think this is a good/well-working idea??? Any concerns or suggestions are appreciated... Regards, Nicolas -- GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl

Hi, On 14.10.2010 17:50, "Nicolas Rüger" wrote: "Flag to be used for marking if a dialog should be constructed for the current request (this make sense only for initial requests)." "dlg_flag" marks the flag which, when enabled, causes the module to track the dialog. I've never used dlg_manage() to start tracking myself but cannot recognize any wrong usage. Can you enable flag 4 at the top of your route block and check if it fills the DB then? Cheers, --Timo

Hey, On 14.10.2010 18:22, Nathan Angelacos wrote: Are you sure dlg_manage() is really required to be called on every message of the dialog (or supposed to be used that way)? If you look at dialog.c, w_dlg_manage() simply call's dlg_handlers.c's dlg_new_dialog() which is also called for new INVITE messages when the flag is set. So AFAICS, it should set up dialog tracking quite similarly and have it work without any further interaction. Cheers, --Timo

On 10/14/10 09:41, Ovidiu Sas wrote: Thanks Ovidiu!

Timo & Ovidiu, Yes, you are correct. Thanks! So, hopefully this is better: route { # Initial invite only if (is_method("INVITE") && (! has_totag() ) ) { dlg_manage(); } if (is_method("BYE")) { xlog ("L_INFO", "Completed $dlg(from_uri) to $dlg(to_uri) - $DLG_lifetime duration"); } }

Hi Nicolas, On 10/14/10 11:58, "Nicolas Rüger" wrote: You should see something in the DB only as long as the call is in progress. make sure you route all the messages through your proxy, and I believe you need loose_route as well: record_route(); loose_route(); Hope this is helpful.

Hi all, ok I figured out now, that dialog module is not the right choice for me, as it stores the data not after the dialog is closed. I could see the traces during the dialog in datbase finally. Thanks for your help... I'll post my question for a tracing mechanism with another more accurate subject to the list again. Regards, Nicolas -- GMX DSL Doppel-Flat ab 19,99 €/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl