Calls now work ok, but there are a lot of errors reported, all the time - not just when I call. Perhaps connected with keep-alives?
2013-04-08 17:37:53 ERROR:core:get_send_socket: current binding is 0x7fa98a9a03f0, proto 1 2013-04-08 17:37:53 ERROR:core:msg_send: received socket is 0x7fa98a9a03f0, proto 1, required proto is 1 2013-04-08 17:37:53 ERROR:core:msg_send: selected socket is 0x7fa98a9a03f0, proto 1 2013-04-08 17:37:58 ERROR:tm:msg_send: received socket is 0x7fa98a9a0228, proto 3, required proto is 3 2013-04-08 17:37:58 ERROR:tm:msg_send: selected socket is 0x7fa98a9a0228, proto 3 2013-04-08 17:37:58 ERROR:tm:msg_send: received socket is 0x7fa98a9a03f0, proto 1, required proto is 1 2013-04-08 17:37:58 ERROR:tm:msg_send: selected socket is 0x7fa98a9a03f0, proto 1 2013-04-08 17:38:21 ERROR:sl:msg_send: received socket is 0x7fa98a9a03f0, proto 1, required proto is 1 2013-04-08 17:38:21 ERROR:sl:msg_send: selected socket is 0x7fa98a9a03f0, proto 1 2013-04-08 17:38:57 ERROR:sl:msg_send: received socket is 0x7fa98a9a03f0, proto 1, required proto is 1 2013-04-08 17:38:57 ERROR:sl:msg_send: selected socket is 0x7fa98a9a03f0, proto 1 2013-04-08 17:39:33 ERROR:sl:msg_send: received socket is 0x7fa98a9a03f0, proto 1, required proto is 1 2013-04-08 17:39:33 ERROR:sl:msg_send: selected socket is 0x7fa98a9a03f0, proto 1 John -----Original Message----- From: Bogdan-Andrei Iancu [mailto:[email protected]] Sent: 08 April 2013 16:44 To: [email protected] Cc: 'OpenSIPS users mailling list' Subject: Re: [OpenSIPS-Users] Unexpected Dispatcher TLS interaction Hello John, Thanks for the info - found the problem. Revert the prev patch and apply this one (which also contains the patch). Please have it tested. Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 04/08/2013 05:16 PM, John Quick wrote: > Hi Bogdan, > > Here is the extra output with your patch: > 2013-04-08 15:13:41 INFO:core:probe_max_sock_buff: using snd buffer > of 255 kb > 2013-04-08 15:13:41 INFO:core:init_sock_keepalive: -- TCP keepalive > enabled on socket > 2013-04-08 15:13:41 INFO:core:tls_accept: New TLS connection from > 81.104.44.9:2105 accepted > 2013-04-08 15:13:41 INFO:core:tls_accept: Client did not present a > TLS certificate > 2013-04-08 15:13:41 INFO:core:tls_dump_cert_info: tls_accept: local > TLS server certificate subject: /C=GB/ST=Hertfordshire/O=Smartvox Limited/..... > 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 >>> > _______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
