On 10/12/10 12:23 PM, "Nicolas Rüger" wrote:

Hello Daniel,

sounds like you're planning to change it, so that one can pass variables via perl_exec()!?

It was not in my plans, I said that development for passing kamailio cfg variables to second parameter of perl_exec() won't be big effort. I'll add it to my to-do list, but I cannot say when I will do it. You can use meanwhile Alex's solution with avps.

Cheers, Daniel

Did I understand you correctly!?

Any idea when this will be ready to use?

Sorry, for bothering you, but I need it for my thesis and the deadline is soon ;)

Thank you...

Regards,

Nicolas

-------- Original-Nachricht --------

...

Datum: Mon, 11 Oct 2010 23:48:12 +0200 Von: Daniel-Constantin Mierlamiconda@gmail.com An: "Nicolas Rüger"NicolasRueger@gmx.de CC: sr-users@lists.sip-router.org Betreff: Re: [SR-Users] Fwd: perl_exec() using parameter? Hello,

On 10/11/10 2:06 PM, "Nicolas Rüger" wrote:

...

Hello,

any ideas for parameter passing to perl-scripts are appreciated!!!

as I understand the documentation, perl_exec() executes a function in Perl script set by filename parameter.

I checked the sources and the second parameter to perl exec is considered static string. It won't be lot of work to make it dynamic PV container. For now you can use Alex's suggestion with passing via variables.

Cheers, Daniel

...

Regards,

Nicolas

-------- original--------

Hello,

is there any chance to pass parameters (like from_uri or to_uri) from

the kamailio routing logic to a perl script?

...

I know that the whole sip message is provided as parameter but I wonder

if there's a way to pass just the caller's uri (from tag) or the callee's uri (to tag) as a second parameter to the perl script.

...

By using xlog it's clear that in $fu and $ru one can find the uri's.

xlog("from: $fu to: $ru \n")

OUTPUT: "from: sip:user01@mykamailio.de to:user02@mykamailio.de"

BUT using these variables as a second parameter in perl_exec() leads to

an error on kamailio start-up cause of bad config file.

...

perl_exec("my_perl_script",$fu);

Any suggestions or ideas???

Thank you...

Regards,

Nicolas

-- Daniel-Constantin Mierla http://www.asipto.com

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Hello,

I am looking for a possibility to trace kamailio on a per call basis.

I need something like...

id | caller | callee | start_time | end_time | ...

as a table in the kamailio database because I want to evaluate these CDRs for SPIT-Prevention.

Therefore I need these traces to be stored in database even after the call has ended.

My alternative idea is to use perl-scripts to print the needed values in database for each call.

Any suggestion or feedback is appreciated!!!

Thank you!

Regards,

Nicolas

Hello,

thank you. That's been one of my thougts as well but I guess I gonna try the idea with using perl-scripts then instead because I need the following attributes and I guess dialog module doesn't provide all of them, right!?

- caller - callee - start_time (and date) --> timestamped at initial "INVITE" - media_start_time --> timestamped at "ACK" after "OK" - end_time (and date) --> timestamped at "BYE" or "CANCEL" - last_response_code

and maybe some more...

So using perl seems more flexible then I guess...

Regards,

Nicolas

P.S. more suggestions are still appreciated!

-------- Original-Nachricht --------

Datum: Fri, 15 Oct 2010 16:06:25 +0200 Von: Morten Isaksen misak@misak.dk An: sr-users@lists.sip-router.org Betreff: Re: [SR-Users] calltrace mechanism available?

Hi,

You could use the dialog module and then create a trigger in mysql that insert the row to be deleted in another table.

/Morten

On Fri, Oct 15, 2010 at 4:00 PM, "Nicolas Rüger" NicolasRueger@gmx.de wrote:

...

Hello,

I am looking for a possibility to trace kamailio on a per call basis.

I need something like...

id | caller | callee | start_time | end_time | ...

as a table in the kamailio database because I want to evaluate these

CDRs for SPIT-Prevention.

...

Therefore I need these traces to be stored in database even after the

call has ended.

...

My alternative idea is to use perl-scripts to print the needed values in

database for each call.

...

Any suggestion or feedback is appreciated!!!

Thank you!

Regards,

Nicolas

GRATIS! Movie-FLAT mit über 300 Videos. Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

-- Morten Isaksen

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Hi Henning,

thanks for the tips.

I checked the ACC module but the documentation says that it's just for transactions and not for a whole session or even a call.

"There is no session/dialog accounting (yet) -- Kamailio maintains no sessions. If one needs to correlate INVITEs with BYEs for generating proper CDRs for example for purpose of billing, then it is better done in the entity which processes accounting information."

I checked SIPTRACE module but it doesn't trace all the data I need.

Therefore my conclusion was that my requirements might be too specific end that I've to find a solution on my own using PERL module for scripting and filling my own table.

To remind, here is the data I need at least:

- caller - callee - start_time (and date) --> timestamped at initial "INVITE" - media_start_time --> timestamped at "ACK" after "OK" - end_time (and date) --> timestamped at "BYE" or "CANCEL" - last_response_code

Sorry if my messages have been confusing. I tried to keep the mail subject as long as someone answers to the topic....like a thread. Isn't that the right way?

I will try to change the mail subjects more often to more adequate ones in future if that's better. Writing in such a list is new to me. Please tell me when I make mistakes.

Regards,

Nicolas

Hi Nicolas,

if you want to create CDRs, take a look to the acc (accouting) module. If you want to store signalisation, maybe the siptrace module is helpful as well.

Just one small thing, your questions will be more visible if you create a new thread (send a new mail) instead of re-using an existing one and just reply to an old message.

Cheers,

Henning

On 18 October 2010 17:16, Henning Westerholt henning.westerholt@1und1.dewrote:

On Monday 18 October 2010, Nicolas Rüger wrote:

...

[..] thanks for the tips.

I checked the ACC module but the documentation says that it's just for transactions and not for a whole session or even a call.

Hi Nicolas,

indeed, the ACC module only keep track of sessions. But you could use this information then with the help of a "CDR engine" to actually get some CDRs (likely the information you want) from it. This could be some perl script as you suggested, you could do it in the DB layer, or in something else, like in the configuration script with the help of the dialog module.

...

Sorry if my messages have been confusing. I tried to keep the mail

subject

...

as long as someone answers to the topic....like a thread. Isn't that the right way?

Don't worry, maybe it was also the fault of my email client that the mail showed up as it was belonging to some other thread.

...

I will try to change the mail subjects more often to more adequate ones

in

...

future if that's better. Writing in such a list is new to me. Please tell me when I make mistakes.

Thanks and regards,

Henning

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Nicolas,

This information is all available if you use the accounting module and are using dialog and mediaproxy also.

Thanks Brian

Hello,

I'm using the "userblacklist" module in kamailio 3.1.

I just experienced that the routing logic function "check_blacklist()" that refers to globalblacklist table in database does not check the caller's URI but checks the callee's URI instead.

I want to change that for me, as I need a global blacklist table for blacklisting some caller's URIs globally.

I guess I have to change parts of the file "userblacklist.c" for modifying the functionality.

I'm not sure but I guess the following lines from "userblacklist.c" are the ones to change.

[...]

if ((parse_sip_msg_uri(msg) < 0) || (!msg->parsed_uri.user.s) || (msg->parsed_uri.user.len > MAXNUMBERLEN)) { LM_ERR("cannot parse msg URI\n"); return -1; } strncpy(req_number, msg->parsed_uri.user.s, msg->parsed_uri.user.len);

[...]

I guess I have to change "msg->parsed_uri.user.s" to something that returns the caller instead of the callee!?

So 2 questions...

1.) Am I right? 2.) How to change to return the caller instead of callee?

Thank you...

Regards,

Nicolas

hi,

yes I agree, that might be the best way.

I am just not an experienced programmer and I thought it might be easier for me just to change "msg->parsed_uri.user.s" to something that returns the caller instead of the callee.

Do you think that adding a parameter is not that complicated?

Regards,

Nicolas

you should add a new parameter to check_blacklist() function that contains the uri the check is done against. see the other two functions of the module for examples.

-- juha

hi juha,

what about the idea to just copy the function "check_blacklist()" change the parsed variable as I need to and then store it as "check_blacklist_1()"!?

Sounds much easier to me as an unexperienced user...

In this case the old functionality is still available (no cfg changes required) and one can even use both functionalities at the same time as they may refer to different tables in database as one can pass the table as parameter already from routing logic.

What do you think?

Regards,

Nicolas

---

...

I am just not an experienced programmer and I thought it might be easier for me just to change "msg->parsed_uri.user.s" to something that returns the caller instead of the callee.

if you do that then you need to keep on patching sr yourself. if you param, you can submit your patch to be included in the module.

...

Do you think that adding a parameter is not that complicated?

no it is not that complicated. there are lots of examples in the modules on how to do it. in this case a little complication comes from the fact that the function already has an optional parameter. you would need to make the syntax look like

check_blacklist ([string table, uri]).

-- juha

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users

Hello,

On 10/15/10 5:21 PM, "Nicolas Rüger" wrote:

Hello,

just realized that something like the following works now with kamailio v3.1...

perl_exec("mytest",$fu);

Whoever changed it...THANK YOU :)

right, this is probably due to Andrei's new API for module functions that identify script variables given as parameters and expand them at runtime.

Report if you have troubles with them, the new API will take over in the next releases, meanwhile it needs to be tested.

Cheers, Daniel

Regards,

Nicolas

...

thanks for adding it to the list. The feature would help me a lot.

In the meanwhile...

I tried to use AVPs instead, but didn't work. I guess I use them in a wrong way...!?

$avp(i:3) = $fu;
perl_exec("mytest","$avp(i:3)");

Using these lines "$avp(i:3)" is passed as a static string again of course.

So how can I pass something like "the value of $fu" from routing logic to my perl script then???

Thank you.

Regards,

Nicolas

...

It was not in my plans, I said that development for passing kamailio cfg variables to second parameter of perl_exec() won't be big effort. I'll add it to my to-do list, but I cannot say when I will do it. You can use meanwhile Alex's solution with avps.

Cheers, Daniel

-- GMX DSL Doppel-Flat ab 19,99&euro;/mtl.! Jetzt auch mit gratis Notebook-Flat! http://portal.gmx.net/de/go/dsl

---

SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users