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;
}
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
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
>
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
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
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
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
************************************************************************
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
Hi,
I just uploaded the materials used during the OpenSER Admin Course in
Rome (held on 29 September 2007). Check the even web page for the updates:
http://www.openser.org/mos/view/OpenSER-Admin-Course---Rome-2007
and follow the "Materials" shortcut to get to the download web page.
Regards,
Bogdan