THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#137 - app_python doesn't work
User who did this - Michal Karas (Largon)
----------
Hello,
we had problem with loading python script too. After debugging we found out problem was in dname variable which changes it's value after calling memcpy on tname.
I attach patch we've used to solve the issue for us.
----------
One or more files have been attached.
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=137#comment305
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.
Hi All,
Our system has two IP address, one is used for kamailio and 2nd one is used
for data.
The problem is suppose a request came in to kamailio on a TCP connection
with first IP address and connection is torned down before sending the
response. Later when the response is send out kamialio is using the 2nd IP
to create the connection. The reason is kamailio doesn't have force socket
in in reply, so it uses INADDR_ANY for soruce addres .so kernel uses source
address based on the detaintion IP.
I tired to force the socket using pseudo variable $fs or
force_send_socket(), but neither of them worked from reply_route.
So i modfied the code relay_replay to set the SND_F_FORCE_SOCKET which will
use the address where request is recieved as source address to make the TCP
connection The code change is shown below.
Please let me know is there anyother way we could acheive it?
}else{
buf = build_res_buf_from_sip_res( relayed_msg, &res_len );
/* if we build a message from shmem, we need to remove
via delete lumps which are now stirred in the shmem-ed
structure
*/
if (branch!=relay) {
free_via_clen_lump(&relayed_msg->add_rm);
}
/* update send_flags with possible additions from the
reply route */
SND_FLAGS_OR(&uas_rb->dst.send_flags, &uas_rb->dst.send_flags,
&relayed_msg->rpl_send_flags);
/* Make the response to use the same IP where it receives
the message */
* *
* uas_rb->dst.send_flags.f |= SND_F_FORCE_SOCKET; *
}
Thanks
JIjo
Hello,
I installed a new wiki site, targeting to collect documentation for
upcoming v3.2.0 and further releases. You can find it at:
* http://www.kamailio.org/wiki/
Hopefully, it will make the process of updating/migrating the relevant
documentation from old wiki (http://www.kamailio.org/dokuwiki/)
straightforward and offer a clean reference for upcoming stable version.
Old wiki is in place since 2005, collected a lot of pages, but many are
for very old versions of kamailio, making difficult, at least for new
comers, to sort out documentation for latest stable.
All of you are invited to help with this process of adding documentation
for 3.2.0 on the new wiki. The old wiki will stay in place, it will not
be removed. Both are based on Dokuwiki, using different themes. The new
one is at the beginning, so no much content in there yet, but by the
time of releasing 3.2.0, should contain sufficient documentation for get
started with that version.
One very demanded thing was the alphabetic index for parameters,
functions and mi commands from modules. This page contains new generated
indexes for version 3.2.0. More details in a separate email.
If you have questions about the new wiki, don't know where to place some
tutorial, feel free to ask on mailing lists. Ultimately, pages can be
relocated, but try to use namespaces for related topics.
Cheers,
Daniel
--
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Dec 5-8, Berlin: http://asipto.com/u/kathttp://linkedin.com/in/miconda -- http://twitter.com/miconda
THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.
The following task has a new comment added:
FS#167 - $hdr(SomeHeader)[$var(i)] fails when $var(i) is 0
User who did this - Walter Doekes (wdoekes)
----------
Ah. This was indeed a non-issue in kamailio. I'm sorry for wasting your time.
Regards,
Walter
----------
More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=167#comment304
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.