Hi all,
I got a question regarding dialog module handling of tm callbacks where
the SIP response message is set to FAKED_REPLY. Specifically, dialog's
dlg_onreply() takes the response message given in the tmcb_params
structure and passes it onwards to all dialog callbacks. One major
problem with this in case of a FAKED_REPLY (e.g., 408) is that dialog
callback users cannot access PVs anymore which, to my knowledge,
requires access to a transaction's message, either request- or
response-wise. Moreover, dialog users will have to check for FAKED_REPLY
to prevent seg-faulting, a tm detail that should be hidden on the dialog
level IMHO.
I (and Marius) have been thinking about ways to resolve this. Here's a
list of what we have come up with:
(1) Instead of passing FAKED_REPLY, pass the response that would be sent
to the caller (e.g., 408). I took a look at the tm module to see if this
is even remotely possible, but frankly, that module is voodoo to me.
Hopefully, someone else can provide some feedback.
(2) Similar to tm callbacks, store both request and response messages in
dialog's analog of tmcb_params (called dlg_cb_params). The dialog
callback user then gets to pick the message to be appropriate for his
use case.
(3) In cases where the response is FAKED_REPLY, pass the request to
dialog callbacks instead.
The last solution is probably the least favorable as it changes the
semantics of the callback: Where you expected a (possibly FAKED_REPLY)
response to be given when the callback is executed, it may now be a
request in certain situations. (2) is easy to implement but still
requires the callback user to be aware of the existence of FAKED_REPLY.
(1) makes most sense to me but I wonder if there were good reasons why
it wasn't done like this in the first place.
Ideas?
Cheers,
--Timo
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A new Flyspray task has been opened. Details are below.
User who did this - Costin Radu (ctradu)
Attached to Project - sip-router
Summary - db_mysql fails to load on centos 5 due to bad simbol ref
Task Type - Bug Report
Category - Core
Status - Assigned
Assigned To - Andrei Pelinescu-Onciul
Operating System - Linux
Severity - Medium
Priority - Normal
Reported Version - 3.1
Due in Version - Undecided
Due Date - Undecided
Details - When trying to compile kamailio with mysql support via db_mysql, the build fails with:
<code>
ERROR load_module: could not
open module </usr/local/lib/kamailio/modules/db_mysql.so>:
/usr/local/lib/kamailio/modules/db_mysql.so: undefined symbol: log
</code>
The compile procedure is as follows:
<code>
wget http://www.kamailio.org/pub/kamailio/latest/src/kamailio-3.1.2_src.tar.gz
tar xzvf kamailio-3.1.2_src.tar.gz
make FLAVOUR=kamailio include_modules="db_mysql dialplan xlog" cfg
make all
make install
</code>
The error has been reported in [[http://lists.sip-router.org/pipermail/sr-users/2010-April/027608.html|Failu… to load module db_mysql.so due to undefined symbol: log]] as well, but it hasn't been fixed yet.
The solution proposed there is working, but it is a year already, and in the main source tree a solution has not been provided.
Working [[http://lists.sip-router.org/pipermail/sr-users/2010-April/027665.html|solut… by Marius Zbihlei]]:
<code>
In modules/db_mysql/Makefile add a -lm (link the math library) to the LIBS variable (right after -lz)
</code>
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=118
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
A user has added themself to the list of users assigned to this task.
FS#118 - db_mysql fails to load on centos 5 due to bad simbol ref
User who did this - Costin Radu (ctradu)
http://sip-router.org/tracker/index.php?do=details&task_id=118
You are receiving this message because you have requested it from the Flyspray bugtracking system. If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.