sr-users October 2007

sr-users@lists.kamailio.org

130 participants
286 discussions

Re: [OpenSER-Users] Insert in location table very slow
by Alex Balashov 15 Oct '07

15 Oct '07

Gregorio, How long does it take? -- Alex On Mon, 15 Oct 2007, Gregorio wrote: > Hi all. > > > > I am using openSer 1.3 with mySQL. My problem is that although registration > is fast in SIP protocol terms, the contact binding is written in the > 'location' table long time after this contact has received a 200 OK to his > registration. So a user could think that he is registered before he is in > the data base. > > > > Could it be a configuration issue? > > Can I solve this? > > > > Thanks! > > > > This is my config: > > > > > > # ----------- global configuration parameters ------------------------ > > > > debug=2 # debug level (cmd line: -dddddddddd) > > log_facility=LOG_LOCAL7 > > fork=yes > > log_stderror=no children=4 > > port=5060 > > > > listen=udp:192.168.1.206:5060 > > listen=tcp:192.168.1.206:5060 > > > > # ------------------ module loading ---------------------------------- > > > > #set module path > > mpath="/usr/local/lib/openser/modules/" > > > > loadmodule "mysql.so" > > loadmodule "xlog.so" > > loadmodule "sl.so" > > loadmodule "tm.so" > > loadmodule "rr.so" > > loadmodule "maxfwd.so" > > loadmodule "usrloc.so" > > loadmodule "registrar.so" > > loadmodule "textops.so" > > loadmodule "auth.so" > > loadmodule "auth_db.so" > > > > loadmodule "presence.so" > > > > loadmodule "presence_xml.so" > > > > loadmodule "mi_fifo.so" > > > > loadmodule "mi_xmlrpc.so" > > > > # ----------------- setting module-specific parameters --------------- > > > > > > modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo") > > > > # -- usrloc params -- > > > > modparam("usrloc", "db_mode", 2) > > > > # -- auth params -- > > modparam("auth_db", "calculate_ha1", yes) > > modparam("auth_db", "password_column", "password") > > > > # -- rr params -- > > # add value to ;lr param to make some broken UAs happy > > modparam("rr", "enable_full_lr", 1) > > > > > > #Agnadido para la Presencia > > modparam("presence|usrloc|pua", > "db_url","mysql://openser:openserrw@127.0.0.1/openser") > > modparam("presence", "presentity_table", "presentity") > > modparam("presence", "active_watchers_table", "active_watchers") > > modparam("presence", "watchers_table", "watchers") > > modparam("presence", "clean_period", 100) > > modparam("presence", "max_expires", 3600) > > modparam("presence", "server_address", "sip:192.168.1.206:5060" ) > > > > #Presence_XML > > modparam("presence_xml", > "db_url","mysql://openser:openserrw@127.0.0.1/openser") > > modparam("presence_xml", "xcap_table", "xcap") > > modparam("presence_xml", "force_active", 1) > > modparam("presence_xml", "integrated_xcap_server", 1) > > modparam("presence_xml", "pidf_manipulation", 1) > > modparam("presence_xml", "pidf_manipulation", 1) > > > > #Mi FIFO > > modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo") > > modparam("mi_fifo", "fifo_mode", 0600) > > modparam("mi_fifo", "fifo_group", 0) > > modparam("mi_fifo", "fifo_group", "root") > > modparam("mi_fifo", "fifo_user", 0) > > modparam("mi_fifo", "fifo_user", "root") > > modparam("mi_fifo", "reply_dir", "/home/openser/tmp/") > > > > #Mi XMLRPC > > modparam("mi_xmlrpc", "port", 8080) > > modparam("mi_xmlrpc", "log_file", "/var/log/openser-xmlrpc.log") > > modparam("mi_xmlrpc", "reply_option", 0) > > modparam("mi_xmlrpc", "buffer_size", 8192) > > > > > > # ------------------------- request routing logic ------------------- > > > > # main routing logic > > > > route{ > > > > # initial sanity checks -- messages with > > # max_forwards==0, or excessively long requests > > > > if (!mf_process_maxfwd_header("10")) { > > sl_send_reply("483","Too Many Hops. Route filter"); > > exit; > > } > > > > if (msg:len >= max_len ) { > > sl_send_reply("513", "Message too big. Route filter"); > > exit; > > } > > > > if (!method=="REGISTER") > > record_route(); > > > > # subsequent messages withing a dialog should take the > > # path determined by record-routing > > if (loose_route()) { > > # mark routing logic in request > > append_hf("P-hint: rr-enforced\r\n"); > > route(1); > > }; > > if (uri==myself) { > > route(1); > > }; > > > > if (uri==myself) { > > # presence handling > > if( is_method("PUBLISH|SUBSCRIBE")){ > > route(2); > > }; > > > > if (is_present_hf("MyHeader")) > > { > > t_relay("192.168.1.111"); > > exit; > > }; > > > > > > if (method=="REGISTER") { > > # Uncomment this if you want to use digest > authentication > > if (!www_authorize("openserDialcom", "subscriber")) > { > > www_challenge("openserDialcom", "0"); > > exit; > > }; > > > > save("location"); > > exit; > > }; > > > > lookup("aliases"); > > if (!uri==myself) { > > append_hf("P-hint: outbound alias\r\n"); > > route(1); > > }; > > > > # native SIP destinations are handled using our USRLOC DB > > if (!lookup("location")) { > > sl_send_reply("404", "Not Found in openSer"); > > exit; > > }; > > append_hf("P-hint: usrloc applied\r\n"); > > }; > > > > route(1); > > } > > > > route[1] { > > # send it out now; use stateful forwarding as it works reliably > > # even for UDP2TCP > > if (!t_relay()) { > > sl_reply_error(); > > }; > > exit; > > } > > route[2] > > { > > # absorb retransmissions > > if (! t_newtran()) > > { > > sl_reply_error(); > > exit; > > }; > > > > if(is_method("PUBLISH")) > > { > > handle_publish(); > > t_release(); > > } else if( is_method("SUBSCRIBE")) { > > handle_subscribe(); > > t_release(); > > }; > > > > exit; > > } > > -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : +1-678-954-0670 Direct : +1-678-954-0671

2 1

[OpenSER-Users] Insert in location table very slow
by Gregorio 15 Oct '07

15 Oct '07

Hi all. I am using openSer 1.3 with mySQL. My problem is that although registration is fast in SIP protocol terms, the contact binding is written in the 'location' table long time after this contact has received a 200 OK to his registration. So a user could think that he is registered before he is in the data base. Could it be a configuration issue? Can I solve this? Thanks! This is my config: # ----------- global configuration parameters ------------------------ debug=2 # debug level (cmd line: -dddddddddd) log_facility=LOG_LOCAL7 fork=yes log_stderror=no children=4 port=5060 listen=udp:192.168.1.206:5060 listen=tcp:192.168.1.206:5060 # ------------------ module loading ---------------------------------- #set module path mpath="/usr/local/lib/openser/modules/" loadmodule "mysql.so" loadmodule "xlog.so" loadmodule "sl.so" loadmodule "tm.so" loadmodule "rr.so" loadmodule "maxfwd.so" loadmodule "usrloc.so" loadmodule "registrar.so" loadmodule "textops.so" loadmodule "auth.so" loadmodule "auth_db.so" loadmodule "presence.so" loadmodule "presence_xml.so" loadmodule "mi_fifo.so" loadmodule "mi_xmlrpc.so" # ----------------- setting module-specific parameters --------------- modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo") # -- usrloc params -- modparam("usrloc", "db_mode", 2) # -- auth params -- modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password") # -- rr params -- # add value to ;lr param to make some broken UAs happy modparam("rr", "enable_full_lr", 1) #Agnadido para la Presencia modparam("presence|usrloc|pua", "db_url","mysql://openser:openserrw@127.0.0.1/openser") modparam("presence", "presentity_table", "presentity") modparam("presence", "active_watchers_table", "active_watchers") modparam("presence", "watchers_table", "watchers") modparam("presence", "clean_period", 100) modparam("presence", "max_expires", 3600) modparam("presence", "server_address", "sip:192.168.1.206:5060" ) #Presence_XML modparam("presence_xml", "db_url","mysql://openser:openserrw@127.0.0.1/openser") modparam("presence_xml", "xcap_table", "xcap") modparam("presence_xml", "force_active", 1) modparam("presence_xml", "integrated_xcap_server", 1) modparam("presence_xml", "pidf_manipulation", 1) modparam("presence_xml", "pidf_manipulation", 1) #Mi FIFO modparam("mi_fifo", "fifo_name", "/tmp/openser_fifo") modparam("mi_fifo", "fifo_mode", 0600) modparam("mi_fifo", "fifo_group", 0) modparam("mi_fifo", "fifo_group", "root") modparam("mi_fifo", "fifo_user", 0) modparam("mi_fifo", "fifo_user", "root") modparam("mi_fifo", "reply_dir", "/home/openser/tmp/") #Mi XMLRPC modparam("mi_xmlrpc", "port", 8080) modparam("mi_xmlrpc", "log_file", "/var/log/openser-xmlrpc.log") modparam("mi_xmlrpc", "reply_option", 0) modparam("mi_xmlrpc", "buffer_size", 8192) # ------------------------- request routing logic ------------------- # main routing logic route{ # initial sanity checks -- messages with # max_forwards==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops. Route filter"); exit; } if (msg:len >= max_len ) { sl_send_reply("513", "Message too big. Route filter"); exit; } if (!method=="REGISTER") record_route(); # subsequent messages withing a dialog should take the # path determined by record-routing if (loose_route()) { # mark routing logic in request append_hf("P-hint: rr-enforced\r\n"); route(1); }; if (uri==myself) { route(1); }; if (uri==myself) { # presence handling if( is_method("PUBLISH|SUBSCRIBE")){ route(2); }; if (is_present_hf("MyHeader")) { t_relay("192.168.1.111"); exit; }; if (method=="REGISTER") { # Uncomment this if you want to use digest authentication if (!www_authorize("openserDialcom", "subscriber")) { www_challenge("openserDialcom", "0"); exit; }; save("location"); exit; }; lookup("aliases"); if (!uri==myself) { append_hf("P-hint: outbound alias\r\n"); route(1); }; # native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "Not Found in openSer"); exit; }; append_hf("P-hint: usrloc applied\r\n"); }; route(1); } route[1] { # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP if (!t_relay()) { sl_reply_error(); }; exit; } route[2] { # absorb retransmissions if (! t_newtran()) { sl_reply_error(); exit; }; if(is_method("PUBLISH")) { handle_publish(); t_release(); } else if( is_method("SUBSCRIBE")) { handle_subscribe(); t_release(); }; exit; }

1 0

[OpenSER-Users] PUA_MI: Error in state assignment
by Schumann Sebastian 15 Oct '07

15 Oct '07

Hello all. Upgrading my OpenSER trunk version from Rel. 2404 to 2920 I encounter problems using the PUA and PUA_MI module. I control the PUA via management interface. In the old version, I could update my presence information and also the non-expiration worked finally. Furthermore, expiring states with Expires: 0 worked as well. After upgrading to the new SVN version, the update does not work anymore. When an user, who changed his state to online and does not want any expiration, wants his state to expire (sends msg. with Expire: 0) at some point, the following error occurs: Oct 15 15:26:39 [15815] DBG:pua_mi:mi_pua_publish: send publish Oct 15 15:26:39 [15815] DBG:pua:send_publish: pres_uri=sip:aastra@10.96.115.125 Oct 15 15:26:39 [15815] DBG:pua:search_htable: core_hash= 256 Oct 15 15:26:39 [15815] DBG:pua:search_htable: record not found Oct 15 15:26:39 [15815] DBG:pua:send_publish: insert type Oct 15 15:26:39 [15815] DBG:pua:send_publish: request for a publish with expires 0 and no record found OpenSER cannot assign the proper state in the database and remove it. Instead, the user stays online "forever". A manual removal from the database is necessary. Where there major changes in the modules? I checked my config against the documentation and cannot find any major modifications I didn't already apply. Any hints for solving this issue are appreciated! Thanks for your help. Sebastian

1 0

[OpenSER-Users] Re: Openser-Perl module in onreply_route
by Murilo Lacerda Yoshida 15 Oct '07

15 Oct '07

Hi Mik, When I faced these problems with openser and DBI, I did a research, and if I remember it correctly, DBD::Sybase does not work correctly with output parameters. So one solution I guess would be you rewrite your procedure so that the parameter is only input and return the same parameter in a result set inside the procedure. That was one thing I had to do when I switched from DBD::ODBC to DBD::Sybase, as I had also some procedures with output parameters. After I rewrote the procedures and returned the output parameters as result sets I had no problems with this. HTH, Murilo -----Original Message----- From: users-bounces(a)openser.org [mailto:users-bounces@openser.org] On Behalf Of users-request(a)openser.org Sent: segunda-feira, 15 de outubro de 2007 08:04 To: users(a)openser.org Subject: Users Digest, Vol 29, Issue 47 Send Users mailing list submissions to users(a)openser.org To subscribe or unsubscribe via the World Wide Web, visit http://openser.org/cgi-bin/mailman/listinfo/users or, via email, send a message with subject or body 'help' to users-request(a)openser.org You can reach the person managing the list at users-owner(a)openser.org When replying, please edit your Subject line so it is more specific than "Re: Contents of Users digest..." Today's Topics: 1. Re: Multidomain and in-dialog REFER auth issue (I?aki Baz Castillo) 2. Changing db table names (Dan-Cristian Bogos) 3. Re: Openser-Perl module in onreply_route (Bastian Friedrich) 4. Re: t_relay(), forward() and send(): retransmissions? (samuel) 5. Re: t_relay(), forward() and send(): retransmissions? (I?aki Baz Castillo) 6. Re: t_relay(), forward() and send(): retransmissions? (Klaus Darilion) 7. Re: Multidomain and in-dialog REFER auth issue (Klaus Darilion) 8. Re: Multidomain and in-dialog REFER auth issue (Klaus Darilion) 9. Re: Multidomain and in-dialog REFER auth issue (I?aki Baz Castillo) 10. Re: Multidomain and in-dialog REFER auth issue (I?aki Baz Castillo) 11. Re: Multidomain and in-dialog REFER auth issue (I?aki Baz Castillo) 12. change status code in reply (Cseke Tamas) ---------------------------------------------------------------------- Message: 1 Date: Mon, 15 Oct 2007 10:13:22 +0200 From: I?aki Baz Castillo <ibc(a)in.ilimit.es> Subject: Re: [OpenSER-Users] Multidomain and in-dialog REFER auth issue To: users(a)openser.org Message-ID: <200710151013.22807.ibc(a)in.ilimit.es> Content-Type: text/plain; charset="iso-8859-1" El Monday 15 October 2007 09:58:36 Iñaki Baz Castillo escribió: > How can my OpenSer know which domain this REFER goes? of course the "To" > header is not valid at all. > > Could be a solution a SQL query to "location" table looking for the URI > (sip:userB@80.98.123.23:5060) and getting the username and domain of this? Anyway this solution wouldn't be secure since userA(a)domainA.com could hack its "From" header in the REFER and appears as "@domainB.com". So I think I need to store dialog info in a table (in the 200-OK), with those info: - "From" header domain - RURI domain - fromtag - totag - "Call-ID" header and query this table in REFER amtching fromtag, totag and Call-ID, and just allow the REFER is "From" header and RURI domain are the same. "Dialog" module is not valid for me since it doesn't store RURI. Any suggestion about it? Thanks a lot. -- Iñaki Baz Castillo ibc(a)in.ilimit.es ------------------------------ Message: 2 Date: Mon, 15 Oct 2007 10:15:31 +0200 From: "Dan-Cristian Bogos" <dan.bogos(a)gmail.com> Subject: [OpenSER-Users] Changing db table names To: "users openser.org" <users(a)openser.org> Message-ID: <40e285320710150115k78aa907co56a4a7a1748bbfc2(a)mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Hi All, I came to a situation where I need to use openser together with other apps on the same database, therefore I will need to change the table names. I know that most of the modules permit that on through config, but my concern is the table version, and the data which should be inside. Can anybody give me any hints on this issue? Ta, DanB ------------------------------ Message: 3 Date: Mon, 15 Oct 2007 10:19:20 +0200 From: Bastian Friedrich <bastian.friedrich(a)collax.com> Subject: Re: [OpenSER-Users] Openser-Perl module in onreply_route To: users(a)openser.org Message-ID: <200710151019.21008.bastian.friedrich(a)collax.com> Content-Type: text/plain; charset="iso-8859-1" Hi Mik, On Friday 12 October 2007, Mik Cheez wrote: > I had been using 'perl_exec' in my scripts with great success until I > decided to try using it in the onreply_route. The strangest thing now > happens; I use my perl script to write information to a database, and it > seems like the failure would have to be in DBI, but it only occurs in > Openser. a few weeks ago, someone else experienced problems when using DBI in OpenSER Perl scripts: http://openser.org/pipermail/users/2007-September/013388.html We currently do not have a proper solution for the problem, as the problems are created by DBI rather than by OpenSER. You might consider trying to establish some kind of OpenSER-internal locking mechanism for the DBI functions. Have you tried running your Perl script with only a single OpenSER instance (i.e. turning of forking)? Bastian -- Collax GmbH . Burkheimer Straße 3 . 79111 Freiburg . Germany p: +49 (0) 761-45684-24 f: +49 (0) 761-45684-10 www.collax.com Geschäftsführer: William K. Hite / Boris Nalbach AG München HRB 158898 . Ust.-IdNr: DE 814464942 \ Smash forehead on keyboard to continue. ------------------------------ Message: 4 Date: Mon, 15 Oct 2007 11:11:03 +0200 From: samuel <samu60(a)gmail.com> Subject: Re: [OpenSER-Users] t_relay(), forward() and send(): retransmissions? To: " I?aki Baz Castillo " <ibc(a)in.ilimit.es> Cc: users(a)openser.org Message-ID: <d18bd3a10710150211n5b0dd1e9oc75297296525c352(a)mail.gmail.com> Content-Type: text/plain; charset="iso-8859-1" forward() and send() are the stateless functions, which basically means they just send the message and forget the transaction. t_relay() is the statefull routing function, so whenever you use this function openSER will take care of the transaction FSM. hope it helps, sam 2007/10/15, Iñaki Baz Castillo <ibc(a)in.ilimit.es>: > > Hi, how do forward() and send() route the messages? do they > retransmissions as > t_relay()? > > Thanks. > > > -- > Iñaki Baz Castillo > ibc(a)in.ilimit.es > > _______________________________________________ > Users mailing list > Users(a)openser.org > http://openser.org/cgi-bin/mailman/listinfo/users >

1 0

[OpenSER-Users] Changing db table names
by Dan-Cristian Bogos 15 Oct '07

15 Oct '07

Hi All, I came to a situation where I need to use openser together with other apps on the same database, therefore I will need to change the table names. I know that most of the modules permit that on through config, but my concern is the table version, and the data which should be inside. Can anybody give me any hints on this issue? Ta, DanB

2 4

[OpenSER-Users] change status code in reply
by Cseke Tamas 15 Oct '07

15 Oct '07

Hello, I have the same problem what discussed in this thread: http://www.nabble.com/SF.net-SVN:-openser:--2835--trunk-modules-sl-t4533872… I'd like to change the status code, is it still inpossible with 1.2? I tried t_reply, sl_send_reply, replace functions but they don't work? Could you tell me any solution for this, if it is possible? Thanks any help, Tamas

1 0

[OpenSER-Users] t_relay(), forward() and send(): retransmissions?
by Iñaki Baz Castillo 15 Oct '07

15 Oct '07

Hi, how do forward() and send() route the messages? do they retransmissions as t_relay()? Thanks. -- Iñaki Baz Castillo ibc(a)in.ilimit.es

3 3

[OpenSER-Users] Openser-Perl module in onreply_route
by Mik Cheez 15 Oct '07

15 Oct '07

I had been using 'perl_exec' in my scripts with great success until I decided to try using it in the onreply_route. The strangest thing now happens; I use my perl script to write information to a database, and it seems like the failure would have to be in DBI, but it only occurs in Openser. I execute a stored procedure, and instead of doing this: exec procedurename @arg1 = '{sip status}', @arg2 = '{callid}' The procedure is called like this: declare @arg2 numeric({string length}) exec procedurename @arg1 = '{sip status}', @arg2 = '{callid}' output I have no idea where the thing is declaring @arg2 as an output variable. I can run my script manually forever and never get this message, but it happens about 50% of the time in Openser (i.e. half the time it works perfectly, without creating the output variable). I would try to run it somewhere else in my openser script, but the sip status isn't available in the request context (where I run similar scripts without any problems). The procedure is not supposed to return anything. Here's the function I created: ***** ***** use strict; use DBI; use DBI qw(:sql_types); use OpenSER qw ( log ); use OpenSER::Constants; use OpenSER::Message; sub proxy_onreply { my $m = shift; my $status; my $callid; my $sth; my $dbh; my $query; $status = $m->getStatus(); $callid = $m->pseudoVar("\$ci"); $dbh = DBI->connect("dbi:Sybase") || die "Database connection not made: $DBI::errstr"; $query = "exec procedurename \@arg1 = ?, \@arg1 = ?"; $sth = $dbh->prepare($query); $sth->bind_param(1, $status, SQL_VARCHAR); $sth->bind_param(2, $callid, SQL_VARCHAR); $sth->execute; $sth->finish; $dbh->disconnect(); } ***** ***** Any suggestions would be lovely. Best regards, Mik

2 1

[OpenSER-Users] Inbound SIP call to openser
by David Adade 15 Oct '07

15 Oct '07

Can somemone point me in the right direction. On a steep learning curve from asterisk to openser. I am tring to setup inbound PSTN to openser 1.2 I have registered nat clients. behind openser. How can i map DDI to nat clients I have already configure the nat clients in the subscriber table. Should i be looking at the Aliases table? Thanks in advance *********************************************************************** IMPORTANT NOTICE: The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you receive this in error, please contact the sender and delete the material from any computer. This e-mail is intended for the above named addressee only. Should you receive this e-mail in error please contact Customer Services on Tel: +44 (0)870 241 2439 ************************************************************************

2 1

[OpenSER-Users] "max_contacts", 1 and EI_R_TOO_MANY
by Jarkko Nevala 15 Oct '07

15 Oct '07

In OpenSER 1.2.0 EI_R_TOO_MANY has been defined by default as "Too many registered contacts" in modules/registrar/reply.c. This message is quite enough for me, but in which occations does UA get this message? I have modparam("registrar", "max_contacts", 1) in my configuration and every time I try to register another client with a username that allready has an AOR in locations table, I get response "503 Service Unavailable", not "503 Too many registered contacts". How should I modify reply.c to get "Too many registered contacts" when I have, well, too many registered contacts? I found this thread from the mailinglist http://www.mail-archive.com/users@openser.org/msg10796.html, but I do not think it really helps me, because the value of EI_R_TOO_MANY does not seem to effect the the response the second UA gets from the OpenSER. thank you JN

1 0

← Newer
1
...
15
16
17
18
19
20
21
...
29
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users October 2007