[SR-Users] wt_timer, delayed replies and sendto error

[Daniel-Constantin Mierla]

Hello,

On 9/14/11 2:41 PM, Andreas Granig wrote:
> Hi,
>
> Another funny thing I encountered lately is this:
>
> Client sends INVITE via kamailio (via dispatcher) to sems, gets back
> 100/200, sends another couple of INVITE with same CSeq (looks like
> retransmissions), gets back more 200, then sends ACKs for each of the
> 200 it got. Looks like a quite broken client to me, but anyways.
>
> The interesting thing is that after>5000ms (which is bigger then
> tm.wt_timer), another 200 is sent from sems to kamailio to the client. I
> see the 200 coming to kamailio in a network trace, but not an according
> log message in the kamailio logs. What I see though is this:
>
> Sep 14 13:51:26 sp2 /usr/sbin/kamailio[15950]: ERROR:<core>
> [udp_server.c:586]: ERROR: udp_send:
> sendto(sock,0x97ec10,1055,0,1.2.3.4:58620,16): Invalid argument(22)
> Sep 14 13:51:26 sp2 /usr/sbin/kamailio[15950]: ERROR:<core>
> [forward.h:149]: msg_send: ERROR: udp_send failed
>
> The 1.2.3.4:58620 is obviously taken from the Vias, which looks like this:
>
> Via: SIP/2.0/UDP 127.0.0.1:5060;rport=5060;branch=xyz
> Via: SIP/2.0/UDP 10.1.1.9:58620;received=1.2.3.4;rport=58620;branch=abc
>
> The top-most Via is itself, the second is the one which reflects the
> destination address in the error message above.
>
> So I'm wondering whether there is some issue with finding the proper
> socket after wt_timer is expired (note that the leg client<->kamailio
> uses a different socket (with public ip) than kamailio<->sems (which
> uses 127.0.0.1)). Or any other idea where this error could come from?
>
> It's actually an educated guess that this could be related to wt_timer,
> but I don't know what else it could be.
>
what happens is that when transaction is active and tm is handling the 
replies, they are forwarded using the same socket where the request was 
received (iirc).

However, the transaction is gone so the reply is sent stateless and the 
default rule of stateless forwarding for selecting the local socket is 
to use the same socket where the message was received (in this case is 
the reply is received on loopback interface). Try either to use mhomed 
parameter or force the right send socket by hand (force_send_socket(...) 
or $fs=...) when there is no active transaction for replies (use 
t_check_trans()).

Cheers,
Daniel

-- 
Daniel-Constantin Mierla -- http://www.asipto.com
Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat
http://linkedin.com/in/miconda -- http://twitter.com/miconda