2013-04-08 15:13:41 ERROR:sl:msg_send: received socket is
0x7f5b485c3228, proto 3, required proto is 3
2013-04-08 15:13:41 ERROR:sl:msg_send: selected socket is
0x7f5b485c3228, proto 3
2013-04-08 15:13:41 ERROR:sl:msg_send: received socket is
0x7f5b485c3228, proto 3, required proto is 3
2013-04-08 15:13:41 ERROR:sl:msg_send: selected socket is
0x7f5b485c3228, proto 3
2013-04-08 15:13:45 ERROR:sl:msg_send: received socket is
0x7f5b485c3228, proto 3, required proto is 3
2013-04-08 15:13:45 ERROR:sl:msg_send: selected socket is
0x7f5b485c3228, proto 3
2013-04-08 15:13:45 ERROR:tm:msg_send: received socket is
0x7f5b485c3228, proto 3, required proto is 3
2013-04-08 15:13:45 ERROR:tm:msg_send: selected socket is
0x7f5b485c3228, proto 3
2013-04-08 15:13:46 ERROR:core:get_send_socket: current binding is
0x7f5b485c3228, proto 3
2013-04-08 15:13:46 ERROR:core:get_send_socket: default UDP selected
2013-04-08 15:13:46 ERROR:tm:msg_send: received socket is
0x7f5b485c33f0, proto 1, required proto is 1
2013-04-08 15:13:46 ERROR:tm:msg_send: selected socket is
0x7f5b485c33f0, proto 1
2013-04-08 15:13:46 ERROR:tm:msg_send: received socket is
0x7f5b485c33f0, proto 1, required proto is 1
2013-04-08 15:13:46 ERROR:tm:msg_send: selected socket is
0x7f5b485c33f0, proto 1
2013-04-08 15:13:46 ERROR:core:get_send_socket: current binding is
0x7f5b485c33f0, proto 1
2013-04-08 15:13:46 ERROR:tm:msg_send: received socket is
0x7f5b485c3228, proto 3, required proto is 1
2013-04-08 15:13:46 ERROR:tm:msg_send: selected socket is
0x7f5b485c3228, proto 3
2013-04-08 15:13:46 ERROR:core:udp_send:
sendto(sock,0x7f5b350454d0,1261,0,0x7f5b350418b8,16): Broken pipe(32)
2013-04-08 15:13:46 ERROR:tm:msg_send: udp_send failed
2013-04-08 15:13:46 ERROR:tm:t_forward_nonack: sending request failed
2013-04-08 15:13:46 ERROR:tm:w_t_relay: t_forward_nonack failed
2013-04-08 15:13:46 ERROR:sl:msg_send: received socket is
0x7f5b485c3228, proto 3, required proto is 3
2013-04-08 15:13:46 ERROR:sl:msg_send: selected socket is
0x7f5b485c3228, proto 3
2013-04-08 15:13:46 ERROR:tm:msg_send: received socket is
0x7f5b485c3228, proto 3, required proto is 3
2013-04-08 15:13:46 ERROR:tm:msg_send: selected socket is
0x7f5b485c3228, proto 3
John
-----Original Message-----
From: Bogdan-Andrei Iancu [mailto:[email protected]]
Sent: 08 April 2013 13:18
To: [email protected]
Cc: 'OpenSIPS users mailling list'
Subject: Re: [OpenSIPS-Users] Unexpected Dispatcher TLS interaction
Hi John,
So, UDP is still tried - I see the "udp_send" is calls after the failover.
I suspect that somehow the outgoing socket is wrongly selected, as
"Broken pipe" cannot be generated on UDP.
To check what kind of interface is selected by msg_send() , I made
here a small patch to print some stuff - if you could apply it and get
the logs it will be really helpful.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 04/08/2013 02:00 PM, John Quick wrote:
Hi Bogda,
Here is the log output you requested:
2013-04-08 11:52:31 Failure_Route: Trying next dispatcher target.
ru=sip:[email protected];user=phone du=<null>
2013-04-08 11:52:31 t_relay failed
2013-04-08 11:52:31 ERROR:core:udp_send:
sendto(sock,0x7f51a476c110,1261,0,0x7f51a47534a8,16): Broken pipe(32)
2013-04-08 11:52:31 ERROR:tm:msg_send: udp_send failed
2013-04-08 11:52:31 ERROR:tm:t_forward_nonack: sending request
failed
2013-04-08 11:52:31 ERROR:tm:w_t_relay: t_forward_nonack failed
John
-----Original Message-----
From: Bogdan-Andrei Iancu [mailto:[email protected]]
Sent: 08 April 2013 11:31
To: [email protected]; OpenSIPS users mailling list
Subject: Re: [OpenSIPS-Users] Unexpected Dispatcher TLS interaction
Hello John,
By default, the protocol selection (for outbound part) is done based
on RURI
- as the call comes via TLS, I expect to have a "transport=TLS" in
RURI, param which will be preserved after doing dispatcher
(dispatcher changes domain and port part). So, I guess, opensips is
trying to set the call out via TLS (after dispatcher).
Could you:
1) print $ru and $du after dispatcher (before t_relay)
2) post here the err logs from t_relay
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 04/08/2013 11:43 AM, John Quick wrote:
I have been running some tests using the Dispatcher module on v1.9
of OpenSIPS and found an unexpected interaction with the transport
protocol of the received INVITE request. When the INVITE request is
received over UDP, Dispatcher works fine for all destinations in the
set, but when the INVITE is received over TLS only the first
Dispatcher destination works. The second and subsequent destinations
(after calls to ds_next_domain) all fail. i.e.
in this code, t_relay() returns false:
ds_next_domain("1", "0");
if (!t_relay()) {
xlog("L_WARN", " t_relay failed");
sl_reply_error();
}
I suspect this is a problem with transport protocol selection for
the onward request because the following alternative code works:
ds_next_domain("1", "0");
force_send_socket(udp:<interface-address>);
if (!t_relay()) {
xlog("L_WARN", " t_relay failed");
sl_reply_error();
}
The problem also happens for the first destination in a new
destination set (e.g. using ds_select_domain("2", "0")), after
exhausting all members of set 1.
I would expect Dispatcher to use the same transport for the first
and all subsequent destinations, but it actually looks like it is
using UDP for the first and then using the transport of the received
request for subsequent destinations. Can the transport be specified
in the destination field of the dispatcher table? For example, could
this field be set to "sip:<destination-ip>;transport=udp" ?
John Quick
Smartvox Limited
Web: www.smartvox.co.uk
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
