can you send the patch with 'git diff' or 'diff -u' -- it will be
easier to apply and analyze it. Once I get it, I will look over the
case you reported in more details.
Thanks,
Daniel
On 10/13/11 10:23 PM, Jijo wrote:
Hi Daniel..
I'm using version 3.1.0. I looked at the change but its done only
for forward_reply.. How about relay_reply()?
Thanks
Jijo
On Thu, Oct 13, 2011 at 3:41 PM,
Daniel-Constantin Mierla <miconda@gmail.com>
wrote:
Hello,
I haven't understood exactly what you tried? Was it use of
force_send_socket(...) in onreply_route and didn't work? If
yes, what version are you runing, there was a fix for such
case some time ago:
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 */